Transfer from FPGAs for prototype to ASICs for production

by Terry Danzer and Cale Entzel , TechOnline India - November 29, 2011

Designing a new product in an FPGA allows for design modifications to be made quickly in hardware. Once the design code is stable and the product is ready for production, a migration from an FPGA to an ASIC can cut the production unit cost by up to 50%.

Field-programmable gate arrays (FPGAs) are a valuable technology for designing and prototyping digital logic into today’s applications. However, high FPGA unit cost can sometimes prohibit higher volume production. Several alternatives exist for transferring a digital design, implemented with an FPGA, into higher-volume production.

Low-cost solutions such as structured application-specific integrated circuits (ASICs), cell-based ICs, and gate arrays offer higher performance, lower power consumption, higher levels of integration, and better response to radiation effects. The idea of migrating an FPGA design into an ASIC can be overwhelming to a design team, but careful planning and partnering with an experienced ASIC vendor can significantly ease the process.

Designing a new product in an FPGA allows for design modifications to be made quickly in hardware. Once the design code is stable and the product is ready for production, a migration from an FPGA to an ASIC can cut the production unit cost by up to 50%. The low non-recurring engineering (NRE) charges associated with a mid-range ASIC solution coupled with a much lower unit price point make this strategy a powerful tool in achieving low overall expense, giving users a competitive cost advantage in the market.

To help ease the migration process, designers must consider several items during the initial design phase:

* Today’s designs are larger, more complex, and contain more specialized intellectual property (IP) than ever before.     

* Careful selection of IP early in the design phase is essential.

* Developing the FPGA and ASIC in a parallel design flow will help speed up the migration process.

* Planning for portability to an ASIC from the beginning will help shorten the time to market and decrease development cost.

* Good coding practices such as the use of synchronous design techniques will enable the architecture to be ported across many different technology platforms.

* Documentation is essential. If a little time and effort is used in the early stages of the design, the migration will require minimal engineering resources.

The migration can result in a drop-in replacement alternative that is footprint compatible to the FPGA. If the system can tolerate packaging and footprint flexibility, designers can attain further cost reduction.

Complex systems may require several FPGAs to prototype a complete system-on-a-chip (SoC) design. ASICs offer better gate density than FPGAs, as well as better core performance. This allows multiple FPGAs to be combined into a single SoC ASIC, saving expensive board real estate. If the architecture will not allow for full integration, a multi-personality ASIC can be produced to emulate the different FPGAs, allowing for a direct functional drop in replacement. This will optimize cost savings by reducing the ASIC tooling charges.

Parallel design flow

Parallel design flows allow the designer to compress the ASIC development schedule (see figure 1). Prototyping in an FPGA enables engineering teams to verify functionality prior to ASIC implementation. It also provides a path for early hardware and software validation. In this design flow, the register transfer level (RTL) is developed and targeted to the FPGA and provided in parallel to the ASIC vendor for review and analysis. This allows the ASIC vendor to offer recommendations and modifications to the code to enhance robustness. Timing scripts and clocking architectures are developed for both the FPGA and ASIC. Package selection for the ASIC is determined along with signal integrity and power dissipation analysis. The printed circuit board (PCB) can be developed at this time to handle the larger power-hungry FPGAs with an identified path for migration to a smaller, more efficient ASIC package.

 

 

Figure 1: In a parallel design flow, the RTL is developed and targeted to the FPGA and simultaneously provided to the ASIC vendor for review and analysis.

One option is to place the ASIC design on hold pending the final FPGA verification, or ramp-up to production. More commonly, the ASIC team begins logical design activities once the base architecture is fixed, IP requirements are defined, and pin out is fixed. Early ASIC development may also include development of the design for test (DFT) structures, script development for static timing analysis (STA), initial floor planning, and cell placement. Any major changes to the design can be quickly evaluated in the ASIC flow to ensure that the scripts for DFT and timing do not require modification. The final timing convergence and physical design flow wait until the design is ready to move to the ASIC.

Design for portability

Decisions made during the FPGA design phase can significantly complicate the process of migrating to a low-cost ASIC for volume production. It is therefore important to understand any risks that will impact conversion during the FPGA design phase. This will allow the ASIC implementation to be executed in a timely fashion with a minimum amount of effort.

Intellectual property (IP)

If a migration from FPGA to ASIC migration is a possibility, the FPGA designer needs to closely evaluate all IP needs. One tempting option is to use proprietary software provided by the FPGA, often without additional license agreements or cost. Although such software holds out the prospect of simplifying implementation, use of this type of IP may limit the designer from migrating the IP into an ASIC due to complications in maintaining functional and cycle compatibility. Designing with IP independent of technology or platform will help prevent this scenario. IP license agreements should be negotiated, where feasible, to allow implementation into either an FPGA or an ASIC. This will permit an easy migration to any technology. IP decisions should also be made based on the use of standard interfaces. For advanced SoC designs, soft stack layers are available that target both the FPGA and ASIC PHYs while using the same application interface.         

Plan for a potential voltage change

Design the system board to allow for a voltage change between the FPGA and ASIC implementation. FPGA devices are built in higher-end technologies to meet performance and gate count requirements. Often the same function and performance can be accomplished in an ASIC using an older and less expensive technology node. The change in technology may require a different core operating voltage. Moving to an ASIC with the same voltage as the FPGA can limit your options to improve performance and may limit cost savings.  Design the PCB with an isolated power supply for the FPGA core. This will allow for a simple regulator or resistor change to enable the ASIC core voltage requirement.

Plan for an ASIC JTAG implementation

Joint Test Action Group (JTAG) requirements are another board-level issue to be considered. Often, an FPGA design does not utilize all of the available I/O, but all I/O are still included in the board-level JTAG description. If unused I/O must be preserved in the ASIC implementation to match the FPGA architecture, the ASIC die size may increase and additional cost savings can be lost. It is best to instantiate JTAG specific to the ASIC using only the I/O required for the design. A boundary-scan description language (BSDL) file representative of the ASIC implementation can be provided for board-level testing.

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, designers should document the following in detail: system timing budgets, multi-cycle and asynchronous timing paths, system timing margins, clock frequencies, clock and reset diagrams, I/O standards, IP requirements, and any major design attributes. Providing this documentation to the ASIC development team will greatly reduce the engineering burden required to recreate these details and 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 application. If a designer documents the clock-to-out requirements for the system rather than the FPGA clock-to-out capability, the conversion process can be simplified and an older ASIC technology node may be used to increase cost savings. Additionally, the designer may be able to reduce the I/O drive strengths, thereby improving board-level signal integrity.

Additional design considerations

Develop robust design verification suites

The nature of FPGA development allows designers to address a missing timing constraint or functional bug by quickly reprogramming and retesting the FPGA. In an ASIC environment, the cost and time spans associated with similar mistakes are much greater. It is thus extremely important to have full functional verification suites available, including simulation test benches and STA constraints, particularly for IP blocks that will be replaced in the ASIC implementation. These verification suites can be ported to the ASIC environment to ensure the conversion is correct before silicon 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 result in RTL and gate-level simulation mismatches, since logic simulators and logic synthesizers may interpret the RTL code differently. It is best to code the design RTL to meet industry standards.[1] The design team should also verify the RTL code using one or more of the RTL rule checkers available in the marketplace.

Synchronous design techniques

A synchronous design can be ported to any technology node, providing it meets system performance requirements. A completely synchronous design is one that has a single master clock and a single master set/reset driving all sequential elements in the design. All input signals are synchronized to the clock so they never violate setup and hold times. Not many designs meet this rigid definition and often designs require multiple clock domains. Great care must be taken to synchronize data transfer between these domains by using either a handshaking protocol or first-in-first-out (FIFO) techniques. Gated clocks should be avoided unless low power requirements drive their implementation. If gated clocks must be used, designers should work closely with the ASIC vendor to prevent any potential glitches being generated on the clock lines. It is also best to think about design for test. Avoid the use of latches and combinational feedback loops and provide the ability to reset all sequential elements.

Packaging

When designing in an FPGA, it is important for the design team to review package requirements and board layout. FPGAs use significantly more power than ASICs and may require a higher-performance package. The FPGA is also less efficient with core logic. If the design is placed into a larger FPGA family to accommodate the core logic requirements, the design may fit into a smaller pin count package once it is migrated to an ASIC. Package costs track with ball count and substrate performance. If the design can utilize a lower-performance industry standard package with lower ball counts, the device cost can be reduced dramatically. A drop-in replacement package can usually be provided, which will minimize any board rework and provide no or limited change to the system for software and hardware.

Information required for conversion

The information required by the ASIC vendor varies depending on the technical requirements of the design. In general, the more information provided, the better picture of the design the ASIC team will have. Minimum requirements include:


* Intended ambient operating temperature
* Desired core voltage
* Pad voltage(s)
* Specification of inputs, outputs, and bi-directional signals
* Identification of transceiver requirements such as type (LVDS, HSTL, SSTL, LVPECL), speed, and version
* Memory (RAM, ROM) requirements
* IP requirements (all relevant IP information such as name, brief description, quantity, speed, and compatibility to existing standards, vendor, and licensing requirements)
* Usage and purpose of timing IP blocks such as DLLs or PLLs
* Package type
* Design format (RTL, Verilog, VHDL, FPGA)
* Timing requirements
* Power Budgets

 

FPGAs provide a fast time-to-market and an efficient prototyping tool, but the high cost of mid-to high-end FPGAs can be prohibitive for volume production. With proper planning during the development phase, migrating the FPGA to an ASIC can be completed quickly without significant additional engineering effort.

References

1. Michael Keating & Pierre Bricaud, Reuse Methodology Manual, Kluwer Academic Publishers (1999).

About the authors:

Terry Danzer is Digital ASICs Product Marketing Manager and Cale Entzel is Systems Architect at ON Semiconductor.

Comments

blog comments powered by Disqus