System Design

By using virtual prototypes based on an HDL for whole-system simulation, designers can get information about their systems that is nearly impossible to obtain from hardware prototypes. Virtual prototypes deliver this information with extremely high accuracy and at running speeds orders of magnitude faster than those of conventional simulation.

The power of a virtual prototype lies in its ability to make all aspects of a system visible and interactive. Even before building a system, designers see the activity of processor registers, bus transfers, memory accesses, and I/O controllers. Actual software and firmware runs on this virtual system, allowing designers to make tradeoffs by changing system parameters and watching the results.

While these capabilities prove valuable before a physical prototype is available, they can be equally useful after a physical system has been built. The virtual prototype described in this article is such a case. A company had developed and built a digital image-processing system and wanted to upgrade the design. To evaluate factors that were hard to see in the physical system, the company contracted with CPU Technology Inc. (Pleasanton, CA) for a SystemLab virtual prototype.

The four-processor system in hardware The image-processing system matches video inputs to known patterns, completing each recognition cycle within a fixed interval. This real-time system consists of four PCBs, each with its own 32-bit IDT MIPS R3081 processor and peripheral functions (see Figure 1 ). Three of the boards provide general-purpose image-processing support, while the fourth handles digital camera control and first-level image filtering. The boards communicate with one another via a quad-port memory subsystem that utilizes a "mailbox" structure.

The goal of upgrading the design was to create a more integrated version that provided higher throughput. The designers wanted to evaluate the system's architecture to see whether it could be made more efficient without making it more complex. In fact, the designers wanted to simplify the system to make it easier to integrate into ASICs. To do that, the designers needed to probe inside the chips--especially the processors--and monitor many different I/O lines simultaneously. Physical probes could not do the job.

The solution was to emulate the system in software with a virtual prototype. To enable CPU Technology to set up this software emulation, the designers supplied information such as a high-level block diagram of the system, functional specifications for each block, device latencies, and a programmer's view of the system.

The science of system simulation Simulating the image-processing system using RTL-level VHDL or Verilog code was impractical for several reasons. VHDL/Verilog models for the processors were not available, for one thing. But even if they were, the sheer size of the simulation would be prohibitive, with simulation speeds of one or two clocks per second. VHDL and Verilog were designed for creating gate/transistor representations of digital logic. They are not optimized for behavioral descriptions and are thus poorly suited for simulating an entire system.

To remedy this shortcoming, CPU Technology developed an HDL called the SystemLab Behavioral Language specifically for system simulation. This language represents common digital functions at a much higher level than VHDL or Verilog, reducing code size by a factor of 10. A 16-bit multiplexer can be specified in just one line of SystemLab Behavioral Language code, for example. On average, the language needs 10 bytes of memory to represent each gate. Thus, even extremely complex systems can be simulated on a personal computer.

At the same time, SystemLab Behavioral Language code is binary accurate. At the level of registers and pipelines, designers can see exactly what would be going on in a physical processor chip--if they could see inside the physical chip. The code can even be translated into VHDL or Verilog.

To create a virtual prototype, CPU Technology develops behavioral models for each block. Blocks are defined in terms of their interfaces (inputs and outputs), functions, and cycle-based timing characteristics. All the blocks are then connected to make the system model.

Figure 1. System block diagram. The system incorporates four cards, each with an IDT R3081 processor and various memory and I/O devices. The four cards communicate with one another using a quad-port memory.

The four-processor system in software In the case of the image-processing system, the modeling process resulted in a fully functional model that executes instructions on all four R3081 processors, provides assembly and disassembly capabilities, and offers numerous instrumentation views for observing system behavior. Figure 2 shows a portion of the virtual prototype.

External events such as I/O streams are also modeled. For instance, the data stream from a digital camera is modeled by furnishing actual camera data from a memory array via a FIFO structure that has a programmable fill rate. The system can read this data under software control. Similarly, actual firmware and software are loaded into the system's EEPROMs and SRAMs.

The CPU Technology team took less than six weeks to specify, create, and validate the virtual prototype of the image-processing system. Although absolutely perfect accuracy is impossible, the virtual prototype comes remarkably close. Running the same user code as the physical system, the virtual prototype provides 99.97 percent accuracy. The SystemLab prototype is therefore as accurate as the crystal on which the system clock is based.

Running on a 100MHz Pentium-based PC, the virtual prototype simulates 460 clocks per second. That includes all four processors, memories, I/O devices, external events, etc. With a real-time interrupt every 2.5msec, the prototype takes less than three minutes to simulate one complete recognition cycle. Thus, every three minutes designers can see every function the system performs.

Figure 2. System visibility. Signal values and internal states of processors and system devices are shown. Most of this information is not visible in the physical system. The waveform display shows a history of this processor's local bus activity.

Virtual instrumentation In a physical system, designers observe hardware events by applying probes; software behavior is captured by having one software routine interrupt and trap the results of another routine. Both of these procedures can change system behavior.

In contrast, the virtual prototype "captures" behavior using real-time non-intrusive instrumentation (RTNI). As the model runs, designers can watch graphs and readouts showing parameters such as processor MIPS, processor utilization, bus utilization, cache hit rate, I/O throughput, instruction mix, and software execution time (see Figure 3 ). It is even possible to see the image with which the system is working at any given time and watch the image change as filtering and other algorithms are applied.

RTNI avoids unwanted changes to system behavior, but desired changes are easy to make. SystemLab prototypes allow designers to alter virtually any factor in the system, including memory wait states, address ranges for each device, input data rates, the size and latency of caches, and many other parameters.

In Figure 3 , for example, the uppermost box that stretches horizontally across the width of the screen lists the wait states for each of the memories in the system. By placing the cursor on any of these values and changing it, the designer instantly alters that parameter. The results are reflected in the way the model behaves.

This capability allows a designer to determine in a matter of minutes whether it makes sense to change some aspect of the system. Would it be cost-effective to optimize the EEPROM interface, for example? By setting the EEPROM wait states to zero and observing the performance graphs in further simulations, designers could find out exactly how much overall improvement was possible.

Figure 3. Performance monitoring. Many different aspects of the system performance can be measured and displayed using bar graphs. Processor MIPS, cache hit ratios, and instruction mix statistics are shown here.

Because the virtual prototype allows designers to see inside the processors, it was possible to evaluate changes there, too. Designers could see whether the system performed efficiently enough to meet real-time limits without the processor's internal cache, for example. When building an integrated version of the system using an R3000 core, being able to forego the cache memory would allow significant space/cost savings. The virtual prototype allows visibility into many processor mechanisms, including the internal buses and even the pipeline stages.

Revealing problems and solutions Using the virtual prototype, the designers of the image-processing system found a variety of hardware and software problems and quickly solved them.

One challenge was to improve system throughput. As shown in the processor performance graph in Figure 3 , this processor was executing barely 5 MIPS, but its peak on a benchmark was 30 MIPS. The processor was performing far below its capacity, and a faster processor could hardly be expected to do any better.

It turned out that a DMA controller was choking the processor by taking too many bus cycles. The cause of the problem became clear when the designers looked at the bus utilization bar graph. The bus was in constant use, but the processor clearly was not getting its share. The culprit had to be the DMA controller. Ironically, the DMA controller had been added to increase the processor's speed. By giving the controller a private path to memory, the processor's performance rose dramatically. The value of this simple architectural change was quickly verified with the virtual prototype.

Another processor issue was the need to complete all the image-processing tasks within the system's 2.5msec real-time interrupt (RTI) period. The existing design met that goal, and designers wanted to know how much time was left over. How much headroom did the system have?

The virtual prototype's processor utilization graph showed exactly how much headroom the system had at any given moment. This bar graph measures task completion time with respect to the RTI period and varies over time with a "live" characteristic. By comparing the utilization levels for all the processors, designers could immediately see whether the load was balanced among the processors. In this case, the load was adequately balanced, but variations in the loads showed where to assign new tasks.

Figure 4. A variety of virtual systems. Virtual System Prototyping can be applied to a wide range of systems. This virtual prototype, consisting of a virtual PC system with a video display window and virtual keyboard input, is booting up the Windows operating system.

Tuning software on the virtual prototype The virtual prototype offers as many advantages to software developers as it does to hardware designers. In a typical design flow, the hardware design must be more or less complete and in physical prototype form before software developers can make much headway. But a virtual prototype can be created as soon as the system architecture is organized. Software developers can use this prototype as their initial development platform--an innovation that allows hardware/software tradeoffs to be worked out from the beginning of the design process.

In the case of the image-processing system, software and firmware had already been developed on the physical system. When that code was loaded onto the virtual prototype, however, several firmware errors became apparent. For example, power-on, self-test code verified that each processor was performing certain tasks correctly. If not, the firmware was supposed to flag an error. It turned out that the firmware detected errors but did not trap the errors correctly, so they went unreported. This fault was found using breakpoints and by checking where the program counter was going. The visibility provided by the virtual prototype made it easy to find and correct this problem.

A critical software issue for the image-processing system was the length of time spent in the interrupt service routine. A start/stop counter (a standard part of SystemLab models) measures this time interval so that both the hardware and software developers could easily compare results from one trial to the next. This capability allowed designers to see how to optimize the quad-port mailbox memory, for example. When one processor sends a message to another, the mailbox subsystem handles the interrupt sequence. By measuring this sequence with the start/stop counter, designers could tell exactly how much system overhead the mailbox subsystem put on the rest of the system. Because the instrumentation on the virtual prototype is non-intrusive, developers could get an accurate reading of how long the system spent executing any portion of the code.

Many features of the virtual prototype help software developers isolate errors. A good example is the prototype's ability to run forward or backward. Developers can set a breakpoint at an error routine then back up to see what caused the error. Backing up even further reveals the sequence that led up to the cause. Developers can then change values and run the prototype forward to see whether the error disappears.

Any type of digital system Virtual prototyping can be applied to a wide variety of systems, from personal computers to supercomputers. Both general-purpose computers and dedicated systems such as the image-processing system are candidates for virtual prototyping.

For example, Figure 4 shows a SystemLab prototype of a personal computer booting Microsoft Windows. System developers could use this prototype to optimize the PC's performance while maintaining strict compatibility with PC standards.

In addition to making the activities of a system highly visible to designers, a virtual prototype makes it possible to change parameters at any time and see the results instantly. System architects can rapidly make high-level tradeoffs before the detailed design begins. Or, as in the case of the image-processing system, designers can refine and debug an existing system in a much shorter time than would otherwise be possible.

Ed King is chief executive officer of CPU Technology Inc. (Pleasanton, CA), a company specializing in the research and development of computing systems for the Fortune 500 and the US government.

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

integrated system design  May 1996