Controlling the Complexity of FPGA Based ASIC Emulation
FPGA Prototyping technology has advanced enough that ASIC designers and verification engineers can no longer ignore the value that it brings to ASIC and SoC development. It's not surprising that it has become an increasingly important component of ASIC verification plans; the benefits are compelling:
- At speed or near speed ASIC emulation allows many more test scenarios to be run, resulting in a more thorough verification of the design architecture before tape-out.
- FPGA emulation of ASICs is fast enough to run meaningful segments of system and application software, providing additional opportunities for system verification.
- An FPGA prototype can be available before the physical ASIC, allowing for early testing and debugging of software.
But porting an ASIC design onto an FPGA prototyping platform comes with its own set of risks that can trap the unwary. Without a clear understanding of the problems that can arise, the effort can expand beyond even the most conservative estimates, approaching or exceeding the effort to design the ASIC itself. Worse case, design changes being made to the FPGA database need to be reflected back into the ASIC which creates the very unfortunate situation of the FPGA schedule driving the ASIC tape-out schedule.
Figure 1: Distinct ASIC and FPGA Tool Flows
There is a simple reason for this. ASIC and FPGA flows each have a different set of tools and methodologies (see Figure 1). Standard ASIC design methods do not always translate easily to FPGA tools and flows. In many cases porting will require design changes to the ASIC, resulting in expensive redesign efforts, and an FPGA implementation that is very different from the original ASIC. This costs money, takes time, and reduces the value of the emulation. In the worst case the FPGA prototyping project can fail, increasing overall costs, and pushing the schedule out beyond market windows.
Is there a solution to this problem? Yes. The key is to plan ahead. By considering the requirements of FPGA prototyping at the earliest stages of the ASIC design, it's possible to avoid unexpected redesign efforts. In essence, the strategy we take at Intrinsix is to design FPGA Prototyping into the ASIC, without sacrificing the functional or market requirements of the ASIC itself. This greatly simplifies creation of the prototype, resulting in lower costs, and more predictable schedules. It also promotes a higher performance FPGA prototype, which increases its value as an emulation platform.
There are many things to consider when designing an ASIC for FPGA prototyping. Some of the more important ones are:
- clock planning,
- design hierarchy,
- external interfaces,
- RTL coding style, and
- debugging support.
Let's discuss these in more detail.
Because ASIC and FPGA clocking mechanisms differ significantly, an ASIC clock distribution strategy can cause serious problems if the requirements of the FPGA prototype are not considered in advance. One of these differences involves clock gating, which is commonly used to reduce power consumption in ASICs. Unfortunately, FPGAs have a limited set of dedicated resources for distributing low skew clocks, and these typically do not allow the clocks to be gated. But if the clock gating is expressed in a style recognizable to the FPGA synthesis tools, the gating will be automatically resynthesized as clock enables, which are better supported by FPGAs.
Another example involves the limited set of low skew global clock resources on an FPGA . This will place a limit on the number of distinct internally generated global clocks on the ASIC. Care must be taken to avoid the limit, either by restricting the number of these clocks, or by using a different clocking scheme for the FPGA prototype.
The structure of the ASIC design hierarchy can have a large impact on the performance of an FPGA prototype, as well as the time it takes to create the prototype. The process of partitioning the ASIC design onto FPGAs will be simplified if top level design blocks in the hierarchy fit entirely within a single FPGA - from both a gate count and an IO count standpoint. This will also help to achieve the highest possible prototype performance.
The FPGA prototype will usually run at a slower speed than the actual ASIC. Consequently, special consideration needs to be given to high speed external interfaces. Devices like XAUI, DDR3, and PCIe may not be able to run at slower speeds. If the verification plan calls for interfacing the FPGA prototype with these types of external devices, care should be taken to keep these interfaces running at the highest possible speed.
Consideration should also be given to the fact that exact FPGA counterparts may not exist for the ASIC IP that implements external off-chip protocols. As a consequence, the interface IO on the FPGA prototype may differ significantly from the original ASIC, requiring RTL changes on the prototype.
RTL Coding Style
Since a different set of synthesis and partitioning tools are used for FPGAs, it's important to use an ASIC RTL coding style that is well supported by the FPGA tool suite. Obviously, this needs to be taken into account before RTL coding begins.
One of the great benefits of simulation is its high visibility debugging environment. Every signal is readily visible at all times during the simulation. FPGA prototypes, however, provide much lower visibility. To address this, FPGA vendors have created tools to enable debug, such as Xilinx Integrated Logic Analyzer (ILA), Altera SignalTap etc. To take advantage of this requires planning ahead, developing a strategy for using these tools, and leaving enough room on each FPGA to incorporate the extra debugging logic.
The Bottom Line
These are just a few examples of how to prepare an ASIC for FPGA prototyping. The lesson is that: FPGA prototyping can provide a huge verification boost, and allow the software team to get an early start on debugging; but you need to plan for it from the very beginning. Intrinsix has engineers knowledgeable about FPGA prototyping. Access to these engineers early in the ASIC development process will set the stage for a successful FPGA prototyping experience, yielding benefits that can reduce risk, improve the schedule, and ensure a first silicon spin free of logic bugs.