Decisions made during a product’s FPGA design phase can significantly complicate the process of converting the product to a low cost ASIC for volume production. Therefore it is important to consider issues that will impact conversion during the FPGA design phase. This will allow the ASIC implementation to be done in a timely fashion with a minimum amount of effort. Some of these issues are as follows:

Plan for a potential voltage change (FPGA – ASIC)

Design the system board to allow for a voltage change between the FPGA and ASIC implementation. FPGA devices are built in high-end technologies to allow for high performance and large gate counts. Often the same function and performance can be accomplished in an ASIC using an older technology node. This may require a higher core operating voltage. Design the printed circuit board (PCB) with an isolated power supply for the FPGA core. This will allow a simple regulator or resistor change to switch to a higher core voltage for the ASIC. A cost savings can be obtained by enabling the use of a less expensive technology node.

Plan for an ASIC JTAG implementation

Another board level issue to consider is the JTAG implementation. Often times an FPGA design does not use all of the available I/O for functional requirements, but all I/O are included in the board level JTAG implementation. If unused I/O must then be maintained in the ASIC implementation to match the original JTAG structure, the ASIC die size may increase and additional cost savings can be lost. It is best to employ a custom JTAG implementation for the ASIC using only the I/O required for the functional implementation.

Provide complete design documentation

The amount and accuracy of design documentation can have a great impact on the effort required to convert an FPGA to an ASIC. During FPGA development, the following should be documented in detail: specification requirements, system timing budgets, asynchronous timing issues, clock management specifications, I/O standards, IP requirements, and any major design issues. Providing this documentation to the ASIC development team will greatly reduce the engineering burden required to recreate these details. Discipline in this regard can pay big rewards during the conversion process.

Specify system timing requirements vs. FPGA timing capability

When designing an FPGA, keep in mind the difference between FPGA-specific I/O timing capability and system level timing budgets required to ensure system operation. Many FPGAs can deliver faster clock-to-out times than required by the system performance goals. If a designer documents the system clock-to-out requirements for the ASIC conversion rather than the FPGA clock-to-out capability, the conversion process can be simplified and an older ASIC technology node may be used, thereby resulting in additional cost savings. Additionally, the designer may be able to reduce the I/O currents, thereby improving board level signal integrity.

Develop robust design verification suites

Adequate design verification suites are key to successful FPGA-to-ASIC conversions. The nature of FPGA design allows designers to address a missing timing constraint or functional bug by quickly reprogramming and retesting the FPGA. In the ASIC world, the cost and span of a mistake is much greater to repair. Therefore, it is extremely important to have full functional verification suites available, including simulation test benches and STA constraints, particularly for memories and IP blocks that will be replaced in the ASIC implementation. These verification suites can then be ported to the ASIC environment to ensure the conversion is correct before expensive hardware is built.

Follow industry RTL coding standards

RTL coding style largely determines several key aspects of the design, including architecture, testability limitations, area, timing performance, and power dissipation. The RTL coding style may also cause RTL and gate-level simulation mismatches, since logic simulators and logic synthesizers may interpret the RTL code differently. For all of these reasons, it is best to code the design RTL to meet industry standards (see also the Reuse Methodology Manual by Michael Keating and Pierre Bricaud, Kluwer Academic Publishers, 1999, IEEE P1364.1 “Draft Standard for Verilog Register Transfer Level Synthesis”.) It is also highly recommended that the RTL code be verified using one or more of the RTL rule checkers available in the marketplace.