RASSP Virtual Prototyping Application Note

3.0 Example - SAR System Virtual Prototype

The Digital Signal Processing (DSP) subsystem of a Synthetic Aperture Radar (SAR) system was virtual-prototyped under the RASSP Benchmark-2 project. Details of the SAR project can be found in the SAR Case Study.The virtual-prototyping was conducted by Lockheed Martin's Advanced Technology Laboratories (ATL) in VHDL for relatively seamless transition to the down-stream detailed design processes.

The design risk assessment indicated the most significant challenges involved integrating and coordinating the various hardware and software elements into a system of multiple cooperating PE's. Because the hardware and firmware elements were selected from COTS products, they effectively became validated by default. Therefore, the design team considered the prototyping of the complete hardware-software multi-processor system to be more important than modeling the operation of an individual sub-section of the architecture.

Preliminary design and modeling produced a performance model of the integrated system. The performance model assisted in:

partitioning the application software tasks,
mapping the software tasks to processor elements,
scheduling the tasks, and
selecting the network architecture.

The performance model indicated that the selected partitioning/mapping/scheduling solution could satisfy the processing throughput requirements. This assumed that the selected solution would produce the correct numerical results. However, because the performance model does not actually perform the numerical computations, it could not verify the numerical correctness of the solution, nor could it show the data values processed at any point. Therefore the performance model could not serve as a total concept validation.

To further validate and develop the design solution, a more thorough prototype of the system was needed. Specifically, an abstract-behavioral model was needed to describe not only the timing and structure, but the functionality as well.

Because the performance model was carefully constructed in VHDL for extensibility, a new modeling effort was *not* needed to construct the prototype from scratch. Instead, the whole performance model was re-used by simply adding the missing functionality to it, as shown in figure 1. In this way, the performance model was extended to an abstract-behavioral model. It is abstract because it does not resolve the actual bit-representations of the values or structures. It is a behavioral model because it describes both functionality and timing aspects. See the VHDL Taxonomy document for more details on these concepts.

Figure 3 - 1: Extending performance model to abstract-behavior virtual-prototype

The new model served as a true prototype for the system. It responded in value and time as the designed target system would. It is a virtual-prototype, because it is not a physical construction, but exists as a software-based simulation.

Specifically, the compute subroutine, which consisted merely of a time-delay statement in the performance model, was augmented to include calls to the actual numerical subroutines, such as FFT and vector multiply. The token-definition was extended by adding one field to hold the data being transferred between processors.

An error in the assumed sequence of data arrival at a compute-node was discovered by the virtual prototype. This allowed the error to be isolated and quickly fixed prior to delivery of the hardware.

The abstract-behavioral model was later extended by incorporating a detailed register-transfer-level (RTL) model of the system I/O-board. This demonstrates the extensibility of this method, as well as the need to carefully consider the appropriate way to structure each abstraction level ahead of time.

When the physical hardware became available the software, which had been developed and tested abstractly on the virtual-prototype, was quickly ported and began running on the physical system. Because the application software had been pre-validated, some minor debugging issues were quickly isolated to a sporadic I/O device. The system was running correctly and meeting performance requirements within only about two weeks after porting began.

The Need for Abstraction

The VHDL virtual-prototype consumed 14 CPU-hours to execute 5-seconds of simulated runtime of a 6-processor version of the system. The simulated processor elements were Intel i860s which execute 40-million instructions per second. Because the virtual-prototype used abstract behavioral models of the processors, it does not explicitly model the individual instruction cycles. Considering the number of processors simulated, their instruction rate, and the duration of the simulation, the effective execution rate of the aggregate model was 23,810 instructions per second.

In contrast, a less abstract model of the processor, known as an instruction-set-architecture (ISA) model exhibited about 5.5 to 7.5 instructions-per-second on a Sparc-10 CPU. It is very clear that prototyping significant segments of the multi-processor system could not be practical with such a model. ISA models are more useful for understanding the behavior of software segments that dwell within a given PE. Table 3 - 1 compares the relative execution rates of the various model types.

In summary, rapid virtual prototyping of complex systems is made practical through appropriate use of abstraction. The virtual prototype was found to accurately model the numerical results and time-related performance within a few percent of the eventual physically constructed system.

Table 3 - 1: Comparison of simulation efficiencies for types of models in the design process

Next: Up: Appnotes Index Previous:2 Introduction to Virtual Prototyping

Approved for Public Release; Distribution Unlimited Dennis Basara