System Design

Co-Verification Strategies In Hardware-Software Co-Design

The need for co-verification of both hardware and software forces many hard choices for system designers who desire a smooth path to silicon (and code).

by Steven E. Schulz

Hardware-software co-design is hardly a new idea. For decades, design teams have had to face the realities of combining digital computing with software algorithms to deliver a system capability. The problem has been that until recently, verifying the interaction between the two has required the building of actual prototype hardware. While this has always been a difficult and painful exercise at best, it has generally sufficed­until now.

The trends of the '90s have both exacerbated the problem and opened up new potential solutions. Semiconductor processes now permit entire systems to fit on a single chip. Most of the processing of "real world" data­audio, video, sensors­has migrated to the digital realm. The "system on a chip" phenomenon is now adding to the momentum, as co-design turns from merely a good idea into an economic necessity (see "Bridging the Gap to Software," ASIC & EDA , September 1994). And predictions for the future point to greater embedded software content in hardware systems than ever before.

Major trends in hardware-software co-design In the early days, code development and hardware development were performed sequentially, with relatively little cross-coupling until actual prototype hardware was built. Today, we are seeing that selected portions of the development flow are coupled, requiring multiple, fragmented modeling efforts to support specific co-verification goals throughout the design process. In the near future, several factors are evolving that will likely converge the designer's environment for co-verification.

First, workstation processing speeds continue to increase at an impressive rate. While much can be attributed to IC manufacturing process capability that enables shrinking design rules and higher edge rates, other factors such as advanced CPU architectures, workstation architectures, operating systems, and compilers all continue to enable software to run faster on simulated hardware. However, the corollary is that designing those very same systems to deliver this capability also requires more co-verification than before to achieve design goals.

Design re-use has been a popular buzzword for many years, but until recently remained an elusive concept. Now that "system on a chip" densities and processes are a reality, previous and current generation ICs are finding their way into new designs as embedded cores in a mix-and-match fashion. This will force greater convergence of methodologies for co-verification, since both data-flow and control-flow dominant hardware must reside on a single IC. This higher priority should lead to a new breed of commercial tools that help integrate co-verification choices.

In 1993, the U.S. government initiated a 48-month program to develop new co-design methodologies and automation tools in support of rapid prototyping known as RASSP (rapid prototyping of application-specific signal processors). RASSP combines the concepts of hardware-software co-design and design reuse with other novel approaches that promise to raise the state of the art across a broad array of design applications. Numerous system, IC, and tool suppliers have teamed to insert this functionality into many of the EDA products already in widespread industry use, as well as to bring new tools to market.

In the future, both hardware and software designers will increasingly need tools for estimating the impact of design changes earlier in the design cycle, before committing to specific hardware-software partitioning.

Design methodology implications Applying the right modeling strategy at the right time is key to catching elusive design errors quickly. Yet it is often necessary to consider multiple approaches as the design project progresses, rather than just one. How can multiple modeling approaches fit into an already tight design cycle?

The answer is highly dependent on the specific goals and constraints of one's design project, as well as computational domain and end-use. In general, the design flows are fairly complex. The process of co-verification is also iterative, with multiple passes required to validate increasingly refined levels of detail.

The design flows can look very different depending on whether one is designing a cellular phone, computer system, graphics compression chip, or a custom RISC processor. We will use the DSP system flow as an example, to demonstrate how multiple modeling approaches can be applied throughout the design flow as part of a co-verification strategy (Figure 1). In practice, schedule or cost constraints may limit the actual number of approaches utilized.

Figure 1. This is an example of a DSP-based system design flow incorporating numerous modeling approaches for co-verification. (A) Useful to help refine HW system, work interfaces, and see timing relationships. Little (if any) code can be run. (B) This software program is essentially a finite state machine that accepts and responds to object or assembly level instructions. (C) Show interactions in HW system, but only portions of code can be run. Can override internal processor rate. (D) Permits source code debugging at HW speeds, with access to internal registers. Not part of HW system. (E) Allows near-speed SW execution in the HW system context, with access to internal registers, etc.

The first verifications use traditional event-driven logic simulation (A in Figure 1) in conjunction with bus-functional or full timing-accurate models of the processor. Neither model is appropriate for running code, yet still very useful to refine the hardware design and analyze timing relationships in the system.

The first interactions of the software design with hardware occur with a specialized processor simulator (B in Figure 1). This software program is essentially a finite state machine that accepts and responds to assembly-level instructions. Although it lacks internal views of factors such as pipelining, it nonetheless shows how the algorithms will be executed (but with no surrounding hardware system). A source code debugger provides a graphical interface for operational control and disassembly.

After technology mapping (e.g. synthesis), more detailed logic simulations can be run (C in Figure 1). This time, object code can be loaded into the model, which may be useful to the hardware designer. If a cycle-based model is used, it may be possible to have a "virtual" in-circuit emulation (ICE) capability. If a physical model is used, no ICE features will be available.

The next co-verification step permits source code debugging at full hardware speeds, using a hardware emulator (D in Figure 1). The hardware emulator is an electrical interface to special pins on the processor that utilize JTAG (for test scan access) to permit display and modification of internal registers (even while the processor is active in the target system). Software running on the workstation controls the emulator hardware, and also provides a graphical source code debugging interface for accessing internal registers. Support for parallel processing configurations is possible with additional hardware development modules. Hardware emulators can run code in real time, and within a system context.

Returning to a hardware view, the design proceeds with logic emulation (E in Figure 1). Unlike hardware emulator modules, logic emulation is useful to co-verify the system context even when the target system hardware has not yet been built. If a custom processor is being designed, then logic emulation is ideal for examining functional correctness after technology mapping is completed. In a system context, the processor may be plugged in using an adapter board. Furthermore, traditional ICE equipment (such as HP logic analyzers and disassemblers) can be connected to the adapters. Near-speed code execution is feasible, with recent advancements in emulation technology supporting clock speeds up to 50 MHz.

In the example above, a commercial off-the-shelf DSP chip is used, and it was assumed that the instruction level simulator, emulator module, functional software model, and physical IC were readily available. However, in a custom processor design, time should be allocated for the development of all models for hardware-software interaction. This requires tremendous effort, and a significant portion of project schedules can be expected to focus on model/emulator development.

Presently, numerous EDA tool offerings are available to help support flows such as the one just described (Table 1). These products are often used in conjunction with other development tools from IC suppliers and internally developed tools.

One aspect of Table 1 requires further explanation. A close examination reveals numerous product offerings which do not use any model of the hardware processor in co-verification. Several of the commercially available tools offer co-verification through simulation of the system, prior to partitioning into discrete hardware and software components. These tools are generally based on graphical input of state diagrams and data processing blocks, where the underlying simulation models are libraries based on "C" or other functional description format. Since the simulations represent combined functionality, the software code need not run on any model of hardware. At a later stage, these tools output both HDL code and software "C" (or assembly) code during the partitioning stage.

Co-verification of hardware and software sub-systems continues to be a fairly messy business. To ensure success, a co-verification strategy encompassing numerous detailed factors must be planned in advance, and a specific design flow should be coordinated project-wide. Model development and support can also require a substantial effort.

Yet the benefits are clear. Improved time to market, reduced prototype development costs, and higher quality systems are all being enabled through recent advancements in modeling, simulation, and emulation. Combined hardware-software systems are quickly becoming the norm, not the exception­and co-verification tools and techniques are reflecting this growth in popularity.

Contributing editor Steven Schulz is a member of the design automation division in Dallas-based Texas Instruments' Semiconductor group.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  July 1995