Besides the increase in mask set cost, total development cost is also increasing due to the reduced probability of getting the design right the first time. As design complexity continues to increase, surveys have shown that only about a third of today's SoC designs are bug-free in first silicon, and nearly half of all re-spins are reported as being caused by functional logic error. As a result, verification managers are now exploring ways to strengthen their functional verification methodologies.

With increased complexity, another cost becomes a limiting factor to the effectiveness of verification – simulation runtime and inaccuracy of stimulus models. Prototyping an ASIC design in FPGAs, while often yielding different performance, still results in the same logical functionality. Further, running a design at speed on an FPGA prototype with real stimulus allows for a far more exhaustive and realistic functional coverage as well as early integration with embedded software. Thus FPGA prototyping can be used effectively to supplement and extend existing functional verification methodologies.

When adopting an FPGA prototyping flow, there are a number of important issues a designer has to consider as follows:

• Partitioning the design across multiple FPGAs
• Translating ASIC primitives to FPGA logic cells
• Conversion of gated clocks
• Support for DesignWare libraries
• Coding for memory portability
• Support for ASIC constraint files

Go high-density
When prototyping a design in an FPGA, if at all possible, try to find a programmable logic device with enough capacity to accommodate the entire design. Doing so will remove any extra design overhead associated with partitioning the design into multiple devices. If more than one device may be required, take the steps early to properly plan the partitioning. While some tools claim to handle partitioning automatically, time is still needed to use the partitioning tool (and often the tools do not live up to their marketing claims).

Further, leaving the partitioning to a tool does not provide good control over utilization overhead, potentially requiring more time to re-adjust the design partitioning latter to better suit the specific prototyping requirements. Instead, use a high quality graphical design entry tool to manage the hierarchy creation, thus each FPGA can be treated as a block within an overall top-down ASIC design flow. Remember that FPGA prototyping is a verification activity, so expect to perform multiple iterations as you identify, diagnose, and correct design errors. Treating each FPGA as a separate block helps to localize the effect of design changes, reducing iteration time.

Be mindful of the programmable logic architecture
Though some differences between ASIC and FPGA design are obvious, such as the lack of any third-party place-and-route flow for FPGAs, others are more subtle but still have profound impact on the design process. Perhaps the most fundamental difference between targeting an FPGA versus an ASIC comes from the architecture of the FPGA itself.

An FPGA is similar to a masked gate array in that both have a number of layers of pre-fabricated logic circuitry and routing lines. The FPGA differs in that – instead of allowing the designer to customize the top few metal layers to configure routing – an FPGA contains a vast array of configurable cells which control interconnect points within a fixed routing architecture. Most general signal routing needs to be mapped to use the generic routing architecture of the FPGA, often having a negative impact on design performance from what one would expect out of a custom or cell-based IC.

Most FPGAs do offer some pre-balanced, high-speed, low-skew routing lines – specifically for clock or other high-fanout nets – as a means to recover some of the performance gap with ASICs. These specialized routing resources are often accessed by instantiating a specific type of buffer cell on the net being mapped to the low-skew line. When prototyping an ASIC design in an FPGA, try to make use of as many of these high-speed clock routing lines as possible in order to improve the performance of the prototype. Encapsulating the clock trees within their own hierarchy allows for a group of FPGA clock mapping buffers to easily replace the ASIC clock tree within the prototype.

Convert gated clocks
Clock gating is a common technique in ASIC designs to power-off certain clock trees in order to conserve power or maximize battery life in portable applications. This same gating circuitry, while effective in an ASIC, severely hinders the performance of the FPGA prototype, since most FPGAs require that high-speed, low-skew routes be connected directly to the flip-flop's clock input.

A good FPGA synthesis tool automatically converts gated-clock-triggered registers to clock-enabled registers, with the clock-gating logic feeding the clock enable to allow mapping of the clock net to high-speed low-skew routes (Fig 1). This mapping reduces the amount of clock delay and skew associated with internal gated clocks in an FPGA prototype.

1. Converting gated-clocks to clock-enables