A Delicate Choice – Emulation versus Prototyping

Hardware-assisted verification has been with us (commercially) for around 20 years and at this point is clearly mainstream. But during this evolution it split into at least two forms (emulation and prototyping), robbing us of a simple choice – to hardware-assist or not to hardware-assist (that is the question). Which in turn sometimes encourages us to force a choice – which is the better option? The answer to that question unfortunately (at least for your capital budget) is that it depends. There are multiple factors to consider.

The most obvious way to look at this is cost. Emulators are expensive and prototypers are much cheaper. But cost, while a good secondary metric, is rarely a good primary metric. An off-road UTV is cheaper than a car but I wouldn’t want to drive it to New York. Equally, I wouldn’t want to drive a car up a goat trail. These solutions each have strengths in different applications. Also, emulation providers are starting to offer cloud-based access, presumably with much more modest usage-based costs.

Another consideration is where/when you can use the solution. Conventional wisdom holds that you use emulation earlier in design and prototyping when the design is pretty much frozen. But this isn’t quite right. Prototyping can actually be very useful before you even commit to hardware implementation for at least a couple of reasons. The first is the classic reason you build any prototype – to check it out in situ so you can refine design concepts. This approach is also useful when you want to bid on a project request for proposal or when you’re trying to raise funding. A demonstrator is a very credible way to convince a prospect that your proposal is viable.

There’s another very important reason to consider an early prototype – to start software development early. Virtual prototypes (the purely software kind) are also valuable here but are limited where the prototype needs to interact with real-world connections, through MIPI or ADCs/DACs for example. An FPGA prototype can realistically interact (through extension boards) with these interfaces.

Another consideration is real-time performance. Typical emulator clock speeds are in the sub-5MHz range, whereas prototypers will run in the 5-10Mhz range with hands-free setup and can run even faster (I have heard of 50MHz or higher clock speeds) with hand-tuning. Both options are usually well below real silicon speeds but the higher performance of the prototypers makes them more effective for certain tasks. Supporting software development is one obvious example. Few software developers will accept test/debug cycles at emulation speeds, but they are willing to work with prototyping speeds.

Performance is also important when testing functionality with video and audio streams. It’s difficult to test a meaningful segment of a 4K video stream at emulator speeds. On a prototyper, testing will still not be real-time but will be much more practical.

Performance is also important in the late stages of design if running big regression/ compliance test suites is a significant consideration. Here the time to cycle through these suites can be a major gate in the schedule, so reducing that time becomes very important. And obviously if you can deploy multiple low-cost prototyping platforms to parallelize regression testing, you can further reduce that time.

So far it might seem that I’ve made a very strong case for FPGA prototyping being the solution of choice for all needs. But emulation has some significant advantages which shine during design development. The first is setup time. A prototype can take days (best-case) to weeks to setup. That’s OK when you’re in the concept phase or in final functional verification / signoff. But it’s not OK when you’re cycling through RTL drops. Here you need a day or less for setup time, something emulators can support even on very big designs.

The there’s hardware debug. FPGA prototypers map your design into FPGAs with an emphasis on performance and utilization rather than design debug. This is because adding significant debug support logic would significantly expand the size of your design (so you’d have to buy bigger prototyping systems) and also would reduce performance. There are still ways in prototypers to get fast access to some of the logic. You can even dump all state but very, very slowly. So prototype users look at their boxes primarily as support for software debug, not hardware debug. Where a potential hardware bug shows up in software testing, the prototyper team will kick it back to the emulator team for detailed diagnosis.

Emulators on the other hand have mechanisms to access and debug all state in the design across expansive time windows because that capability is intrinsic to the hardware design of the emulator. So emulators are significantly more effective in supporting hardware debug, which is obviously of primary importance during the hardware development phase.

So there’s your answer. Emulators and prototypers both have significant and complementary value during product development. You can learn more about this topic by reading the S2C/SemiWiki book on prototyping, which you can request HERE.