enSpire - providers of ASIC and FPGA Design Services

Many successful systems use field programmable gate arrays (FPGAs) to achieve performance, power and time to market objectives. The well defined design flow, large gate counts, package options and design software available, coupled with ease of design modification, make them an obvious choice for all but the most demanding applications. So why consider migrating an FPGA design to ASIC?
A popular strategy is to prototype a design using FPGAs, then convert it to ASIC for full production. In this way, the design can be perfected before the high up front costs of an ASIC are incurred.
Other reasons for considering an ASIC migration are to: reduce unit production costs; improve performance (either or both speed and power dissipation); and to save board area. It is important to focus on the key objectives for the migration at the start - a vague notion that an ASIC 'is cheaper for volume production' is not an objective!
When considering potential unit cost savings, the major downside is the initial cost of performing the migration and the setup costs of ASIC manufacture, both of which must be included in the analysis. If the migration is done 'in house', new design software packages may be required and the appropriate training provided. Other cost factors may arise if significant board or system redesign work is required to accommodate the ASIC part.
Converting an existing FPGA design to ASIC can refresh a product's competitive edge by reducing power consumption and increasing speed of operation. ASIC technology offers a greater range of functionality and flexibility, which enables more aggressive design optimisation. An ASIC will not, for example, have unused gates increasing power dissipation.
A FPGA of given gate count has a limited number of package options; a non I/O intensive design may be forced into an inappropriately large package by gate count alone, wasting valuable board space. An ASIC will have a wide range of package options for a given die size.

Risk factors

Timing is a key issue for any designer. When using FPGA technology, the cell layout, power and clocking strategies are predetermined by the device chosen and the final connection of the cells is fixed by synthesis or schematic capture. Thus, it is possible to perform an accurate timing analysis post synthesis using the known device characteristics - some FPGA synthesis tools take account of timing goals automatically. Furthermore, the characteristics of a FPGA will have been verified on manufactured devices.
An ASIC design, by definition, will not have been manufactured before, although a process of known characteristics will be used. As with FPGAs, the timing properties of individual logic functions are known, but other factors influencing timing characteristics are not, particularly parasitic interconnect capacitance. These factors cannot be calculated until the final device layout is complete, thus a timing problem in an ASIC design may require the whole synthesis and layout process to be repeated. To reduce this risk, statistical timing estimation techniques are used at several stages in the layout process to try and identify potential timing problems as early as possible.
A successful FPGA design may contain asynchronous components - such as loops, one shots and delay buffers - which are unlikely to work in an ASIC migration. Unless these are identified and replaced with synchronous equivalents before migration, the timing problems they cause may not be detected until late in the migration process.
Functional verification, although part of the FPGA design process, is often incomplete for FPGA designs. For an FPGA, much of the verification can be performed using prototype devices, the cycle time from register transfer level (rtl) to device is typically only a few days. An undetected error in a manufactured ASIC will waste tens of thousands of pounds in process setup costs, and rtl to device times for ASICs are measured in weeks rather than days.

FPGA and ASIC design flows

As shown in Figure 1, the ASIC and FPGA design flows are similar up to the point of the netlist description. Entry to the FPGA process may be via schematic capture or rtl description and synthesis. Processes new to FPGA designers are testability enhancement, functional verification of the netlist, manufacturing test generation and layout. Schematic capture users may also be unfamiliar with synthesis.
The key to a successful ASIC design is an adequate functional test set, which is used to provide verification of each step in the design process. Because functional verification is repeated several times in the design flow, it is worth getting an effective test harness in place before synthesis of the design.
Code coverage and state machine verification tools help build an effective functional test at the rtl. Functional verification aids save six weeks in the typical ASIC design flow, by giving simple measures of the quantity of code checked by each test. This helps avoid the possibility of areas of the design not functioning properly after manufacture.
Synthesis processes the rtl to produce a minimal functional representation of the design which it then maps onto the available logic functions. An ASIC technology will provide the synthesis program with a richer set of logic functions than is available in a FPGA. Timing goals will only be tested against cell delays, which cannot guarantee final ASIC timing characteristics. Likewise, cells will be selected to have sufficient drive capability; ignoring the effect of interconnect capacitance. Unlike FPGA design, successful synthesis is not sufficient to ensure a device which functions as designed. Synthesis can be directed to produce area efficient or timing optimised implementation styles.
Testability enhancement (or test synthesis) is required to ensure a manufacturing test can be generated. The manufacturing test differs from functional verification in that it is used to detect manufacturing flaws (such as bridged interconnect) and not to confirm correct function of the circuit. The manufacturing test requires a fault coverage (based on the single stuck at fault model) in excess of 98% to be effective for most technologies. The usual testability enhancement is to link all registers in the design into a scan path; this technique can be performed automatically, has minimal impact on design timing and silicon area and is sufficient to enable the use of an automatic test pattern generator (atpg) to produce the manufacturing test.
The layout process attempts to minimise interconnect track length and clock skew. After cells are placed a timing analysis based on cell separation and flight lines is performed. These results are back annotated onto the netlist simulation to confirm function and timing goals.
After routing is complete, the final timing analysis is performed, using 3d field solvers to predict interconnect capacitance. Once again the revised timing information is back annotated onto the design netlist to enable functional verification. The layout process itself is checked by extracting a netlist from the final layout and subjecting that to the same functional verification process. The layout must also pass technology specific design and electrical rule checks before being passed for manufacture.

FPGA to ASIC migration flow

The entry point to the ASIC design flow must be at rtl. A complete redesign from the original specification may be appropriate if significant performance improvement or function changes are required as part of the migration. If an rtl description is not available, tools to convert a netlist to rtl can be used.
The rtl should be reviewed to check for, and eliminate, asynchronous constructs. If multiple clocks are required, these should be derived from a master clock to eliminate asynchronous behaviour between clock domains and clock skew.
Whichever starting point is used, it is essential to develop a functional test suitable for the ASIC design process. The functional test must be built using code coverage and state machine analysis tools to confirm that all of the design function is being exercised. Failure to do this could result in a timing problem, testability enhancement or layout problem going undetected.

Interface and outsourcing

The ASIC manufacturer will specify a set of 'sign off' requirements which must be completed before manufacture can commence. These requirements attempt to ensure that the ASIC design process has been adhered to and that manufacture will result in working parts.
Electrical and design rule checks ensure that process requirements are met. The 'sign off' requirements also ensure the risk of a functionally incorrect ASIC rests with the designer. All the manufacturer will guarantee is to produce parts that will meet the published electrical characteristics and pass the manufacturing test. It is the designer's responsibility to get the function correct.
It is possible to 'outsource' some or all of the ASIC/FPGA migration process. Most ASIC manufacturers will perform the layout part of the design process; indeed, as ASIC technology advances, this is the most usual mode of operation. The manufacturers have tools and engineers dedicated to performing layout for their processes. The input to this service is a design netlist and functional test. The functional test on a back annotated netlist simulation is used to 'sign off' the layout process.
Complete migration services, such as those offered by ChipExpress, SiQuest, Temic and AMI, require a FPGA netlist and functional test set. The service offered by Xilinx does not require vectors, but is applicable only to Xilinx FPGA designs. Outsourcing the conversion process removes the need to learn and obtain tools to support the migration process, but does not build in house design expertise. But if a fast migration is what you are looking for, then outsourcing is most appropriate.

Author profile:

Andy Kayley is senior development engineer with TransEDA.

Steps to successful FPGA to ASIC migration

The following activities are required to promote a successful migration:
* Define the objective of the migration and evaluate possible knock on effects and costs.
* Review the design to be migrated - ensure it can be made synchronous.
* Generate an effective functional test set - use code coverage and state machine analysis tools to validate.

If the aim is to develop a regular migration path to ASIC, the following steps are needed:
* Invest in ASIC synthesis, automated test enhancement and ATPG tools.
* Invest in ASIC design training.
* Use the ASIC manufacturer's layout and timing analysis services.

For a fast, one off migration, consider:
* Outsourcing the whole migration.

This article, written by Andy Kayley of TransEDA, was first published in the 21 March 2000 issue of New Electronics and is reproduced here with the permission of New Electronics and TransEDA. Copyright New Electronics 2000. Click here for more information on New Electronics. Click here for more information on TransEDA.

If you have any questions or comments please email webmaster@enspire.co.uk.