WP_Term Object
(
    [term_id] => 41
    [name] => S2C EDA
    [slug] => s2c-eda
    [term_group] => 0
    [term_taxonomy_id] => 41
    [taxonomy] => category
    [description] => 
    [parent] => 14418
    [count] => 73
    [filter] => raw
    [cat_ID] => 41
    [category_count] => 73
    [category_description] => 
    [cat_name] => S2C EDA
    [category_nicename] => s2c-eda
    [category_parent] => 14418
)
            
S2C Banner
WP_Term Object
(
    [term_id] => 41
    [name] => S2C EDA
    [slug] => s2c-eda
    [term_group] => 0
    [term_taxonomy_id] => 41
    [taxonomy] => category
    [description] => 
    [parent] => 14418
    [count] => 73
    [filter] => raw
    [cat_ID] => 41
    [category_count] => 73
    [category_description] => 
    [cat_name] => S2C EDA
    [category_nicename] => s2c-eda
    [category_parent] => 14418
)

Fastest SoC time-to-success: emulators, or FPGA-based prototypes?

Fastest SoC time-to-success: emulators, or FPGA-based prototypes?
by Don Dingee on 02-11-2016 at 12:00 pm

Hardware emulators and FPGA-based prototyping systems are descendants of the same ancestor. The Quickturn Systems Rapid Prototype Machine (RPM) introduced in May 1988 brought an array of Xilinx XC3090 FPGAs to emulate designs with hundreds of thousands of gates. From there, hardware emulators and FPGA-based prototyping diverged – but why, considering they do approximately the same thing?

How they do the job of SoC verification is quite different, but both are important. In the latest 2014 Wilson Research Group Functional Verification Study, data shows FPGA-based prototyping systems wildly popular for small design projects less than 5M gates, each used roughly equally for medium designs, and a current advantage for emulators with FPGA-based platforms starting to close the gap for large designs over 80M gates.


chart courtesy of Mentor Graphics and Wilson Research Group

Emulators fall in the category of capital expenditure, some with price tags of over $1M for hundreds of FPGAs or ASICs and specialized interconnect inside. An SoC design can be loaded on an emulator, chopped into many smaller pieces, and spread out across many partitions fairly quickly. Users need not know the details of the logic implementation or the interconnect organization, there are few issues with closure, and there is extensive debug visibility. Once installed and configured, ease of use after an initial learning curve is a big benefit.

FPGA-based prototyping systems are definitely more cost effective, most with one to eight FPGAs. Some state-of-the-art platforms are emerging with 32 FPGAs which may challenge for very large design starts. If an FPGA is large enough to contain all of an SoC design, synthesis is straightforward; otherwise, some partitioning is required to distribute logic across several FPGAs. Debug visibility is improving rapidly. Knowledge of the FPGA architecture and interconnect is increasingly automated in hardware-aware synthesis tools. Even with automation, synthesis and place & route can take some time – vendors now tout overnight turnaround, possibly faster with incremental synthesis for small changes.

Taking cost, capacity, and use cases out of the equation for a minute, how can the two platforms be compared apples-to-apples on a design of given size running the same verification steps? A fair comparison is time-to-success. How long does it take to set up, test, and iterate an SoC design until completely verified? Two variables dominate the time-to-success equation: preparation time, and run time.

Preparation time goes to the hardware emulator. Usually a design can be loaded in a matter of hours, compared to days or weeks for FPGA-based prototypes beyond trivial complexity.

Run time goes to the FPGA-based prototyping platform. Emulators are fast compared to software-only simulation, but get blown away by FPGA-based prototypes which typically run in the 10 to 50 MHz range, sometimes as fast as 100 MHz if conditions are right. We said we’d take away a difference like co-verification with a production operating system and software which may be infeasibly slow on an emulator, but even for the same testbench, a run on an FPGA-based prototype can be 10 to 100 times faster than emulators that usually top out around 1 MHz.

That suggests a crossover in time-to-success. If you’re lucky enough to have designs with relatively few bugs and a correspondingly low number of design iterations, the hardware emulator may win the race with its faster preparation time and a short debug cycle. As complexity in integration and testing grows, there are likely to be more iterations required. With the preparation time baked in and a reasonable debug cycle and turnaround time for iterations, FPGA-based platforms deliver a shorter time-to-success as N runs are considered.

 Where is that crossover? S2C has captured a simplified analysis in their Performance Crossover Calculator tool. By plugging in bring-up time, clock speeds, unit test time, cost per gate, and N runs, designers can get a graph comparing the timeline for each approach. (All the “your mileage may vary” caveats apply here, but it does provide a useful estimate.)

Two big hacks can speed time-to-success further. FPGA-based platforms are inexpensive enough to clone – replicate testbenches can be created to divide and conquer the verification testing. There is also the advantage of putting FPGA-based prototypes on desks of software engineers, allowing them to do pre-silicon production software testing.

Of course, your design probably flies through verification the first time, right? If you’ve been frightened by stories of long setup and synthesis times on FPGA-based prototyping systems, and you’re not so sure how many iterations you’re facing, this is worth a look. Both hardware emulation and FPGA-based prototyping have a place, and this may help understand how each can improve your time-to-success.

More articles from Don…

Share this post via:

Comments

0 Replies to “Fastest SoC time-to-success: emulators, or FPGA-based prototypes?”

You must register or log in to view/post comments.