next up previous contents
Next: 2 Overview of the Problem with Synthetic Aperture Array System Up: Case Studies Index Previous:Case Study SAR Index

SAR Case Study

1.0 Introduction

The Rapid Prototyping of Application-Specific Signal Processors (RASSP) program was a four-year DARPA and Tri-Service program that sought to dramatically reduce the time and effort to develop, produce, and maintain complex embedded digital signal processing (DSP) systems.

The program used design benchmarks to assess process improvements. This case study summarizes the first benchmark, describing tasks, demonstrated benefits, and lessons learned. The results of the benchmark were significant, including independently verified reductions in cycle time of 40 percent and reductions in software development time by a factor of seven.

1.1 Summary: Synthetic Aperture Array Benchmark

Benchmarks focus on board level and higher design problems while emphasizing the use of commercial, off-the-self (COTS) hardware and software. The first benchmark was the design and prototyping of a real-time processor for a Synthetic Aperture Radar (SAR) as defined by MIT Lincoln Laboratory (MIT/LL). The processor's specifications made it a realistic application for demonstrating RASSP's design process:

The benchmark's goal was to demonstrate the adaptability and flexibility achievable using RASSP's methodology and design environment. Using first-year RASSP concepts and tools, Lockheed Martin Advanced Technology Laboratories (LM ATL) demonstrated the following improvements as compared to traditional processes and as authenticated by MIT/LL:

Using the second-year RASSP autocoding tool suite for real-time application software development, LM ATL demonstrated the following improvements as compared to traditional processes:

The overall improvement using the RASSP design process was a 2.6X reduction in time-to- prototype

1.2 RASSP Process: Infrastructure, Model-Year Architecture, and Methodology

The Advanced Technology Laboratories used three technology thrusts to achieve RASSP's program goals: Paragraphs 1.2.1 through 1.2.4 describe what ATL did, significant results it achieved, and lessons it learned at each step in the design flow. There is a special emphasis on performance modeling and virtual prototyping with VHDL (VHSIC Hardware Description Language) and top-down-application code development from data flow graphs with autocoding.

1.2.1 System Design

Business Week reported that management commits 60 to 80 percent of a project's total cost up front, which means decisions focus primarily on the current development phase and not on a project's overall life cycle. (Fig. 1- 1)

1 - 1: Chart shows costs committed versus costs incurred in typical design cycle.

Lockheed Advanced Technology Laboratories' team used tools that helped requirement capture and analysis; functional design; and cost, reliability, availability, and maintainability analysis. Cost analysis evaluated life-cycle and development costs for the SAR system. The team accomplished in less than two labor months SAR's system requirement capture, analysis, and partitioning. This resulted in hardware and software module specifications that were generated automatically from a single complete, consistent, and traceable database.

The RASSP SAR benchmark demonstrated a top-down design process that moved from an Executable Specification, through performance modeling, to a full behavioral virtual prototype using models written in a single language (VHDL).

1.2.2 Architecture Design

Lockheed Martin Advanced Technology Laboratories studied eight architectures for the optimal design, and it selected an architecture with the following characteristics:

The study produced an abstract behavioral description of the hardware/software architectural elements that ensured interoperability early in the design process.

The Team captured SAR's design in a single-language (VHDL), hierarchical virtual prototype. It used the prototype to verify design performance from the initial concept of the multiprocessor system through synthesizable Register Transfer Level (RTL) descriptions. This allowed the algorithm's performance to be verified and the required DSP harware to be determined before purchasing or designing and hardware.The use of a single language enabled the Team to add more fidelity to the virtual prototype as the design progressed and as perceived risk indicated. High-risk areas were modeled at lower levels of abstraction, while low risk areas were modeled at higher levels of abstraction.

The Team optimized the mix of COTS and custom hardware to gain a significant cost and size advantage over an all- COTS implementation. A custom interface and a FIR filter module easily integrated with COTS DSP Modules through a COTS backplane, which used a standard interface. This combination provided a smaller and cheaper solution than either an all-COTS or custom-equipment approach. The industry standard interfaces and autocoding software development tools provided an upgrade path that continually reduced support costs through model-year upgrades.

RASSP's autocoding tools were initially unavailable for the SAR benchmark, so software development and coding were done manually. When the tools became available six months later, after successful completion of SAR acceptance test, the team generated application code from the data flow-graph description of the required signal- processing algorithm and mapped the code to the architecture. Compared to manual coding, autocoding reduced application development time by 7X and development cost by 4X, and the improvements included the time to learn the tools. The autocoded software generated using the beta version of the autocoding tools was within 10 percent of the processor's efficiency of the manually generated and optimized code. The Team also improved software productivity by successfully elevating the level of abstraction, at which most design and development work occurs, and by eliminating the need for a large programming team. The combination of graphical program specification and autocoding allowed the designer to concentrate on meeting system-level design requirements and minimized the designer's need to track low-level details of interprocessor communications and memory management.

It is typical to consider emerging technologies during a development effort. The COTS AD21060 (SHARC)-based DSP Module was such an emerging technology but it was unavailable when the Team needed it. Because of the earlier architecture design study, the team quickly chose the alternative COTS i860 based DSP product without a substantial loss of time and effort.

1.2.3 Detail Design

The Team designed custom hardware modules in a conventional manner except to generate VHDL models for the boards and to verify by insertion into the virtual prototype. There were delays due to problems using a new Field Programmable Gate Array (FPGA) with beta layout tools from a vendor. The Team completed the design of two new modules for the SAR system in a normal 26-week design schedule; however, the design included a full virtual prototype of the system, which resulted in enhanced quality. The SAR processor design had no redesign iterations and only two white-wire corrections on one custom printed wiring board.

1.2.4 Integration & Test

The Team quickly fabricated and assembled the SAR's modules. Total system integration took about two months but was delayed by defects in a number of areas:

The team used the virtual prototype to diagnose the defects with the following results:

The SAR processor passed the formal acceptance test conducted by MIT/LL and met all specifications.

This case study describes the RASSP experience early in the program. The methodology document and other case studies and applications notes on this web site provide further information on the RASSP methodology.


next up previous contents

Next: 2 Overview of the Problem with Synthetic Aperture Array System Up: Case Studies Index Previous:Case Study SAR Index

Page Status: in-review, January 1998 Dennis Basara