Published on August 21st, 2008

Converting FPGA Designs

Colin BaldwinMotivation

System designers often find the reprogrammability of FPGAs to be very helpful during system development. At the same time, when those same systems go to volume production the size, power, and cost of the FPGA itself often pose a design problem. One common solution is to develop the system design using RTL that is retargetable to either an FPGA or ASIC, so that once the development phase has completed an ASIC can be quickly made for use production. System designers looking to have the flexibility of moving their design between FPGA and ASIC will need to consider several technical areas during the design phase to make the design as portable as possible.

The top level of the customer’s design (the Design Hierarchy) typically connects the customer’s functional top level with the physical elements on the device such as IO buffers and PLLs. This will have to change when moving from an FPGA to an ASIC to reflect the changes in the physical IO buffers and clock sources available with the new technology. This can be minimized by maintaining the functional top within an RTL subroutine, leaving no logic and only the IO and clock connections as the elements at the device top. Also, the clock create logic should be kept within the device top level, so that any changes needed there do not require modification inside the functional top.

Design Constraints

All ASIC methodologies, structured or standard cell, require complete and accurate design constraints to control logic placement. Also, since direct netlist conversion is no longer common due to the inherent performance limitations for large designs, proper constraints are required also for synthesis. A fully constrained design requires all of the device logic to be fully synchronous, meaning that there cannot be asynchronous paths inside the design (e.g. ring oscillators). Note that multi-cycle paths are fine.

Constraining a design properly is made more difficult for designs with:

  1. Large numbers of clock domains, such as seen when SerDes are used
  2. Designs with source synchronous interfaces, such as DDR or DDR2
  3. Designs that use multiple functional modes, where different clocks might be present on the same clock tree

Also, tools like Synplicity’s Synplify, the de facto standard for large FPGA synthesis, allow the user to set a default frequency for all otherwise unconstrained paths. Therefore, a partially constrained design will create, without any error flags, a complete and working design in the lab. However, those same constraints would not be sufficient for an ASIC. To work around this, customers needed to actively check for unconstrained design paths in the design.

Startup Latency

Note that FPGAs, at power-up, require some time to load in the input programmation file and setup the device. ASICs do not require this function and therefore suffer no latency. For some system designs, the lack of latency in the replacement ASIC can be a problem. This needs to be reviewed by the customer.

Memory Initialization

FPGA programmation files also set the initial RAM values for an FPGA. This is contrary to the situation for ASICs where the initial RAM state is unknown and initialization is required after power-up. Therefore, customers looking to port designs from FPGA to ASIC need to design so that they do not rely upon RAM bit settings without first manually initializing those RAMs.

Design for Testability

FPGA designs have, by definition, no testability in the design itself. During conversion to an ASIC the design must have test inserted using DFT tools. To plan for this test insertion, customer’s should avoid manually inserting clock gating cells in their low-level logic. Also, resets should be generated at the top level to allow for their deassertion synchronous to a top level core clock.

Memories

One side-effect of FPGA architecture is that memory is available in both large amounts overall and in a distributed fashion with lots of small RAMs spread across the device. Designs which optimize around the available FPGA RAMs will be less optimal as ASICs since ASICs favor fewer, larger RAMs since that eases routing and floorplan congestion, allowing for greater density and performance.

Another issue is that the FPGA RAMs come in a very few discrete sizes. Customers needing a 4Kb RAM may have to use a much larger 18Kb RAM in the FPGA. That is fine in the FPGA as long as the design fits, but in an ASIC we can trim out the wasted RAM area by making sure that only a 4Kb RAM is instantiated. To do this, the logical RAM wrapper (e.g. 4Kb) should be separated from the physical RAM instantiation (e.g. 18Kb in FPGA and 4Kb in ASIC). By placing the physical memory instances in a file, the designer can maintain one design with two sets of memory files that will work in either technology. By simple replacing the file containing the physical FPGA memory instance definitions with a new file containing the compiled ASIC RAM instance definitions the design can be made ASIC ready.

IP Cores

While the high availability of FPGA IP from Xilinx and Altera is convenient when building an FPGA, it can also become an obstacle when porting the design to an ASIC. Embedded processors like Microblaze and NiosII are not available in the ASIC world. Other Xilinx and Altera cores may require block-level replacement, if the license does not permit reuse in an ASIC. In general, all FPGA IP cores will require a separate license for the ASIC version.

Package

With the flexibility of an ASIC to create a custom floorplan and pin placement, combined with custom substrate design, an ASIC pinout can normally be created that functionally matches the FPGA. Note that actual buffer signal integrity performance will be different as the device creating the signal has changed and is being built using different but similar technology. The voltage levels for those buffers, as well as the core voltage supplies, needs to be paid attention to.

Performance and Power

ASICs are substantially faster than FPGAs, but care needs to be taken in a couple areas. First of all, users should be careful about optimizing the use of the FPGA hardware DSP blocks. These blocks are standard cell ASIC blocks at 90nm (Stratix II/Virtex-4) or 65nm (Stratix III/Virtex-5) and have the expected extreme level of performance. A typical ASIC conversion takes advantage of the architectural performance advantages of ASICs and drops 1-2 technology nodes in the conversion while maintaining the same overall system logic performance. Therefore, a Virtex-4 conversion might be built as an 0.18um or 0.13um ASIC. If the FPGA design relies upon the optimized hardware DSP block performance to achieve the needed system bandwidth, the ASIC may struggle to achieve the needed bandwidth using DSP blocks available in the slower technology. Also, note that while FPGAs are speed-binned, ASICs are not. That is why an FPGA 90nm DSP block will be faster than even a 90nm ASIC built in the same process - the latter is not binned for performance.

Another area for care is with the core power supplies. A shift in process technology may require changing the core power supply voltages to the device. Also, although ASICs use considerably less power than FPGAs, care still needs to be taken to make sure that the FPGA pinout, if matched precisely, provides sufficient power and ground connections for the ASIC device.

Summary

Through careful system design it is possible to develop a device that is both FPGA-ready and ASIC-ready without burdensome extra effort. By making the changes up front to allow retargetability, the designers will enjoy maximum flexibility as they prepare for high volume production and spend less effort overall in getting there.

About the Author

Colin Baldwin is Open-Silicon’s Director of Business Development. He has 15 years of ASIC design and sales experience with Texas Instruments, Arrow Electronics, and Open-Silicon. Currently he is focused on marketing and business development activities for Open-Silicon. Mr. Baldwin received both BEE and MSEE degrees from Georgia Tech.

Send your comments to jkobylecky@extensionmedia.com and our Editorial Director at jblyler@extensionmedia.com.


Tech Videos

©2019 Extension Media. All Rights Reserved. PRIVACY POLICY | TERMS AND CONDITIONS

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.