Nikkei Electronics Asia -- February 2007
Monthly Special
Choosing Appropriate Hardware IP for FPGA-ASIC Conversion

E-Mail Article
Tweet This
Digg This
Share this with friends on Facebook
Buzz Up!
Jan 26, 2007 18:15 Nikkei Electronics Asia
As with any complex technology, embedded systems developers have many factors to consider when selecting a design partner in today¡Çs semiconductor market, particularly if planning to convert FPGAs to ASICs.

Intellectual property (IP) is one of the most important considerations. Selecting the right IP can make a sizeable difference in total cost of ownership. In addition to determining the type of IP required (SerDes, USB interfaces for computing, Ethernet MACs, 32-bit RISC processors, and so forth) one must consider the portability and reusability of the IP. When targeting an FPGA for conversion to an ASIC, one must also consider how compatible the IP is with both the FPGA and the ASIC. This compatibility is especially important for critical pieces of IP such as I/O, memory, and timing generators. Finally, it is necessary to consider numerous factors when selecting third-party IP, including compatibility, maturity, cost, legal issues, verification, quality, and the vendor itself.

This article describes the choices in planning ahead for a successful project, specifically on FPGA-to-ASIC conversions.

The IP market grew 21% from US$1.06 billion in 2003 to US$1.27 billion in 2004, according to market statistics. The growth was fueled by microprocessors and high-speed serial interfaces for both connectivity and memory. Multi-gigabit SerDes (serialization/deserialization) applications are becoming more prominent in the market. Some of the applications driving the increase in SerDes usage are shown in the Table.

Complex IP such as SerDes and double data rate (DDR) physical interfaces (PHYs) are more difficult to port from one technology to another, making them critical elements in the decision-making process during an FPGA development, particularly if the end goal is to cost-reduce the device in the long term.

IP Portability
IP macros can be characterized as soft, firm, or hard depending on the degree to which the macro is optimized for a particular semiconductor fabrication process.

Soft macros are delivered in synthesizable RTL, so they are more flexible than firm or hard macros and are not specific to any manufacturing process. Soft macros have the disadvantage of being somewhat unpredictable in terms of performance, timing, area, or power. Soft macros carry greater IP-protection risks because RTL source code is more portable (and therefore, less easily protected) than either a netlist or physical layout data.

Firm macros are delivered in netlist format and have been structurally optimized for performance and area using a specific semiconductor fabrication library. Not surprisingly, firm macros offer a compromise between soft and hard macros. They are more flexible and portable than hard macros, yet more predictive of performance and area than soft macros. Protection risk of firm macros is similar to that of soft macros.

Hard macros are optimized for power, size, or performance when mapped to a specific chip technology, and are usually delivered in GDS-II format. Being process-specific gives hard macros the advantage of having deterministic timing, area, and power-consumption characteristics. The downside of being process-specific is that hard macros are not portable. Protection risk is much less than soft or firm macros because the macro is specific to a particular technology.

IP portability is one of the most important issues in FPGA-to-ASIC conversion. The IP selected for the application should be supported for both the FPGA and the eventual ASIC device. Usually the best solution is to select a third-party IP vendor that licenses an RTL version of the macro allowing the designer to use that IP for both the FPGA and the ASIC. This is especially true for processor macros. Processor macros, unlike other types of hardware IP, have a greater impact on overall development of the application because they influence both hardware and software design. For this reason, it makes sense early in the development cycle to adopt a processor that can be used in both the FPGA and the ASIC.

Third-Party IP
When using third-party IP, several issues have to be considered:
• IP compatibility;
• IP maturity;
• Costs;
• Legal issues;
• IP verification;
• Reputation and experience of the IP vendor.

IP Compatibility
The four levels of IP compatibility are: function compatibility, I/O compatibility, software compatibility, and cycle-to-cycle compatibility. Third-party IP that is functionally compatible will work in an application but may require some changes to the system. Glue logic may be required to integrate the functionally compatible IP into the hardware, and software used to control and configure the IP may also need to be modified. I/O compatible IP is also functionally compatible but has the added advantage of a compatible I/O interface. This interface allows the IP to be integrated into the hardware without any additional glue logic. Software compatible IP has common register addresses so that the application software can be easily ported when converting from an FPGA implementation to an ASIC implementation. This compatibility is particularly relevant for processors and processor peripherals that have software-addressable registers.

Cycle-to-cycle compatible IP reacts to stimulus in exactly the same way on every clock cycle in both FPGA and ASIC implementation. Cycle-to-cycle compatible IP is truly drop-in-replaceable, requiring neither hardware nor software changes to the rest of the system. It is particularly important to maintain FPGA compatibility in the conversion ASIC with core components, such as memory interfaces (such as DDR SDRAM interface), I/O, and timing generators. These core components are required in most applications and are generally designed as hard macros, making them process specific.

DDR SDRAM is a common memory interface used in today¡Çs applications. DDR SDRAM differs from traditional SDRAM by transferring data on both the rising and falling edges of the clock. A DDR SDRAM interface is comprised of both a PHY and a controller. The DDR PHY is timing critical and thus is usually implemented as either a firm or hard macro. The DDR controller is not as timing critical but often requires more flexibility and is usually implemented as a soft macro. Proven interoperability between the PHY and controller is a key characteristic to look for when selecting a solution for both an FPGA and ASIC implementation.

In addition to supporting various buffer types, voltage levels, and I/O standards such as GTL, GTL+, HSTL class 1, 2, 3, & 4, LVPECL (input), PCI-33, PCI-66, PCI-X 133, SSTL2 Class 1 & 2, the conversion ASIC should also support digital controlled impedance (DCI). High-speed I/O standards require printed circuit board (PCB) traces with specific impedance, usually with termination resistors of precise values on each I/O pin to match the trace impedance. These resistors eliminate reflections and ringing that degrade signal integrity and affect system performance. However, a PCB design is complicated by increased device I/O counts, which could mean additional board layers, higher board cost, and longer development time. DCI eliminates the need for board-level termination resistors and simplifies PCB design.

Timing generators are another important consideration when converting from an FPGA to an ASIC. For instance, in order to emulate the digital clock manager (DCM) features in a Xilinx FPGA, the DCM must support clock-phase shifting (fixed and variable), clock doubling, clock division (extended range), and quadrature clock generation.

IP Maturity
All IP has bugs. There is no such thing as perfect IP. However, the more mature an IP core is, the less likely a bug will surface in a similar application. Ideally, mature IP should be production proven in numerous applications with a minimal number of bug fixes over the last 12 months. Suppliers may classify their IP, based upon the maturity level of the IP. For example, a supplier may classify IP as alpha (not yet proven in silicon), beta (proven in test silicon but not production proven), and qualified or production-ready IP.

Other Considerations
Designers are naturally interested in reducing the cost of applications but there are many things to consider. Total cost of ownership includes more than licensing fees, support and maintenance fees, and royalties; it may also include unforeseen expenses, such as the added cost of dealing with proprietary or immature IP.

Even if you¡Çve chosen synthesizable IP for all of the application¡Çs functions one may still need to consider legal issues when converting the FPGA to an ASIC. FPGA vendors typically produce their own IP and will not license it for an ASIC conversion. ¡ÈFree¡É proprietary IP from an FPGA vendor may make the conversion more expensive because of increases in non-recurring engineering (NRE) costs and development time (design span). A simple cost versus unit volume analysis of ¡Èfree¡É FPGA IP, combined with the silicon cost of FPGAs versus the cost of commercial IP, combined with the silicon cost of ASICs, quickly illustrates that ¡Èfree¡É FPGA IP may actually be quite expensive. The solution is to use third-party IP that can be used in both the FPGA and ASIC.

It¡Çs also important to evaluate the level of verification performed on the IP. The verification environment should be regressive, self-checking, portable and well documented. The level of code coverage and functional coverage should be specified as well as the method for timing verification. For timing critical IP, such as SerDes and DDR PHYs, it¡Çs also important to review characterization data. Characterization involves the test and measurement of the performance of the IP in the target silicon. A report  which contains both verification and characterization information should be available.

When evaluating an IP vendor one should consider the size of the company, the length of time the company has been in business, the reputation of the company within the industry, and the number of staff dedicated to IP design and verification. It¡Çs also important to know if the company develops its own IP or markets and resells IP from another developer. An IP vendor who resells IP from another vendor usually doesn¡Çt have in-house technical expertise, adding a layer of complexity to the support process.

Lastly, as with any service company, evaluate the IP vendor¡Çs level and quality of customer service. Some vendors are willing to make modifications to the macro if needed; others discourage changes with high NRE charges. Often a little extra effort in the verification process will help to guarantee a first-pass silicon success.

Essential Component
IP is an essential component in complex FPGAs and choosing the right IP in the early stages of design can significantly reduce the effort to convert to ASIC. Portability and reusability of third-party IP are important factors to consider in determining total cost and the design span of the project. Third-party soft IP is the best choice, whenever possible. When driven to a firm or hard macro due to performance requirements or area constraints, it is important to adopt a solution that fits the application with minimal impact on the ASIC conversion.

If the ASIC needs to be a drop-in replacement for the FPGA, the ASIC vendor must be able to place any I/O type at any pin. They should offer a rich set of I/O standards and be able to emulate all of the features of the FPGA. This includes memory interfaces, internal memories, timing generators, DCI, and so forth. Working with the ASIC supplier at the early stages of the design can eliminate many difficulties and provide the maximum cost savings in an FPGA-to-ASIC conversion.
    
by Rick Mosher,
Product Manager,
Structured Digital Products,
AMI Semiconductor