Much has been written about the rise of field-programmable-gate-array (FPGA) -based platforms over application-specific-integrated-circuit (ASIC) implementations. During the last few years, FPGAs have certainly increased their size and performance capabilities. One testament to these improvements is Xilinx's recent release of Virtex 4. This release boasts a multi-platform FPGA family that was produced using 90-nm/300-mm chip-making process technology. The platform targets three major architectures: Virtex-4 LX FPGA (logic-intensive designs); SX FPGA (high-performance signal processing); and FX FPGA (high-speed serial connectivity and embedded processing) (FIG. 1).

With such improved performance and the addition of embedded-processor and digital-signal-processor (DSP) cores, some experts have suggested that FPGA-based solutions are moving upward toward the system-level-design space. Others contend that system-level design is best done using software-intensive, virtual prototypes. Which viewpoint is correct? As any engineer will tell you, it all depends upon your requirements and the resulting solution tradeoffs.

For example, assume that a wireless design must handle a large block of streaming data (i.e., many samples coming through at a high data rate). Perhaps the design requires the use of a Viterbi decoder or a Reed-Solomon coder. "These are the implementations where FPGAs with embedded DSP cores really shine," says David Squires, Director of the DSP Center of Excellence, IP Solutions Division of Xilinx (www.xilinx.com). Squires explains that these compute-intensive portions of the overall design could be downloaded onto an FPGA. There, they would run faster than they would in a software simulator.

Tom Anderson, Chair of the VSIA Function Verification Working Group, agrees that hardware-based solutions have the potential for very high simulation speed. Such solutions include simulation accelerators, emulators, and FPGA-based prototyping systems. Depending upon the project size and complexity, Anderson adds another benefit of hardware prototypes: Because of the fuzzy line between acceleration and emulation, it may be possible for projects to use the same hardware system in different modes during different project phases. By using FPGA platforms with readily available IP, designers could quickly put together an entire system. DSP applications are ideal for such IP integrations. After all, they contain a host of pre-defined implementations, such as FFTs, FEC cores, and FIR filters.

This IP-centric view also supports the need for rapid prototyping. Such prototyping gives the software designer a quick platform on which to develop programs. According to Luaro Rizzatti, VP of Marketing and General Manager of Emulation and Verification Engineering (www.eve-team.com), "FPGA-based platforms are good for validating hardware/software integration and for developing drivers, RTOSs, and embedded applications." Yet Rizzatti cautions that FPGAs may be expensive and hard to set up for large designs (more than five million ASIC gates).

FPGA platforms are commonly used to initiate software development and debugging early in the development cycle—especially for real-time systems. Johannes Stahl, Director of Marketing for SPW at CoWare (www.coware.com), notes that real-time requirements can be the key differentiator: "The best way to distinguish between rapid- (FPGA-based) and virtual-prototyping needs is to first determine whether you have a real-time interaction or not." Stahl points to the design of a baseband chip as one example of a real-time interaction. To verify all of the baseband protocols in the physical-layer interactions, the designer must have access to the analog front end. Thus, he or she needs real hardware running at real time—a rapid prototype.

Prototypes aren't without flaws, however. Serge Leef, General Manager of Mentor Graphics' (www.mentor.com) SoC Verification Division, explains, "Physical prototypes enable execution close to real time, as real hardware is used. But the tradeoff [with virtual prototypes] is poor control, limited observability, and high costs." The hardware prototype also must be available before any software can be developed, notes Leef. In other words, the prototypes won't typically be available until the later stages of the design process.

"Understanding the interaction between RF hardware and baseband digital signal processing at the physical layer is critical to determining overall system performance," notes John Arnold, Manager of Marketing Communications for Ansoft Corp. (www.ansoft.com). Here, the worlds of FPGA-based platforms and virtual prototyping—circuit simulations—can be used to co-simulate a complex radio design. The FPGA output can be linked directly to the virtual model.

On the other hand, there are a host of applications in which real-time interactions aren't a concern. An example is multimedia processing. For these types of applications, complex functionality represents the biggest design challenge. Such applications are ideal for virtual software prototyping.

If multiple processors and buses are needed to implement a design, for example, FPGA-based platforms could provide the necessary number of processors. But debugging the overall system could be difficult. The advantage of using a virtual prototype to analyze this design is one of transparency: Every single data point in the whole design could be examined. For complex design, the observability of the virtual model is often far better than it is for the FPGA-based model.

Another advantage of virtual system prototypes is the reduction in development risk and cost early in the product life cycle, notes Graham Hellestrand, CEO of VaST Systems Technology (www.vastsystems.com). "Virtual prototyping does not only facilitate serious architectural exploration and analysis. It also enables hardware/software co-design and verification to begin in the first 25% of the development schedule. FPGA prototyping facilitates this only at the 50% mark of the project" (FIG. 2).

Hellestrand points out that in traditional wireless (cell-phone) product engineering, two-thirds of the engineering effort is in software development with the remainder in hardware design. In the traditionally sequential engineering process, software development wouldn't occur until after the hardware platform was ready. Unfortunately, the hardware usually isn't available until the last quarter of the project period. FPGA prototyping does make the hardware available sooner. Even then, however, Hellestrand says that it is only at about the halfway point of product development. This delay still could put the project success at risk.

Conversely, the virtual prototype is built upon an architectural description of the hardware and software. By its very nature, this prototype precedes the actual hardware and software development as well as the system integration and verification. Hellestrand reasons that the virtual prototype can effectively move the peak development activity up into the second quarter of the project. With respect to the traditional embedded-systems engineering process, this shift in development effort should reduce risk by about 90%. It should cut the project period by about 30% and project resources by about 25%.

Architectural tradeoffs demand the ability to work at a high level of system abstraction before functions have been defined into hardware or software. This "level of virtuality" is another of the key differences between FPGA and software prototypes, cites Brian Bailey, an independent consultant working in the functional-verification space. "A software prototype will always be able to handle higher degrees of abstraction than what can be mapped into FPGAs."

Bailey emphasizes that the primary question to be considered is the intended usage of the prototype. Once this question is answered, the engineer can match the applicable requirements with the capabilities of the available platforms—be it a hardware or virtual software model. Say an engineer needs to explore the system design space in order to investigate the interaction of functionality blocks that are connected by communication channels. In this scenario, a virtual prototype is best. Yet if the designer must verify a particular implementation, Bailey notes, an FPGA might work out better.

In the end, both hardware (e.g, FPGA-based) and virtual (system-level) prototypes have their place in the design environment. Software-simulation virtual modes are necessary for system-level design. Blocks of the system may be tested out in FPGAs. For real-time systems, hardware prototypes are still preferred. But virtual prototypes are becoming more cycle accurate. They may even be used for some real-time designs. The tradeoffs depend on the application complexity and the nature of the system that's being designed.