IP Verification : RTL prototyping: a hardware/software co-verification solution

Implementing a design as an FPGA-based prototype at the register transfer level, has three applications. First, a designer can use RTL prototyping for real-time verification of an IP module in a single large FPGA. Second, designers can perform near real-time verification of an ASIC in a multiple-FPGA implementation. And, by providing a platform for hardware/software co-verification, RTL protot yping provides the flexibility to verify software and hardware functionality in tandem at or near real-time speeds early in the design flow.

An RTL prototype is created by implementing a design from RTL code in one or more FPGAs. The RTL design usually consists of either a single IP block or an entire SoC design. Not all of the SoC functionality has to be implemented in FPGAs. The prototype can incorporate any functionality that is available as a stand-alone chip — an embedded processor or memory, for example. Using this strategy maximizes prototype speed and minimizes cost. In the case of an embedded core, using an off-the-shelf chip or bonded-out core reduces cost and allows easier prototype development.

Some IP is now being implemented in FPGAs, proving especially handy for distributing IP within organizations. With this approach, even highly complex subsystems can fit into a single high-capacity FPGA that runs at the application's real-time speed.

The prototyping re quirements for evaluating IP are similar to those for any other hardware or software verification. Blazing speed tops the list. When evaluating complex IP such as an MPEG decoder, running the logic at real-time speeds, with real-world data streams, is the only way to make sure the IP delivers the necessary performance, quality of results and compliance with standards. Because an IP block typically fits into a single FPGA, designers can almost always get the IP to run at real-time speeds.

ASIC RTL prototyping has grown in usefulness as the tools for automating prototype development have improved. A big advancement for RTL prototyping in recent years has come from the ability to partition an ASIC design across multiple FPGAs automatically. A fast verification synthesis tool aimed at automating RTL prototype development, such as Synplicity's Certify software can make partitioning choices much faster and often with better implementation than would be possible by manually partitioning the RTL code. An RTL prototype also accommodates necessary differences between the ASIC and FPGA implementations such as different clocking implementations without changing the RTL source code. This methodology allows for the use of a single golden version of RTL source code for both the ASIC and prototype, reducing the risk and cost of maintaining different versions.

When a single FPGA does not provide sufficient logic capacity for a prototype, a verification synthesis tool can automatically change the implementation to work around the limitations. The growing gate capacity of FPGAs has reduced the number of chips needed to implement an SoC prototype, but the number of I/O pins remains a key constraint when dividing logic into multiple FPGAs. In cases that require thousands of interconnections, the pin limitation may prevent a designer from taking full advantage of an FPGA's gate capacity unless they multiplex some interconnects. Multiplexing reduces the potential speed of any given signal, so the technique i s appropriate only when it does not violate the prototype's timing performance. But when multiplexing is appropriate, it can significantly boost the FPGA capacity utilization.

A long-available technique for handling pin limitations relied on synchronous multiplexing to share signals on each I/O pin. This technique works well but requires special care, especially in multiple-clock designs. A newer technique based on asynchronous multiplexing simplifies the requirements. As a result, software tools can automate the process, eliminating manual work by designers.

RTL prototypes help both hardware and software developers, with the latter benefiting most. Software developers can hardly be expected to optimize code without executing large amounts of it several times at a minimum. To meet this goal, software developers typically need 8-MHz performance or better from the hardware design, depending upon the processor core and application.

Many SoC teams attempt to get an early start on software development by augmenting their traditional ASIC methodology with emulation or hardware/software co-verification-based design capabilities. In this methodology, designers use their existing tool infrastructure and flow but verify hardware using a hardware simulator or emulator and concurrently run an instruction set simulator (ISS) to verify software. Unfortunately, even the most advanced and expensive emulation and hardware/software co-verification tools cannot exercise systems at near real-time speeds. Software execution is thus orders of magnitude too slow to meet the verification needs of SoCs.

Even if software developers are willing to be patient with ISS speeds, it is often impractical to interface emulated logic with the real-world data streams needed for many SoC applications such as communications and multi-media. Among other problems, many hardware interfaces cannot run at speeds significantly below their normal operating range.

Thus, design teams can either delay soft ware optimization until functional SoC hardware is available or take advantage of RTL prototyping to cut a significant amount of time from the development cycle. Running at real-time speeds enables strong compatibility testing and allows evaluations of subjective characteristics such as voice or video quality. Equally important, an RTL prototype allows a designer to minimize the cost or maximize the performance of a design by exploring the performance effects of tradeoffs between hardware and software.

This process implies that hardware and software teams are working on the prototype simultaneously. Because RTL prototypes are relatively inexpensive, several copies — commonly called replicants — can be used by different hardware and software teams. Software developers can interface with the prototypes through their usual debug environments.

The ability to run an RTL design in real-time and verify its functionality has long been valued by hardware designers who use prototypes. As software developers play an increasing role in SoC designs, the ability to use prototypes to verify the hardware/software functionality can provide even greater benefits than when used for hardware verification alone. And for any design project, saving months of development time is the best payoff of all.

See related chart