S2C Limited.
S2C Limited.

Emulation vs. Prototyping -- The Performance Curve Crossover | EE Times

Emulation vs. Prototyping -- The Performance Curve Crossover | EE Times Jan 20, 2016

Ron Green, S2C  1/20/2016 11:55 AM EST

As W. Edwards Deming famously said: "Without data, you're just another person with an opinion."

Emulation and FPGA-based prototyping are two technologies used for verifying complex hardware designs and validating systems with large software components. Architecturally, these tools are quite different, but the overlap in their capabilities and applications invariably invites some form of comparison.

As the "big iron" of the verification world, emulators boast muscular chassis wrapped in heavy cables and accompanied by hefty price tags. Cost, in fact, has been the primary knock against emulators. But these systems are quick to bring-up and quick to turn around when processing design changes. Emulators are also recognized for their strong debug capabilities that are comparable to those of software simulators.

Standing alongside an emulator, an FPGA-based prototype can appear small and lightweight. Often the province of one or two engineers, these systems are modestly priced as compared to their big-iron counterparts. Where FPGA-based prototypes shine is speed. While emulators can reach speeds of up to 1 MHz, they often have to settle for 500 KHz or so. Prototypes blow past this handily, regularly clocking in between 10 to 50 MHz, with some approaching 100 megahertz.

The big drawback to FPGA-based prototypes is that it can take a long time to bring one up. It's not uncommon for these efforts to take from two weeks to two months or more. Moreover, prototypes can incur long FPGA place-and-route times when iterating the design, and are typically much weaker than emulators at hardware debug.

The pros and cons of these systems are debated endlessly, often as hallway discussions supported by much anecdotal evidence and arm waving, yet the irony is that emulation and FPGA-based prototyping are the yin and yang of the verification world -- Siamese Twins joined at the point where their performance curves cross over.

Performance crossover is a straightforward analysis, occurring when two systems have different operational speeds and ramp-up times. The performance curves for emulators and FPGA-based prototypes are developed from the metrics of system speed, bring-up time, and time per unit test. Admittedly, this is a simple analysis, and it omits a host of factors such as turn-around time, debug effort, reusability, and other considerations. Nevertheless, performance crossover analysis can be quite revealing and insightful.

One surprising find is that the crossover point occurs so quickly -- even if the prototype is months behind. This fact removes much of the concern regarding long bring-up times. Any effect of bring-up delay disappears as the test and development effort continues.

The other revelation is how dramatically the performance gap grows. The difference in performance is particularly steep when prototype replicates (copies) are used in parallel. The cost advantage that FPGA-based prototypes enjoy -- typically 5 to 1 -- allows multiple platforms to be deployed, thereby accelerating overall performance.

To examine this for yourself, take a look at this Performance Crossover Calculator. The calculator lets you run your own analysis by entering numbers for system speed, bring-up time, unit test time, as well as cost per gate. The resulting graph plots the number of tests run against time, and displays performance crossover data for elapsed hours as well as days.

As Deming famously said: "Without data, you're just another person with an opinion." This analysis lends metrics to a discussion that previously has gone without. As you simulate various combinations of parameters, you will see that results beyond the crossover point become quite compelling for FPGA-based prototypes, especially when unit test times are long or the number of test runs is increased.

Now, if you think all of this makes a case for FPGA-based prototyping in lieu of emulation -- it doesn't. There's no arguing against the tried-and-true methodology of emulation. The inherent strengths of emulators are well-suited to system integration efforts and rigorous verification testing. In fact, the direct results of performing emulation are designs that stabilize and mature more quickly. This in turn precipitates a shift from verifying hardware elements to validating software components.

When this change in focus occurs, FPGA-based prototypes become the natural platform to pick up the pace of validation and further drive software development. Performance crossover analysis serves as an aid in determining when to make that shift, and why. Ultimately, this is a powerful demonstration of how emulation and FPGA-based prototypes are complementary tools -- not despite their performance crossover, but because of it.

Back to list Back to list
Related S2C Complete Prototyping Solutions
Neuro enables users to quickly access FPGA computing power and CPU cluster resources deployed in data centers or company computer rooms through various terminal devices.
Memory Modules
DDR3 Memory Module, DDR3 Memory Module Type B, 8GB DDR4 Non-ECC,16GB DDR4 ECC
Prodigy Logic Module
S2C's FPGA Prototyping system has been in the market since 2004 and has since been widely adopted by many leading SoC/ASIC design companies. The Prodigy Logic Module series are specially designed ...
What's New at S2C
Request for Quote
What type of chip are you designing
What is the capacity of the ASIC gate included in the design?
5 million-20 million
20 million-50 million
50 million-100 million
100 million-1 billion
More than 1 billion
Which FPGA do you prefer to use?
Xilinx VU440
Xilinx KU115
Xilinx VU19P
Xilinx VU13P
Xilinx VU9P
Intel S10-10M
Intel S10-2800
Not sure, need professional advice
What kind of FPGA configuration do you need?
Single FPGA
Four FPGAs
Eight FPGAs
Not sure, need professional advice
What kind of peripheral interface do you need?
How many prototype verification platforms do you need?
Do you need the following tools?
Segmentation tool
Multiple FPGA debugging tools
Co-modeling tool (allows large amounts of data to interact between FPGA and PC host)
When do you need to use our products?
0-6 months
6-12 months
More than 12 months
Not sure
Any additional comments?