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, I enjoy reading your blog on my favorite subject “Emulation or Prototyping”. I am Thomas Huang and have devoted the last 20+ years in ASIC Emulation and Rapid Prototyping. Your thoughts are well documented here and I would like to add some insight from my experience in these areas. Wireless core designs are pipelined and must run over 20 Mhz to hear voice. Consumer SoC core designs need to run over 25 Mhz to mimic the real time environment.
The emulation advantages are (1) mapping automation (2) interconnection routing (via TDM) (3) mapping verification (via co-emulation) (4) RTL verification acceleration (via SCE-MI) (5) full visibility debugging (via TDM probe). The emulation disadvantages are (1) slow (2) expensive and (3) uncertainty of Speed Bridges. When the ratio of core logic and target interface is too high, such as 1 Mhz to 75 Mhz, the Speed Bridge makes the validation results questionable.
The FPGA prototype challenges are mostly related to mapping and debugging. In the earlier emulation days, most engineers were paranoid they would detect a problem that was caused by mapping error, physical damage, design error or embedded software bug. It was extremely frustrating for a team to find out the problem is caused by non-design issue. Once co-emulation was used as a standard methodology to verify mapping and physical integrity, the issues shifted to hardware/software co-debugging. You have stated many FPGA debugging issues in previous blog. In the FPGA prototype world, co-emulation is not an option and these users typically rely on ILA or logic analyzers to catch mapping, physical design, and software issues one by one… very slowly.
Michael Chang and myself founded InPA Systems and are trying to make FPGA prototyping a much easier process with new technology that will address the issues I mention above…stay tuned!
Brian, I would be happy to join your topic of emulation/rapid prototyping in the future.
I have managed a development of product (wireless terminal) and we also developed the needed mixed signal IC as part of the design. I have used both simulation and emulation methods for that project. I can definitely suggest that the use of FPGA for part of the emulation definitely helped us get quick and good results on the first tape-out. We did identify some issues using the emulation which were difficult to identify with just simulation. It also provided a quick way to enable the software team to go ahead and develop and test the board level software on the emulation board before we have received the final mixed signal IC.
Very timely article,Indeed. My own experience about emulators vs prototypes showed that FPGAs show great value addition for 1/100th the cost and 50x gain in test speeds along with immeasurable advantage it gives to SW development and test teams spread across multiple locations.
The basic ingredient of success is not the partitioning tools but to have FPGA specific skillset in the team which ports ASIC design on multiple FPGAs.
Brian - A very relevant topic in the current state of affairs with ASIC designs - using FPGA based prototypes have become the norm not only for emulation, but also for software development (or prototyping). I know there is some overlap between an emulator and prototype platform, but they are for different purposes. An emulator is used to verify the RTL, while the prototype is used more for software development.
Cost(as you rightly pointed out) and the need for custom interfaces is a major factor driving people to do their own FPGA boards. Also, buying an FPGA board really doesn't solve the problem of having to partition/tune the RTL for FPGAs.
However, the good news is that some of the recent software tools do take some pain points away in "rolling your own" boards: There is now a tool to architect, specify the communication between FPGAs, and design your FPGA boards from Cadence - the Allegro FPGA System Planner. There are also tools from Synopsys (Certify) and Auspy (ACE) that help with partitioning and automatic insertion of the muxes for the Time Division Multiplexing that you talk about. These software tools, in combination with the debug techniques you talked about in your previous blog should give users the confidence to design their own boards (and save the "extra" budget for a bonus!!!)
I hope that some of the bullet points would help - at least to start with - determine which you may have more success with. Then as you say there are the goals and outcomes that a team expects to get from it. Costs are very different. Suppose for example that you want to create 20 or 100 prototypes to give to a set of software developers spread around the world. It may not be possible to do that in an economic fashion with an emulator - and besides, the visibility into the hardware may not be an issue. But if you are trying to debug some core driver routines that have some timing issues, then the emulator may be more suitable for that task. Every development team and situation is different, so any vendor who says that my solution is always the right one is lying. The right way to go takes planning and being aware of all of the trade-offs that you are making.
The folks pushing emulators say that FPGA-based rapid-prototype boards don't provide sufficient visibility into the design and can't offer co-emulation and co-simulation capabilities.
The folks pushing FPGA-based rapid prototype boards say that emulators are too slow and expensive and... the battle rages on.
Have you had experience with both solutions? If so, how would you advise someone who wasn't sure which way to jump?
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.