The RASSP Digest

The Benchmark 1 Executable Requirement

The first RASSP benchmark, which was delivered to Martin Marietta and Lockheed Sanders by MIT Lincoln Laboratory in early August, included a tape cartridge with about 1/2 Mbyte of data and source code for an executable specification for a Synthetic Aperture Radar processor. The data is an accurate description of the signal transformations which the processor is to perform and it's system environment.

The use of executable specifications is essential to the RASSP Model Year concept which seeks to ensure that a signal processor will employ state-of-the-art technology when fielded and that it will be possible to upgrade the system throughout its lifetime. It is also a key to achieving improved design time and quality because it can provide a thread of evolving models from system definition to implementation.

What constitutes an executable specification and how to name the different varieties is a subject of active discussion, but common to all definitions is simulation of the processor in its environment. A design process can be thought of as a successive refinement and adding of detail to a processor model beginning with initial requirements and ending with a virtual prototype which models the hardware and software system in complete detail. An example of executable model evolution would include at least the three levels shown in the figure on page 16. They are:

1. Requirement - a simulation of the required signal transformations, with timing, in the environment in which the processor will operate. As shown in the figure on page 16, the environment includes a signal source, a controller and a data sink which may perform comparisons with a desired output. These comprise a testbench for the processor which will be used throughout the development to ensure conformance with the requirement.

2. Conceptual - simulations with different algorithms and performance models for exploring design tradeoffs. Each conceptual model may contain modules at different levels of detail.

3. Virtual prototype - the final model with the processor partitioned into software and hardware modules. The virtual prototype's output will be identical to that of the final system and it is the definitive definition of the processor. Certain virtual prototype modules may serve as source for hardware synthesis.

The Benchmark 1 design exercise calls for creation of a virtual prototype for a real-time SAR processor for an existing radar, the MIT Lincoln Laboratory Advanced Detection Technology Sensor (ADTS). The ADTS radar is a fully polarimetric Ka-band radar installed in a Gulfstream G1 aircraft which has flown about 400 data collection missions. The processor is specified so that it could be installed in the aircraft or on a UAV and create real-time images from ADTS data. At the peak rate of about three images per second a one-gflop/sec processor is required.

Since Lincoln Laboratory was working with an existing system this requirement has some of the characteristics of a system upgrade. The data input interface to the processor and data formats were completely determined and real data was available. There was some freedom for Lincoln in specifying the data output format and port and the control interface is a new design which is not completely specified to the two design teams.

The sponsors and Lincoln decided to create an all-VHDL Executable Requirement. The SAR strip map algorithm was implemented in VHDL through a straight forward translation of an existing C program. It primarily uses real and integer variables and VHDL signal variables very sparingly and executes the algorithm in zero simulated time. The VHDL created strip maps are essentially identical to those created with the C program. Data timing is modeled at the processor data input and output ports and the user can set processor latency between 0.1 and 3 seconds.

The VHDL testbench simulates the sensor system output by reformatting data from disk files and presenting it to the processor at the proper simulated time. It presents commands and setup data to the processor as a simulated host and writes output data from the processor to files and compares it with other disk file data. Latency is measured and compared with a user supplied reference. The processor and testbench model comprise 2430 lines of VHDL and use an existing math library.

The VHDL processor simulation is about 25 times slower than a C program for the math parts of the SAR algorithm, that is, an FIR filter, FFTs and vector multipliers. However, for the entire simulation with I/O, data reformatting and the small amount of timing simulation, the VHDL simulator is about 200 times slower than the C program which does no timing simulation. To simulate one frame of 512 pulses, for one polarization, in the Vantage Spreadsheet simulator requires about 2 1/2 hours on a Sun SPARC 10/51 workstation. This running time is acceptable for doing a requirement simulation but not when the testbench is used with processor models for conceptual design. Lincoln Laboratory is doing further work to identify any inefficiencies which may be contributing to run time.

The simulation was written to run on any IEEE STD 1076-1987 compliant simulator. Successful runs on Vantage Spreadsheet, Mentor QuickVHDL and Cadence Leapfrog simulators at Lincoln Laboratory and Lockheed Sanders, Martin Marietta and Wright-Patterson Air Force Laboratory, respectively, are proof of success.

The simulation runs were done on different, but similar, uniprocessor workstations and no dramatic differences in run time was observed.

The delivered testbench will be used to exercise the virtual prototypes created by the developers. The second benchmark will probably be a prototype hardware implementation of the SAR processor and for that development Lincoln Laboratory is building a hardware testbench which will source and sink data in real time.