Next:
Up: Appnotes Index
Previous:2 Introduction to Virtual Prototyping
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:
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.
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.
Next:
Up: Appnotes Index
Previous:2 Introduction to Virtual Prototyping