Most system designers today are faced with a dichotomy. They must develop systems in constantly shrinking time-to-market windows, but at the same time they are constricted by aggressive material and manufacturing cost targets. FPGAs have clearly shown themselves to be an excellent vehicle for implementing custom digital logic within the time-to-market window. However, their flexibility is not without a price. FPGA architectures require 25 to 50 times more silicon area per logic function than an ASIC in the same technology. That makes the FPGA a more costly alternative, a disparity that often makes it impossible to meet the system cost targets with an FPGA solution. Many system designers resolve the dichotomy by designing FPGAs for new-product introduction and converting them to ASICs for volume production.
There are several factors to consider when adopting the FPGA-to-ASIC strategy. First, the cost trade-offs should be evaluated to determine whether the volume requirements are adequate to offset the nonrecurring engineering costs involved in developing the ASIC. For optimized overall turnaround time, engineers must consider design techniques that will facilitate a seamless conversion to an ASIC. Finally, designers who plan such a conversion will also find that they face a choice of ASIC design methodologies, which can be summarized as retargeting or remapping. Each has advantages and disadvantages.
Although the cost savings of an ASIC can vary widely, the unit cost will typically be 50 percent of that of the FPGA that is being converted. This is because in most cases, an ASIC die will be smaller and cost less than a comparable FPGA die. The programming flexibility of the FPGA architecture requires more silicon area to implement a logic function than in an ASIC, which adds to the FPGA's higher cost.
For an FPGA-to-ASIC conversion to make sense, the nonrecurring engineering (NRE) costs incurred must be recovered in the unit-cost savings. That happens when the volume of ASICs purchased, multiplied by the unit-price cost savings, exceeds the NRE costs. The annual volume at which the NRE costs are recovered and overall cost savings are realized can be as little as 1,000 units for complex FPGAs or as many as 25,000 units or more for low-end FPGAs. Wafer costs for an FPGA are also typically higher because of the masking levels required for programmable logic architectures.
Certain design considerations are recommended when a designer knows from the outset that the design will be converted from an FPGA to an ASIC. The use of synchronous design techniques best facilitates that kind of conversion. A synchronous design can be defined as one that has a single master clock signal and a single master set or reset signal driving all sequential elements in the design. In addition, all input signals should be synchronized to the master clock in such a manner that there are no setup- or hold-time violations. The benefit of synchronous design is that it reduces the timing issues to be resolved during conversion to maximum clock frequency, input setup-and-hold times, and clock-to-output propagation times.
It is not always possible to design a synchronous circuit in this way, however. In those cases, additional timing issues will revolve around what happens with sequential elements, such as registers and flip-flops. The clock, set and reset pins of the sequential elements are referred to as direct-action signals because they have an immediate effect on the element. Unlike combinational logic, any unexpected spikes, glitches or pulses on these direct-action signals can have a detrimental effect on performance by introducing unexpected changes to the state of the element.
Direct-action signals require more detailed consideration when designing an FPGA that is targeted for conversion. Without this additional consideration, an FPGA can be designed and simulated, and exhibit no spikes, glitches or pulses. But when converted to an ASIC, where the loading between logic cells is greatly reduced and switching times are much faster, this same design can exhibit an unwanted direct-action signal glitch. The best time to address these issues is during the design of the FPGA so as to avoid unforeseen delays in the FPGA-to-ASIC conversion schedule.
State decoder example
An example of direct-action signal glitches can be observed by considering the state decoder circuit described by the Verilog RTL and the resultant schematic in Figure 1. This design is a 2-bit counter that loads data (D) into the flip-flop on the right when the counter reaches a value of 11. A problem can occur when the CNT0 and CNT1 signals transition from a "01" value to "10" value. If the CNT0 signal transitions to a "1" value before the CNT1 signal transitions to a "0" value, a glitch will occur on the CA signal, causing an unanticipated loading of data into the flip-flop. In an FPGA, where the internal capacitance and the propagation delays are greater than in an ASIC, this condition may not occur nor be observed during simulation. The problem may not show up at all until a converted ASIC is simulated.
The problem with this kind of state decoder can be corrected in different ways. An asynchronous solution is described by the Verilog RTL code and resulting schematic in Figure 2. In this case, the CA signal is derived from the CNT0, CNT1 and the inverse of the clock signal. Any glitches resulting from different delays in the CNT0 and CNT1 signals will be ignored until the CLK signal returns to a "0" state. This technique usually works as long as the delay of the CNT0 and CNT1 signals is less than the pulse width of the CLK signal in both the FPGA and ASIC.
A synchronous solution to this design problem is described by the Verilog RTL code and resultant schematic in Figure 3. This solution does not add any clock delay by decoding the clock-enable state value during the previous clock cycle. This decoded value is stable and ready to use as a clock-enable signal when the master clock transitions. This solution is preferred because it will work independently of the delay characteristics of both the FPGA and ASIC libraries.
Once an FPGA design is finalized and is ready for conversion to an ASIC, the designer needs to choose a conversion methodology. A retargeting methodology utilizes the RTL code for the FPGA and resynthesizes the design in an ASIC library. The remapping methodology performs a functional "mapping" between the FPGA netlist to an ASIC netlist. The selection of the conversion methodology should be based on the complexity of the design, the design performance requirements and the conversion objectives. A remapping methodology will usually result in higher design performance as a result of the enhanced interconnect loading and propagation delays of the ASIC library. Although the performance will be enhanced, it may not be optimized. A retargeting methodology should be employed when the objective is to optimize the ASIC performance and when the conversion objective involves the integration of two or more FPGAs into a single ASIC.
FPGA designs of low-to-average complexity that do not push the performance limits of the FPGA can be best converted utilizing the remapping methodology. The remapping approach is automated, it requires limited engineering resources to implement the conversion and it optimizes the overall conversion schedule. The remapping methodology is a mature process that has a demonstrated success rate in excess of 98 percent.
The benefits of remapping diminish as the complexity and performance of the FPGA increase. It can be difficult, and sometimes impossible, to achieve timing convergence when remapping a complex or high-performance FPGA. A retargeting methodology becomes necessary for designs of this nature. It is important to review your design requirements with the ASIC vendor to determine the best methodology for an FPGA-to-ASIC conversion.
Dave Locke is applying his more than 22 years of industry experience as a product-marketing manager at AMI Semiconductor's Digital ASICs Business Unit (Pocatello, Idaho). He received his bachelor's of science degree in electrical engineering from Georgia Tech (Atlanta).
© 2001 CMP Media LLC.
11/1/01, Issue # 13149, page 36.