When pondering your next-generation system design, you may ask yourself whether the spiraling mask costs have priced you out of the ASIC game. You'll perform the requisite analyses of performance requirements (high) versus cost (much higher) and begin wondering whether another implementation path might serve the end product in a more costeffective fashion. And you'll consider the notion of using FPGAs, at least for prototyping if not for production. FPGAs? Can they have the horsepower to make that nextgeneration design sing? With major FPGA vendors now at the 90-nm process node, it's quite likely they do.
Endowed with a wealth of on-chip resources, today's highend FPGAs can take on circuits that looked ASIC-bound. And FPGAs will soon hit the 65-nm node, and with that, they'll reach new heights in terms of density, performance, and their ability to move signals onto and off of the chip (see the table).
But it's not the silicon alone that forms these FPGAs. Tool flows for FPGAs, both from the silicon vendors and from third-party EDA vendors, continue to evolve to support the chips' burgeoning capabilities.
USAGE MODES
Generally, there are two broad categories of tools for FPGA implementation. One category comprises the tools provided by the FPGA vendors at low cost, or even gratis. In most cases, these tools are dedicated to the vendors' own devices. A corollary is the tools provided by FPGA vendors in OEM arrangements with EDA vendors; such tools are limited to a given FPGA vendor's silicon. The tools can fit the bill for designers who have settled on a given FPGA vendor.
The second category involves tools from EDA vendors that are FPGA vendor-independent. Designers often will want to benchmark their circuit on FPGAs from various makers. Vendor-independent implementation flows make this an easier process than having to switch from tool set to tool set.
Further, FPGA users typically fit into two major camps. One uses them to prototype an ASIC or other full-custom IC. For these users, the FPGA is little more than a verification vehicle on which they prototype parts, or all, of their ASIC design. The idea here is to mitigate risk before entering into the costly process of committing to custom silicon.
"About 60% of the systems customers we deal with are using FPGAs for prototyping before going to standard-cell, large-volume production," says Sanjay Bali, product director for front-end solutions at Magma Design Automation.
"If you look into using FPGAs for prototyping, the requirements for tool use are very different from those who use FPGAs for production silicon," says Juergen Jaeger, director of marketing for Mentor Graphics' DCS Division.
When it comes to prototyping, these users may not necessarily be experts in FPGA tool flows. But they're trying to map their ASIC designs into FPGAs in the easiest possible manner. They need their FPGA tools to handle ASIC-style designs, including a mixture of languages and levels of abstraction.
Also critical when prototyping with FPGAs is the tools' ability to handle design constraints. They must also be able to take in the Synopsys .sdc constraint file format.
"Things like the quality of results (QoR), which, in the FPGA world, really means the maximum frequency (FMAX) at which the design can run as well as gate utilization, are not so important in the ASIC prototyping world," says Mentor's Jaeger. "You're not running as fast as the ASIC would, but you're still running a lot faster than the simulation."
What is critical, though, is preservation of functionality. Because prototypers use the FPGA for verification, they also require fast design iteration times. This means that their tools should support an incremental design methodology so that small changes can be implemented quickly without having to recompile the entire design.
The second major mode of usage for FPGAs is when the FPGAs themselves are the final implementation vehicle for the circuit. In this case, FPGAs are used in production and not just for prototyping. Thus, QoR is obviously a much more important issue, both in terms of speed and gate utilization. The designer also needs deep insight into the devices' onboard resources and how they're used most effectively.
Reprints
