FPGAs today are generally used with a design flow that mimics the ASIC flow.

If the design flow for FPGAs is similar to that of ASICs, the cost structure is entirely different. There is no nonrecurring engineering fee, except for the purchase of however many FPGAs the design team will consume in the course of its work. Synthesis tools for FPGAs are generally much less expensive than for cell-based design, and the vendor design-mapping tools are often given away if the customer appears promising. So a design team can go from concept to working circuit boards for little more than the bill-of-materials cost.

With every morsel of good news, however, comes some bad. Because of their configurability, FPGAs are necessarily much larger for a given capacity than structured ASICs or cell-based ASICs. And typically, family members add gate capacity, I/O count, embedded intellectual property blocks and package cost all at once, so prices escalate quickly as you need more gates. As a result, the unit price for FPGAs is much higher than for a cell-based or structured ASIC, when the comparison is between parts that can implement the same design.

This difference may be distorted by overstating the capacity of FPGAs or comparing the cost of the latest generation of low-cost FPGAs against the cost of an ASIC implemented in a much larger process geometry. But it should also be kept in mind that many small ASIC designs today are pad-limited, even with fine-pitch or staggered pads, and that in fact a small, low-end FPGA may be comparable in price in these cases. Further, FPGA vendors have been aggressive in pushing down the prices of older, smaller parts as the technology advances, so users can expect reductions in cost over time.

For larger designs, however, the FPGA cost becomes truly impressive, reaching well over $1,000 a piece at the top end. Thus, the design manager must balance the greatly reduced NRE and design cost against what may be a substantially higher parts cost.

From the beginning through what would be netlist handoff to an ASIC vendor, the design flows for large designs are nearly identical, whether the target is an ASIC or an FPGA.

The design RTL must be created, IP blocks included, verification performed, a netlist synthesized, and timing extracted and added to the netlist. For a large design, these steps are very similar in difficulty and time for either approach.

This is not true for small, simple designs. From the beginning FPGAs were used by board-level designers whose methodology was evolved using PLDs: a cut-and-try approach that emphasized verification by smoke test over verification by simulation. For designs simple enough to be intuitive and to respond to this methodology, FPGAs have a clear advantage. But the methodology does not converge on large designs.

For those, the difference in design time comes about primarily after the timed netlist is completed. And here the situation becomes highly ambiguous. It is certainly true that it will take an ASIC vendor or customer-owned-tooling (COT) design team longer to get from netlist to samples in hand then it will take an FPGA user, if all goes well. But the existence of a thriving industry of FPGA design consultants is evidence that all does not always go well. The cut-and-try culture of many FPGA designers, the complexity of modern designs and the exponentially increasing difficulty of achieving timing closure as device utilization grows all combine to put some FPGA designs into a never-converging gyre.

Even though going from design to silicon takes minutes or at worst hours for FPGAs-against weeks or months for an ASIC-all of this advantage can be lost in seemingly endless attempts at closure if the methodology is not rigorous. So it is best to say that the total time to production release can be much shorter for FPGAs, but only if adequate skills and methodology are applied.

Up to a point, the same can be said for human design resources. Because they tend to be less analysis-intensive-and because they often rely on the FPGA itself for verification-FPGA designs can be done with smaller, less specialized design teams. FPGA flows do not require the range of specialized skills necessary for a COT design or even an ambitious cell-based design with an ASIC vendor. The skill set is more similar to that needed for a structured-ASIC design.

In the early, glue-logic-gathering days of FPGAs, it was true that FPGA design was a subset of board-level design and did not require the skills expected of chip designers. But as the amount of functionality pushed into FPGAs has increased, this has become less and less true. In high-integration designs, the skills necessary to succeed at RTL design, synthesis and timing analysis of an FPGA are very similar to those needed for an ASIC.

And yet, there is the nagging risk that the design will not converge. This risk can be addressed by good planning and adequate staffing, or by bringing in a good FPGA expert early in the process.

There are some secondary risks as well. It does happen that, despite preliminary analysis (or in its absence) it proves impossible to meet the system requirements with an FPGA. The devices do have hard limits in capacity, speed and power efficiency. They are less flexible than cell-based ASICs in some areas, such as clock domains, asynchronous logic and designs that use registers or memory lavishly.

There is also the risk of market success. Nothing can make a large FPGA as inexpensive per unit as an ASIC of equivalent capacity. If a product proves successful in a cost-competitive environment, the design team will have little choice but to rework the design for an ASIC.

Indeed, there are ASIC vendors that specialize in this, and at least one FPGA vendor offers a conversion path from FPGA to a metal-configured version of the same device, requiring minimal redesign and gaining much of the cost advantage of an ASIC.

On the other hand, the rewards of FPGA use can be substantial. The most obvious is time-to-market. Less obvious, but equally important, is the ability of an FPGA-based design to track changes in a volatile set of design requirements. This is particularly vital in the case of so-called "emerging standards," in which the entire functionality of a codec or interface may change rapidly during the political battles that lead to standards approval. It may be far better to accept the higher parts cost of an FPGA for the volatile portions of an integrated design-realizing that the functionality may change with every meeting of the standards body-than to commit to an ASIC that will be incorrect before it even tapes out.