January 16, 2009 -- As FPGAs increase in both size and performance, they also naturally increase in complexity and price. Forward-looking FPGA users hope that their products will take off, driving demand for higher volumes. They consider from the outset what options are open to them to convert more-expensive FPGAs to less-expensive solutions. FPGA vendors often tend to view the FPGA-to-ASIC conversion process as a negative point at which they likely will lose their customers and associated volumes. But with some up-front consideration, FPGA-to-ASIC conversion could become an "evil-to-opportunity" conversion. A solid solution would imbed the conversion process into a tool flow already familiar to FPGA users.

FPGA vendors generally want to keep their customers as long as possible, while customers want to leverage their increasing volumes to save money. If an FPGA vendor designs a business model to accommodate a customer and the eventuality of a specific design increasing in volume, perhaps it opens an opportunity for both of them. An FPGA designed for this purpose would need to integrate the conversion process into the tool flow. More and more FPGA vendors are considering exactly this approach.

Although it may seem obvious why customers want to decrease their costs and increase the range and flexibility with which they can set the price of their product, the same holds true, although less obviously, for FPGA vendors. For these vendors, having the conversion process cost as little as possible provides greater flexibility to adjust the balance between piece prices for the FPGA and the converted part with the NRE charged for the conversion. But there’s a fine balance. Set the NRE too high, and customers are motivated to convert straight to a custom ASIC, bypassing FPGA vendors. Set it too low and FPGA users will convert too early, cannibalizing FPGA sales. The less it costs FPGA vendors to do the conversion, the more control they have over this balance.

So it becomes an issue of making conversions cost as little as possible. One part of the conversion cost comes from the silicon materials costs of the converted part, both the piece cost and the mask costs. The other component of the conversion costs is the engineering hand-holding required for the conversion process. Silicon materials costs can be minimized by the technology chosen for the conversion, but the tool integration directly affects the engineering requirements.

A structured ASIC approach has several advantages for minimizing silicon costs, but there are still considerations. The underlying fabric must be designed to provide the same resources as the FPGA did originally. The two components most directly affecting the conversion costs are customization masks – how many there are, and their cost – and the routable density of the underlying fabric. Sheer logic density does not necessarily provide the best routed density.

Before considering the tool flow integration, it’s wise to consider the necessary differences in an ASIC and an FPGA design process. Two differences must be there, by definition – I/Os and test procedures. There may be others that are part-specific, such as analog blocks, hard macros, or other unique situations; but, for the most part, these can be incorporated directly into the fabric footprint or template.

The I/O issue is essentially one of size. If the I/Os are in a ring around the periphery, there will not be the same space for I/Os when the logic shrinks as a result of conversion. This can be handled in several ways, but all have an associated problem. It is possible to artificially force a limit to the I/O count on the FPGA so that the conversion has the same resources. Another solution allows all of the I/Os on the FPGA to be used, but the integrated conversion tool would then need to check the I/O resources to see if the design is conversion compatible. This implies that not all designs will be converted. To get the same number of I/Os as on the original FPGA, area I/Os can be used; but this approach introduces complications in both the routable fabric and packaging.

The second difference is one of test procedures. In an FPGA manufacturing process, the part is tested prior to design configuration. In an ASIC manufacturing process, the part is tested after it is configured into a particular design. The integration tool must minimize the issues associated with these different test procedures. Analyzing the design during the FPGA creation phase for compatibility with the eventual ATPG process and informing the designer of potential problems needs to be part of the conversion compatibility checks.

The ultimate tool integration consists of two conversion buttons, a "check-it" conversion suitability test button, and a "do-it" convert button. The check-it button goes through a check-list and provides suggestions on required fixes. It needs to confirm that the resources used are available in the converted part (I/Os for instance). It also needs to check that the design is compatible with ATPG tools (synchronicity issues for instance). Both checks can be done relatively quickly and provided as part of the FPGA tool suite.

The "do-it" button can run the place-and-route on the user’s desktop as well as the ATPG. This iteration may take a little longer, but is not nearly as complicated for a structured ASIC as for a full-custom solution. It only is done when the "check-it" process is clean.

After both tasks are run, the resulting files can be sent to the FPGA vendor, with the conversion process virtually guaranteed successful. Timing closure and simulation can use existing tools with which users are already familiar. In some cases, knowledge of the logic locations from the FPGA place-and-route can be used in the structured ASIC. In almost all cases, the performance of the converted part will be superior to that of the FPGA.

With some upfront expenditure on tools and fabric masks – about as much as a single custom ASIC costs – the FPGA vendor can be the silicon provider for the customer all the way through higher mid-level volumes. Matching FPGA vendors’ needs with customers’ needs for a larger part of the product life cycle converts a problem into an opportunity for both.

By Mark Goode

Mark is President and CEO of ViASIC, Inc.