Design for portability is a valuable technique for engineers targeting consumer markets, seeking a cost-effective transition from an FPGA platform used for rapid development and prototyping to create price-competitive products that will win sales in fast paced consumer market.
Design Conversion for Marketing Objectives
FPGAs (field programmable gate arrays) provide a powerful tool for designers seeking to satisfy consumer demands for complex, multi-functional products. The FPGA’s fast development cycles accelerate the learning and debugging processes, which serves demands for short time-to-market that is characteristic of the consumer space. Initial product development using an FPGA solution also facilitates entry into new and untried markets at lower cost and dramatically reduced risk.
But the intense price pressures that characterizes most consumer electronic markets, does not match with the relatively high costs of FPGA silicon and packaging. Power consumption in FPGA’s can be also be high, compared to that of an application specific implementation. This can be a significant drawback, particularly if the end product is battery powered.
A number of solutions are available to product developers who need to reduce the cost of an end product prior to launch or after the initial concept has been proved in the market. There are several FPGA architectures, which have been optimized for lower cost and power consumption, as well as alternative “hard” FPGA conversion technologies. Porting the design to a structured ASIC, platform ASIC or cell-based ASIC, on the other hand, may unlock valuable savings in die size, package cost, power consumption and may provide improved performance.
Recompiling a design to target an alternative FPGA architecture can be accomplished quite easily, using desktop FPGA place and route tools. Migrating to a hard FPGA technology usually involves closer liaison with the FPGA vendor, but little or no electronic redesign work. As far as FPGA-to-ASIC conversion is concerned, the two structures embody very different philosophies for timing generators, clock hierarchies, memory structures, internal signal routing, and I/O pinning. Of course, much of the conversion effort is automated, which holds out the promise of quick and easy conversion. In practice, the time and cost to complete the conversion is heavily influenced by the quality of the design.
Systems incorporating significant quantities of asynchronous design, blocks of FPGA-specific IP, or timing and memory implementations that are unsuitable for ASIC structures are likely to slow the conversion process. Conversely, by paying attention to these issues early on in the FPGA design cycle, engineers can eliminate potential barriers to conversion before they are ever encountered.
In fact, the differences between available FPGAs and complementary ASIC technologies, including standard cell and low-cost structured ASICs, go some way beyond the fundamental structural differences. Other issues include configuration and start-up of the device when in circuit, fabrication technology, packaging and I/O, and IP licensing. Design for portability takes all of these aspects into account, and establishes a best practice approach when converting a prototype FPGA design to an ASIC.
Design for portability can minimize redesign and multiple iterations, which demand considerable human intervention in the automated design flow, and can therefore save days or even weeks from a conversion project. Creating a portable design within a suitable parallel design flow that supports concurrent development of the FPGA and the ASIC delivers cost and time-to-market advantages, while preserving the flexibility to make design changes quickly and economically right up to satisfactory completion of the FPGA design.
Structural Differences
Among the fundamental structural differences between an FPGA and ASIC, clock implementations, timing generators including phase locked loops (PLL) and delay locked loops (DLL), and system timing parameters have to be designed to perform satisfactorily in both implementations. As a rule, asynchronous design is the enemy of portability, because system timing performance cannot be predicted when the design is re-targeted to a different technology. Inevitably, a large system will require multiple clock domains, but care must be taken from the outset of the FPGA project to ensure that data transfers between domains are properly synchronized. A handshake protocol or FIFOs may be used, for example. Gated clocks, on the other hand, can be particularly problematic, and may introduce glitches on clock lines. Although these bring benefits in low power designs, they should be avoided wherever possible as a rule of design for portability.
System timing performance can vary considerably between an FPGA and an ASIC. Since timing ambiguities are not tolerable in an ASIC design, documenting system timing requirements is very important if the design is to be easily portable from FPGA to ASIC. Accurate and comprehensive documentation is essential input data for ASIC development tools, and will allow the ASIC developer to complete the conversion quickly. When using FPGA place and route tools, the recommended technique is to avoid specifying excessive timing constraints. Hence, in an FPGA, for example, the clock-to-out times can be faster than is required by the system. By referring to the documentation specifying actual timing requirements, the ASIC design can be implemented in a lower-cost process capable of meeting the system timing parameters. This can deliver a further valuable cost saving for the project.
In addition to system timing budgets, the clock management specifications and any asynchronous timing issues should also be fully documented, as well as the specification requirements, 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.
Documentation of the configuration and initialization processes for the FPGA is also essential, to allow the ASIC design to minimize the impact on system software. For example, where initial configuration of the FPGA is performed under software control, removing that routine from software can be complex and time consuming, and may require re-qualification for parts of the software. With the benefit of proper documentation, describing the mode of configuration and usage of the configuration logic, the ASIC can be designed to emulate the FPGA’s behavior and thereby eliminate software changes.
The techniques for implementing and controlling memory vary considerably from an FPGA to an ASIC. An extra wrapper might need to be written to ensure the ASIC and FPGA memories behave identically. Full documentation of the memory and how it is used by the system are crucial to a successful conversion. An ASIC also tends to support larger on-chip memory arrays than an FPGA architecture.
Avoiding the use of functions and IP that are specific to the chosen FPGA is also a basic tenet of design for portability. Quite apart from the structural differences between an FPGA and an ASIC, licensing restrictions may prevent implementation of the same IP in both architectures. Third-party IP or equivalents supplied by the ASIC vendor can provide a safer solution both from a technical and legal standpoint. AMI Semiconductor, for example, maintains large libraries of mature and leading-edge IP, designed specifically for implementation in proprietary ASIC families.
Packaging and Process Considerations
Because an ASIC typically performs faster with lower power and consumes fewer I/O than a system design implemented in an off-the-shelf FPGA, the ASIC conversion process gives designers extra flexibility when choosing a package technology. A drop-in replacement for the FPGA can be achieved, using a structured ASIC architecture such as the AMI Semiconductor XPressArray® and XPressArray-II® technologies. Because the ASIC can easily meet system performance parameters within an identical package, this route allows engineers to achieve a rapid and low-cost solution with no board changes required.
If, on the other hand, there is an opportunity to update the board at the same time as moving to an ASIC, then the ASIC can often utilize a smaller less expensive, industry standard package. Today’s 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 costs can be reduced dramatically. Although large FPGAs in BGA packages with over 1100 I/Os are now readily available, designers still tend to choose these larger devices more for the on-chip resources than to meet a real need for such vast numbers of pins. Hence, ASIC conversion brings the opportunity to implement a lower cost package with fewer I/Os, if required. AMIS, for example, has well-developed packaging solutions, with many industry standard package technologies available. When considering the conversion in terms of the available packaging choices, it is also best at this point to employ a custom JTAG implementation for the ASIC using only the I/O required for the functional implementation.
The choice of process technology is closely linked to the issues driving package selection. Where FPGAs tend to exploit the latest geometries to support modern system frequencies with FPGA fabric logic, an ASIC can typically match that performance while using a more mature technology. This can deliver cost savings, and the lower leakage current also contributes to a reduction in overall power consumption. A recent project by AMIS, to convert a high definition video scaler implemented in an FPGA fabricated on a 90nm process was able to port the design to a 180nm ASIC and deliver savings in excess of 75 percent of the bill of materials (BOM) cost. Moreover, the ASIC met the timing requirements and signal integrity requirements in PQFP and PBGA packages, even though the customer had encountered timing and package signal integrity issues with the 90nm FPGA.
Parallel Design Flow
Some FPGA-to-ASIC conversions are born out of an emergency situation, for example where a product has met with unexpected success. But when the end product is aimed from the beginning at a consumer market, a sudden demand for large volumes should come as no surprise to the product management or design teams. Plans for a rapid conversion to ASIC should be built into the product roadmap. Alongside the electronic design principles necessary to create a portable design, an effective design for portability approach will also encompass parallel development of both the FPGA and ASIC designs. As the RTL is developed and targeted to the FPGA, it is also provided to the ASIC vendor for review and analysis. The PCB can also be developed at this time to handle the large power hungry FPGAs with a path for migration to a smaller more efficient package for the ASIC.
Importantly, this approach retains the flexibility to quickly modify the FPGA design, and go through as many design iterations and debugging cycles as the project timeline will allow, before committing to hardware. As the FPGA project progresses, major changes to the design can be quickly run through the ASIC flow to ensure scripts for DFT and timing do not require modifications. The final timing convergence and physical design flow for the ASIC are not invoked until the product is ready to move into the ASIC-based phase of its lifecycle.
Toolset Streamlines Conversion
Figure 1 illustrates the flow for conversion of an FPGA design to a structured ASIC, cell-based ASIC or platform ASIC. In contrast to most FPGA development tools, which are available off the shelf and can be used on a desktop PC after rudimentary training, ASIC design tools are more complex, more powerful and require more expertise if they are to be used effectively. As an example, AMIS has spent some 20 years refining its proprietary conversion tool, NETRANS®, including continual enhancement of its abilities to analyze FPGA designs for common barriers to conversion to return a quick assessment of any design presented. Fundamentally, NETRANS and the AMIS conversion flow replaces the FPGA primitives with ASIC primitives, and performs logic equivalence checking for system timing verification and to identify possible errors during the translation and test insertion. Moreover, logic equivalence checking decreases the need for extensive simulations of the translated netlist. NETRANS also performs circuit optimization including tri-state to multiplexer mapping, and transforms the logic to yield a better conversion efficiency.
Conclusion
The cost advantages of converting an FPGA to an ASIC can be of little concern to design teams embarking on a new consumer product. When the target is a fast-moving and fickle market, it is little wonder that proving the concept takes precedence. But this is precisely the time when the foundations for low-cost, high-volume production can be laid to the maximum effect.
The process of choosing an ASIC vendor, making contact, and sharing information about the design constitute the first stages of an effective strategy to achieve design for portability.
About AMI Semiconductor
AMI Semiconductor (AMIS) is a leader in the design and manufacture of silicon solutions for the real world. As a widely recognized innovator in state-of-the-art integrated mixed-signal and structured digital products, AMIS is committed to providing customers with the optimal value, quickest time-to-market semiconductor solutions. Offering unparalleled manufacturing flexibility and dedication to customer service, AMI Semiconductor operates globally with headquarters in Pocatello, Idaho, European corporate offices in Oudenaarde, Belgium, and a network of sales and design centers located in the key markets of North America, Europe and the Asia Pacific region. For more information please visit the AMIS Web site at www.amis.com.
