As the software content in today's 2.5G and 3G phones rapidly increases, timely software development is becoming critical for product success. The traditional development flow—in which software design isn't started until after hardware design is complete or nearly complete—simply breaks down. The resulting design cycle is too long for the competitive wireless market. In addition, dealing with the hardware-software interaction after most of the hardware has been defined can yield a less than optimal solution.

Today's wireless design flow often relies on FPGA-based hardware prototyping to start the software-development tasks in earnest. Clearly, this approach has one indisputable advantage: The same Verilog or VHDL hardware model that's going to be synthesized into silicon creates the prototype. This methodology requires a single Verilog or VHDL source for both the FPGA and system-on-a-chip (SoC) implementations. By using the same model as the source for both, the developers have a high level of confidence that the software developed on the prototype also will work on the final hardware.

The downside is that the software engineers have to delay the design and testing of their software until after the register transfer level (RTL) is available. This delay lengthens the overall development cycle. Competitive pressure to "get the product out" can lead to situations in which a product is placed on the market even though it is architected in a sub-optimal fashion or exhibits a variety of hardware and/or software problems. The only way to address this dilemma is to find a way to start software development much earlier than usual in today's wireless projects.

The ideal solution must permit the development team to perform the software tasks before the hardware or a physical prototype is available. Instead of a real hardware-based prototype, the team needs a software-based prototype or virtual prototype on which to perform the various software-development tasks. This virtual prototype must be a simulatable, fully functional software model of the target system. The virtual prototype must be available many months prior to a hardware prototype—even before the architecture is fully frozen.

At the same time that the software team is working on the virtual prototype, the hardware designers can be completing their hardware model and synthesizing the chip implementation. Thus, a virtual prototype enables true hardware-software co-design and co-verification. The shift toward a concurrent hardware- and software-development flow fundamentally addresses the problems that are created by the increasing software content in today's wireless products.

This article explores a mixed-level modeling methodology and the tools required to build a virtual prototype. Such a methodology provides critical data to the designers up front in the development process. It helps them make key decisions about the architecture early on. This article also presents a verification solution that enables designers to catch potential functional differences between the virtual prototype and the actual hardware while it's being developed. That verification maximizes the confidence that the software developed on the virtual prototype also will run on the hardware model and the final hardware itself.

Today's typical advanced wireless product utilizes a wide variety of intellectual-property (IP) blocks to provide the functionality demanded by the market (FIG. 1). Such blocks include digital signal processors (DSPs), processor cores, complete subsystems, modems, and multimedia blocks. They also house a slew of interfaces ranging from USB to Bluetooth and Wi-Fi. On the software side, standard operating systems need to be extended to incorporate new hardware capabilities. Meanwhile, new applications need to be developed and validated.

Building a virtual prototype entails building a software model of the target product and its corresponding high-level testbench. Typically, high-level functional blocks, which are related to the various IP blocks, are used along with models for their interconnect fabric. In the virtual prototype, the structure of the interconnect models is important for simulation performance.

From a software perspective, real-time requirements need to be merged with application needs under the control of a real-time operating system (RTOS). In order to be able to answer critical questions concerning the performance of the architecture, the virtual prototype must model the detailed timing behavior of the interconnect fabric (typically on a cycle-by-cycle basis). Very fast and functionally correct models may strip away too much of the timing behavior to provide such answers. On the other hand, accurate cycle-by-cycle modeling of the interconnect fabric may have a severe impact on the overall simulation performance.

Essentially, designers need a solution that lets them choose the level of detail that will be used to model the interconnect fabric. The required details will depend on the answers that they hope to uncover by simulation. If there are questions about the interaction between the application processor and the modem subsystem, for example, that part of the chip needs to be modeled at a detailed cycle-accurate level. Yet other parts can remain at a functional level.

From a software perspective, all of the chip's functionality is available in the virtual prototype regardless of which detailed models and functional models are running. However, users can maximize the simulation speed by keeping most of the models on an abstract functional level. They'll still have the detailed information for a particular interaction available in order to answer key questions about the interaction.

The mixed-level modeling methodology and supporting tools allow designers to build a virtual prototype of the target design. They can connect it to the stimulus/response environment (testbench), load a set of software executables (one for each microprocessor and DSP), and simulate at very high speeds. The tools should allow the virtual prototype to be configured easily for different types of measurements and development needs.

A software developer, for instance, usually wants to maximize performance. He or she would therefore model the interconnect fabric purely on a functional level. In contrast, a system architect might want to measure bus utilization and other aspects of the architecture's performance. Such measurements might require modeling the interaction between the application processor and DSP in a cycle-accurate fashion.