Design Feature: July 18, 1996

Virtually all chips containing one or more processing engines need software to operate. You need to develop this software, whether on the chip in ROM or externally, with the chip's hardware development. Unfortunately, the story about a project team's hardware and software developers' exchanging business cards when they meet approaches the truth. System-on-a-chip hardware and software design and implementation are often separate and parallel operations until the late stages of hardware development (Figure 1). This situation often produces specification and implementation mismatches between hardware and software components.

A design methodology that waits until a hardware prototype is available before checking software compatibility causes many problems. If you discover a software bug, you cannot easily change the hardware without a significant delay in final product release. Also, hardware description languages (HDLs), such as Verilog and VHDL, along with HDL simulators, have greatly accelerated chip-hardware development over the past few years. This acceleration puts an even heavier load on software-development teams to interface with hardware developers earlier in the system-design cycle. Fortunately, help is on the way in EDA tools and design methodologies that can ease your hardware/software codesign burden.

System partitioning

Many factors influence how you partition a system into hardware and software (Reference 1), including:

• Overall system performance, which determines how much of the design you must put into hardware to meet data-throughput specifications;
• Cost of system implementation, including development and physical cost of hardware and software development;
• Ability to modify the system software if it requires future changes, such as for an evolving communication standard;
• Computational nature, meaning how a system processes data;
• Hardware and software concurrency; and
• Communications-overhead cost between system hardware and software components.

Even though you cannot automatically do the partitioning, you can use tools from several software vendors, such as Alta Group, CPU Technology, and Synopsys (Table 1), to validate high-level system representations of partitionings and choose the best one. Today's tools, however, can only point you in the right direction. You still need to simulate your design at lower levels of abstraction to determine if you are meeting required speed, size, power, and cost specifications.

Cosimulation techniques

Throughout your system design, you need to simulate the hardware and software to see whether they work together correctly. Cosimulation lets hardware simulators and hardware models interface with system software. This interface lets you concurrently verify the software while exploring hardware trade-offs. Each type of simulation involves trade-offs between simulation speed and accuracy. You need simulation environments that adequately handle the software and hardware synchronization. You also need to be able to debug the system when problems appear. Debugging involves being able to "see" inside the internal states and register contents of hardware modules. Another factor to consider is the availability of simulation models, both for hardware and software modules. Table 2 from Reference 2 compares cosimulation techniques.

The type of model you use to represent a hardware component reflects a trade-off between the accuracy, or detail, of the part you are modeling and the speed of simulation. The most precise are nanosecond-accurate models, which have accurate timing information at the model's pins and include complete functionality. This type of model is good for checking system hardware details. The high accuracy comes at a price, however. The model is difficult to design, and its simulation is slow. You may also have problems getting a nanosecond-accurate model of a particular component. Manufacturers of this part, fearing reverse-engineering of a model into a competitive part, may not make such models available. Of less complexity is the cycle-accurate, or zero-delay, model. This model supplies correct pin transitions at the edge of each clock transition. Fewer unique event times during simulation result in a simulation speed-up of a factor of approximately 10 over a nanosecond-accurate model. A still-faster model is one that is instruction-set-accurate. This model, also called an Instruction Set Simulation (ISS) model, correctly emulates the instruction set, meaning that the model correctly shows register and memory values but provides no timing information. This type of model is generally not useful for hardware evaluation but is good for debugging software. ISS models do not correctly model some complex processor functions, such as pipelining timing problems, but the model simulates faster than does a cycle-accurate model. Generally, the faster the model, the less accurately it models the system's hardware and the faster it simulates.

Several EDA companies offer tools for the hardware/software codesign problem; none of these tools is currently completely satisfactory. Moving a step toward "easier" hardware/software coverification is Mentor Graphics with the recent announcement of the Seamless CoVerification Environment (CVE). Seamless CVE is the first product stemming from last October's merger of Mentor Graphics and Microtec Research (Santa Clara, CA), a software-development-tool maker. Seamless CVE lets software developers interact with hardware models at the behavioral level and register-transfer level (RTL). The tool's cosimulation kernel works with normally unrelated hardware- and software-design tools (Figure 2). Mentor claims that Seamless CVE performs simulation two to three times faster than does a gate-level simulation.

Seamless CVE presents a true processor model to a logic simulator. The model interacts with the system bus, so that the system correctly models and executes software and hardware interactions. The cosimulation kernel uses synchronization algorithms for timing, optimization algorithms to speed simulation, and memory-management logic to speed data transfer between hardware and software memory models. Seamless CVE supports several popular Verilog and VHDL simulators, including the company's own QuickSim II and QuickHDL and Cadence's (San Jose, CA) Verilog-XL. For very high-performance applications, you can use a hardware accelerator to speed simulation. Microtec's Xray debugger eases software development and source-code tracing. Xray links to commercial and proprietary real-time operating systems (RTOSs) and to compilers for C, C++, and assembly language. Mentor also offers process and DSP-engine models of Advanced RISC Machines (Los Gatos, CA), Hitachi (Brisbane, CA), Intel (Folsom, CA), Motorola (Austin, TX), SGS-Thomson (Lincoln, MA), and Texas Instruments (Dallas) to assist system development.

Virtual prototypes

You use a virtual prototype in place of hardware to help define your system and to debug it after you define the hardware. The idea of a virtual prototype, a software model of a hardware system or subsystem, is conceptually simple but difficult to implement. When you use these models early in the design process, they let you do what-if analyses to decide what portion of a system you should implement in hardware and software. Cost, size, power, and time-to-market constraints are your guides in making this decision. Simulating system software on virtual prototypes helps you make hardware trade-offs; for example, should you put a larger cache on an ASIC processor chip or use faster and more expensive memory chips? After you decide what the hardware should look like, using a virtual prototype to test the application or embedded software tells you if the choice of hardware implementation and software definition is correct. If the software functions incorrectly, you must decide whether to change it or to modify the proposed hardware. Both of these tasks are still relatively easy, because you have not yet implemented your system in real hardware.

You can define virtual prototypes at various stages of your hardware's development: the conceptual, architectural, RTL, or even gate level. The earlier you define and simulate a virtual prototype, the easier it is to make any necessary changes if the system functions incorrectly. Another advantage of using high-level virtual prototypes is that you can simulate them faster than you can lower level software models. However, because you are using software models in place of real hardware, simulation is much slower than emulating the actual hardware or using a hardware prototype.

One company, CPU Technology, offers a virtual-prototyping service using the company's SystemLab environment. SystemLab is a virtual environment that uses fully functional, clock-accurate software models and representations of the equipment you would normally use to design and validate your hardware/software system. Such equipment includes an in-circuit emulator, a logic analyzer, and a clock generator (Figure 3). CPU Technology develops virtual prototypes of the hardware blocks, including off-the-shelf components and ASICs, of your system. You use these prototypes to prove system concept, evaluate hardware architectures, and integrate software and hardware. You can also use SystemLab to modify a system before physically implementing changes. The company's models are cycle-accurate at the instruction level and allow you to run reasonably fast simulations. For example, an 8051 processor simulates in SystemLab at about 8000 clock cycles/sec on a Pentium system and about 15,000 clock cycles/sec on a system with a Pentium Pro processor. You can also run complex system simulations in SystemLab, because you only need about 10 bytes of memory for each equivalent logic gate in a design. (A 1 million-gate ASIC has a modest requirement of about 10 Mbytes of memory beyond that needed for the operating system.)

Eagle Design Automation's Eaglei addresses the embedded-system codesign market. Eaglei contains the Virtual Product Console (VPC) and the Virtual Software Processor (VSP). VSPs are software models of popular µPs to use with the VPC, which links the models with application software. There are two types of VSPs available. The first is an enriched bus-functional model, composed of a C-code core in a Verilog or VHDL wrapper. The C code communicates with the application software, and the HDL wrapper represents the system hardware for an HDL simulator. Eagle's recently introduced ISS models represent the second kind of VSP.

Using the VPC and a VSP with a hardware simulator provides a hardware/software codevelopment environment (Figure 4) that can simulate as many as 5000 instruc-tions/sec. The VPC also lets you test software against the hardware model at the behavioral, register, and gate levels of abstraction. Eagle offers VSPs for the Advanced RISC Machines ARM7; AMD (Sunnyvale, CA) 29K and X86, Intel X86 and i960; Mips Technologies (Mountain View, CA) 4000, and Motorola 68K and Power PC. Eaglei hardware-simulator support includes Cadence Verilog-XL, Chronologic's (Los Altos, CA) VCS, Model Technology's (Beaverton, OR) V-System/VHDL, Vantage's (Fremont, CA) Optium, and Viewlogic's (Marlborough, MA) Fusion.

Hardware emulation

Moving down the design "food chain," emulation is a way of checking hardware and software compatibility early in a design at the RTL before synthesizing, as a logic-gate representation, or at the gate level. At these stages, the hardware is the functional equivalent of a breadboard. The emulation system configures your design within an array of PLDs, which can be commercial FPGAs or, for Mentor Graphics' SimExpress, in a full custom chip. Emulation occurs as fast as tens of megahertz. However, the entry cost of complex design emulation can be hundreds of thousands of dollars for a system with a capacity of hundreds of thousands of gates. Also, the time required to set up a complex system for emulation may be weeks or months (see box, "Chip-emulation advantages"). However, actual emulations take only hours, and you can rerun them as necessary when you make software or hardware changes.

Besides Mentor Graphics, companies such as Aptix, Ikos, and Quickturn Design Solutions offer emulation hardware and software. Of this group, Quickturn is the best known in the simulation arena for the company's System Realizer product line. Quickturn performs RTL emulation before synthesis. The company's top-level system can emulate systems with as many as 3 million gates as fast as 4 MHz. The company's new Quest II emulation software reduces the time to compile a design before emulation and enhances the visibility of the design during debugging. Toshiba America (San Jose, CA) uses a Quickturn emulation system to verify chip hardware at the RTL and gate level (Figure 5). Toshiba performs an optional functional check after synthesis to the gate level if a custom-designed block is on the chip. An example of such a block would be the datapath for a processor, because the custom design is more area-efficient than one done with automatic EDA tools. Toshiba does timing simulation and verification in parallel with chip floorplanning and layout to save design time. Both subflows are closely coupled; a problem in either layout or timing usually means a change in the other subflow.

Hardware prototypes

The most technically ideal way to test your application software on system hardware is to build and use a prototype of the hardware. Software runs at or near full system speed on a prototype and provides accurate hardware-timing checking. Using the real thing gives you a range of software-development tools from which to choose when testing and debugging the hard-ware/software combination. However, if you find a hardware problem, it will most likely effect system-design time; a problem that necessitates a redesign might force the final product to miss a critical design window. This situation emphasizes the necessity of doing everything possible to run hard-ware/software coverification earlier in the design cycle.

The EDA industry, through new tools and design methodologies, is attacking the bottleneck of hardware/software codesign for complex chips (Table 2). Current efforts focus on the use of virtual prototypes for as-yet-unimplemented hardware and speeding the cosimulation of hardware and application software early in system design. The problem of initial system partitioning into hardware and software components, based on such constraints as data throughput, cost, and power, is still in evidence. Such partitioning is largely a manual operation based on designer expertise, and EDA and hardware vendors still need to develop techniques to further automate this procedure.

You can reach Technical Editor Jim Lipman at (510) 606-1370, fax (510) 606-1563, email ednlipman@mcimail.com

References

1. Adams, Jay, and D Thomas, "The Design of Mixed Hardware/Software Systems," Design Automation Conference Proceedings, June 1996, pg 515.
2. Rowson, James, "Hardware/Software Co-Simulation," Design Automation Conference Proceedings, June 1994, pg 439.
3. Bunza, Geoffrey, "A Journey into Parallel Worlds: Exploring Hard-ware/Software Systems Integration," Eagle Design Automation, March 1996.
4. Zaidi, Jauher, "Hardware Software Co-simulation," Design SuperCon96, On-Chip System Design Conference Proceedings, January 1996, pg 3-1.
5. Levy, Brian, "Early Firmware/Hardware Integration and Verification Using Hardware Emulation," Design SuperCon96, On-Chip System Design Conference Proceedings, January 1996, pg 7-1.
6. Mittag, Larry, "Trends in hardware/software codesign," Embedded Systems Programming, January 1996, pg 36.