To emulate or prototype?

In my last blog I talked about debugging a design within an FPGA. This week I want to turn the tables completely and talk about using FPGAs as a way to verify ASICs. FPGAS can emulate a design at speeds close to their actual operating frequencies, enabling kinds of verification that would otherwise not be possible, such as in-circuit emulation, or runs that go deep into the state space of the design that would take hours or even days to reach in simulation.

Using FPGAs can also make stimulus creation a lot simpler by enabling the use of real world stimulus coming from peripheral interfaces, audio or video streams etc. But this is a path not for the faint of heart or those who are unprepared.

There are three primary ways in which people usually accomplish this. This first is to buy an emulator or simulation accelerator from one of the EDA vendors (I will discuss the differences between these approaches in a future blog).

The second option is often called "rapid prototyping" and usually involves a board with a number of FPGA mounted on it with a fixed configuration and may also include other pre-implemented hardware that can be connected in as well. There are two possibilities with these prototypes, either create a custom prototyping board that may match your application domain, or buy a commercial offering that can allow arbitrary systems to be built up from FPGA modules, or from other specialized modules such as memory, processor or peripheral modules. In this blog we will quickly compare and contrast the differences between these alternatives. Of course, in a short blog such as this, only a few issues can be addressed and I may well follow up on some of these in more detailed blogs later.

If you have a design that is running in a simulator, how easy it is to migrate that design into either an emulator or prototype system? The answer to this somewhat depends on if you intended to do this from the start of your project or if it is a last minute decision based on problems and looming deadlines.

If the design was never meant to be targeted to an FPGA, then you may have problems. For example, how many clocks does your design need? What about the IP you are using? What about the number of registers or amount of memory. All of the resources are limited within an FPGA and this can present serious problems with the mapping – even if multiple FPGAs are to be used. Many of these issues will be lessened with a commercial emulator, but not removed completely.

And don’t for a moment think that only ASICs have timing problems. With the design mapped into an FPGA you are likely to be tracking down problems that are only germane to the prototype. Are you ready for the extra debug required?

Of course, when you find a problem, you will have to go back to my previous blog to work out how to debug that issue and to find the right fix, no matter if this is a design issue or a prototype issue.
What if your design contains one or more processors being delivered as an IP block? The answer will depend on which processor and the arrangements you have with the processor vendor. Let’s assume that you have the RTL – do you want to spend the time and effort mapping that onto an FPGA. Perhaps the FPGA vendor has a hardened core for this. Or possibly they have bonded out cores that could be integrated into either an emulator or into some prototyping systems –you will want to check out your options here – ahead of time.

Consider the Xilinx Virtex-6 LX760 device – fairly large designs (over 4M gates equivalent, plus over 30 MB memory) could fit into one of these devices. Synopsys uses these devices in their HAPS FPGA-based prototyping product family, where you get the option of having 1, 2 or 4 of these FPGAs on a single board, which equates to support for up to 18 million ASIC gates per board. Multiple boards are also possible.

Similar devices are used in the EVE ZeBu servers that can accommodate up to 1 billion gates. Most designs will require multiple FPGAs, which means that the design has to be partitioned, and this can be a difficult and error-prone task, especially when the number of FPGAs goes up. Emulators and commercial prototypes do the heavy lifting for you, but for a custom board you are on your own and you may have to redo this every time you make a design change or want to change the levels of internal visibility.

Another problem with roll your own and partitioning tends to be running out of pins. Many emulators and prototypes employ time-division-multiplexing on the interconnect, which frees them of these restrictions, but which requires additional state machines to implement it – something quite simple for the software to do but more difficult when trying to do it yourself.

I spoke to Ron Choi, an independent technical marketing consulting who has been working in this space for a long time. He advised that you should only consider a roll your own approach if:

• You already have FPGA experience
• You must achieve a certain performance (e.g. to display real-time video without rate matching, or to test a wireless application)
• You can fit their design into a few FPGAs
• You are part of a big organization, who can afford a point-tool for SW development/real-time validation, in co-existence with commercial emulators for other stages of the project.

By comparison, commercial emulation may be more appropriate for groups who:

• Have large capacity and multiple user requirements
• Do not have any FPGA experience
• Prioritize HW debug and/or HW/SW Co-verification capabilities over the just the SW development speed
• Want to leverage one system across their ESL flow, HW verification, as well as final SW development and validation.

Finally, there is the issue of cost – but this is not just about the amount that the hardware costs – it is about working out the true cost of all of the issues, the software, the time that will be spent etc. There is no one right answer, but I hope this blog has at least made you think about some of the issues.

Brian Bailey – keeping you covered