Improving Emulation Throughput for Multi-Project SoC Designs

Transcription

1 Improving Emulation Throhput for Multi-Project SoC Designs By Frank Schirrmeister, Caence Design Systems As esign sizes grow, so, too, oes the verification effort. Inee, verification has become the biggest challenge in SoC evelopment, representing a majority share of the evelopment cost, both for harware itself an for verification at the harware/software interface. An toay, it s not uncommon for companies to have istribute teams working on multiple SoC esigns in parallel. In some cases, teams have been known to share emulation resources amongst tens of projects. In this paper, we ll iscuss the characteristics you shoul look for to boost your emulation throhput an esign team prouctivity in orer to effectively an efficiently manage the elivery an performance targets for multiple, complex SoC esigns. Contents Introuction...1 The Emulation Throhput Loop...2 Why a Holistic View of Parameters for Emulation Throhput Matters...4 How to Support Enterprise-Level Verification Computing Nees?...4 Avantages of an En-to-En Flow...5 Summary...5 Introuction While the average esign size in 2014 was about 180 million gates, accoring to Semico, that size is expecte to grow to an average of 340 million gates in Of course, since these are simply average figures, there are esigns that also have more than a billion gates. Large SoCs typically consist of multiple heterogeneous an homogenous integrate processor cores as well as hunres of clock omains an IP blocks. All of these components nee to be verifie to ensure that they work as intene. The software executing on the cores as aitional verification challenges an complexity. So while overall esign size growth is important, you also nee to consier the varie sizes of each of these components. On top of all this, esign scheules are as aggressive as ever, given toay s market pressures. See Figure 1 for an example of an avance SoC. In reaction to shrinking esign cycles, we re seeing much more harware esign reuse as well as the application of avance power management techniques, where functions are instea implemente in embee software. Design reuse an power management a to the verification challenge, as you nee to consier everything from IP interaction at ifferent levels to the interaction between the harware an software components. With these consierations, you nee a harware/software verification platform that can simultaneously hanle tasks of ifferent sizes an execution lengths, from the smaller IP blocks to sub-systems up to the SoC level. An, you ll nee to exten this verification effort across your enterprise to the other esigns that you re concurrently eveloping.

2 Improving Emulation Throhput for Multi-Project SoC Designs 1 L2 cache CPU Subsystem L2 cache 3D GFX Application Specific Components DSP A/V Apps Accel Moem Cache Coherent Fabric SoC Interconnect Fabric DDR3 P H Y USB3.0 P H Y PCIe Gen 2,3 High-Spee, Wire Interface Peripherals Ethernet HDMI SATA MIPI WLAN LTE Other Peripherals GPIO UART Display INTC PMU I2C MIPI SPI JTAG Low -spee peripheral Timer subsystem Low-Spee Peripherals System on Chip (SOC) The Emulation Throhput Loop Figure 1: Avance SoC architecture An effective system verification flow integrates a number of techniques: Virtual prototyping supports early software evelopment prior to RTL availability, with valiation of system harware/software interfaces as the RTL becomes available an transaction-level moels (TLMs) can be run in hybri configurations with RTL. Avance verification of RTL using simulation is the golen reference toay, use in every project. It is focuse on harware verification as it is limite in spee, but unbeatable in bring-up time an avance eb. Simulation acceleration verifies RTL harware as a combination of software-base simulation an harwareassiste execution, allowing you to reuse your existing simulation verification environment Emulation has proven to be effective for harware/software co-verification with the fastest esign bring-up an simulation-like eb, executing jobs of varying sizes an lengths in parallel FPGA-base prototyping is applie when RTL matures an provies a pre-silicon platform for early software evelopment, system valiation, an throhput regressions When consiering the emulation throhput of a platform an its ROI, it s important to keep in min the four major steps in an emulation throhput loop (Figure 2), along with the questions you shoul ask yourself at each step: In the buil process, you re builing your verification job, compiling the atabases to aress ifferent workloas an tasks. Some questions to consier: How fast is the compiler? What is its efficiency an egree of automation for RTL vs. gate-level netlist? How user-frienly is it? How many constructs oes it support? Spee in builing these atabases is just one parameter, as effective use of resources is also important, particularly since the use moel will change as you move throh ifferent scenarios in your esign. cation is about allocating the workloa as efficiently as possible given a certain resource. Questions to consier here: how many parallel jobs can the system hanle? How quickly can you allo from one resource to another without much user intervention? How o you prioritize an swap these tasks accoring to eman loa? All these significantly impact the workloa efficiency with which a compute resource can execute the verification workloas a team has to verify. 2

3 Improving Emulation Throhput for Multi-Project SoC Designs The run step is about execution, but while it may be tempting to focus on how fast the system can run, that s not the whole story here. This step also pertains to the use moel an the interface solutions for that particular use moel. Questions to consier: Is the system running jobs base on your esign priorities? How many jobs can your system execute in parallel? Can jobs be suspene an resume? Can a specific point of interest be save to be resume from later? focuses on etection of pre- an post-silicon bs. Questions to consier: How well can you eb using the verification platform while minimizing the nee to re-run the tests to isolate the b? How efficiently can you ajust your triggers ynamically without re-compiling? Do you have sufficient eb traces for both HW an SW analysis to allow you to capture a large enoh winow of eb interest, or o you have to execute multiple times to get the right ata to eb? Compile atabases for ifferent workloas (Compile: spee, automation, # of workstations) as many workloas as possible (Utilization efficiency: # of parallel jobs, relocation) for both pre- an post-silicon bs (Visibility: trace epth, ynamic trigger) workloas base on priorities (Spee: use moels, interface solutions) Figure 2: The emulation throhput loop Each of these steps impacts overall emulation throhput in their own way. For example, eb analysis, consiering its ata capture an generation requirements, can slow own FPGA-base prototyping an FPGA-base emulation significantly. So you nee to ecie how much eb is neee for each phase in each particular esign. An you might make some ajustments, like using processor-base emulation, uring which eb runs un-intrusively at emulation spees. As illustrate in Figure 3, this emulation throhput loop will be repeate multiple times in parallel from initial bring-up to silicon tapeout as you integrate an valiate each feature set in your esign. So each engineer on your team woul go throh the process of eiting their source, checking, compiling, checking in, an integrating their work with that of their peers. Eventually, an later in the flow, the system becomes eterministic an coherent. Once you ve settle on your feature set an move into the regression run, you might unergo the emulation loop less often until tapeout. 3

4 Improving Emulation Throhput for Multi-Project SoC Designs Initial Bring-up Set 1 Set 2 Set N Silicon Tapeout Figure 3: The verification prouctivity loop is repeate multiple times in parallel throh the esign cycle. Why a Holistic View of Parameters for Emulation Throhput Matters It is also important to take a holistic view of your parameters when you are evaluating emulation throhput. Consier energy cost some may calculate this value as intrinsic power over time. However, intrinsic power is merely one portion of the power equation. When comparing, for example, an FPGA-base emulator with a processor-base emulator, you ll likely fin that the total processor-base emulator power can be lower than in an FPGA-base emulator when you calculate all of the power consume in a verification task, i.e. aing up compilation (which often nees large parallel server farms for FPGA-base systems), allocation (processor-base emulation may allow better workloa efficiency if the granularity of emulation resources is fine enoh), execution, an potentially multiple eb runs require to generate comparable amounts of eb information if trace buffers are not appropriately size. Also important consierations are job granularity an gate utilization some systems are simply better esigne than others to minimize waste emulation space an provie faster turnaroun times. It s not only about the number of jobs supporte. For example, a system with fine-graine capacity can support more jobs in parallel while minimizing the resources require. To calculate total turnaroun time, you nee to consier the number of jobs, the number of parallel jobs that your system can execute, an the run an eb times for this. How to Support Enterprise-Level Verification Computing Nees? If you have multiple ongoing esign projects involving multiple teams istribute across the globe, not just any verification computing system will o. Enterprise-level verification computing calls for a system that: Can scale to billion-gate esigns while running within your performance/power targets Has the ability to support a high number of aily esign turns Offers eb prouctivity with sufficient trace epth to generate the require eb information an fast analysis an compile times Can provie the flexibility to allo a given job to any other omain on the logic boar to make the best use of computing resources Can offer the efficiency of ynamic resource allocation by breaking up a job in a non-consecutive manner to match the available resource in the system Does not lock your jobs to given physical interfaces, instea proviing the ability to switch virtually between targets an jobs 4

5 Improving Emulation Throhput for Multi-Project SoC Designs Avantages of an En-to-En Flow Given these parameters, there certainly are avantages to using an en-to-en flow. When an emulation system is part of a set of connecte platforms, you can quickly migrate between the interoperable platforms an between harware/software omains to complete your system-level esign, integration, an verification tasks. An integrate flow coul provie a substantial boost to esign team prouctivity, while minimizing esign risks. An example of an integrate set of evelopment platforms to support harware/software esign an verification can be foun in Caence s System Development Suite. The suite s connecte platforms reuce system integration time by up to 50%, covering early pre-silicon software evelopment, IP esign an verification, subsystem an SoC verification, netlist valiation, harware/software integration an valiation, an system an silicon valiation. Summary Clearly, if your esign team isn t using your harware resources as efficiently or effectively as they coul, the team loses valuable prouctivity. With toay s large, complex SoCs, achieving high levels of multi-user verification throhput an prouctivity are essential elements of an overall competitive avantage. Many traitional compute resources aren t equippe to meet these parameters. Instea, toay s esigns call for capabilities incluing high capacity, efficient job allocation, fast runtime, an extensive eb to help you swiftly take your esigns to tapeout. Caence Design Systems enables global electronic esign innovation an plays an essential role in the creation of toay s electronics. Customers use Caence software, harware, IP, an expertise to esign an verify toay s mobile, clou an connectivity applications Caence Design Systems, Inc. All rights reserve worlwie. Caence an the Caence logo are registere traemarks of Caence Design Systems, Inc. in the Unite States an other countries. All other traemarks are the property of their respective owners /15 CY/DM/PDF