SAR Case Study

3.1 System Process Description

The first step captured the requirements in the form of simulatable functions, or "executable specification." An Executable Specification is a description of a system or subsystem that can be executed in a computer simulation, the purpose of which is to reflect the precise behavior of the intended system. All functions were independent of implementation at the level of the Executable Specification. MIT/Lincoln Laboratory (MIT/LL) generated the Executable Specification for the synthetic aperture radar (SAR) processor and delivered it to Lockheed Martin Advanced Technology Laboratories (LM ATL) as part of the SAR's processor requirements.

3.1.1.1 Hierarchical Simulation

Virtual prototyping played a major role at each level of the top-down design process. Prototyping began at an abstract level and proceeded to more concrete descriptions as details resolved. Models supported the process at each level of abstraction to verify distinct aspects of the system and its components. The resulting hierarchical model set would support model-year upgrades by providing various degrees of implementation-independent description of the system's functionality.

Virtual prototyping began with an Executable Specification that described the system's signal-processing requirements. Refinement of this specification was a joint effort among contractor and customer to obtain a top-level design guideline that captured the customer's needs. The Executable Specification removed ambiguity associated with written specifications. Token-based performance-model virtual prototyping determined resource requirements like number of processors and memory requirements.

Developers evaluated the impact of different mappings of software functions to processing hardware. At the next level, an abstract, behavioral, virtual prototype verified the correctness and performance of the signal-processor design. At the lowest design level, a detailed behavioral virtual prototype described clock-cycle and bit-level details of the new hardware. All virtual-prototype models verified hardware/software interaction. Table 3- 1 summarizes the purposes of the primary virtual prototype models.

The system engineering tools were not integrated during the SAR benchmark instead the tools were used individually. The SAR results and templates were used as examples to drive the tool integration and define the data exchange necessary for systems trade-off studies. See the RASSP System Process application note for more information on the RASSP system design process and the use of the Integrated System Engineering tools, ISE ( Figure 3 - 2).

Requirement names are in the center of each requirement block. Each requirement name has a prefix that indicates the origin or the level of the requirement. An example is requirement 3.1.1.1. Its name has the prefix SOW that indicates it originated in the BTD but that it may contain minor re-wording. A lesson learned was that all originating requirements must be kept in original form within the database. The CIDS requirements must be separate entries in the database with traceability to the BTD requirements.

In the requirements diagram, all requirements with a black square in the upper left corner have further decomposition and allocations that can be retrieved by clicking on that requirement. In a more complex system, the whole process would be repeated at each subsystem level.

After generating the CIDS, developers performed Requirements Analysis in parallel with Functional Analysis and System Partitioning tasks. An example is requirement 3.2.1.2.2 SOW PRI Detection. Clicking on that requirement in Figure 3 - 3 displays the full decomposition, derivation, and allocation of the originating requirement. Decomposition refers to the action of separating multiple requirements into individual requirements. During decomposition, the form of the requirement does not change and only minor re-wordings or budgeting are permitted. Derivation of a requirement changes the basic form of the requirement to make it appropriate for a lower level subsystem. An example is a noise budget that can be decomposed into individual subsystem noise contributions, but it might be derived to word width and linearity for an A/D (analog to digital) converter.

The Executable Specification model included information on I/O (input/output) timing constraints, I/O protocols, I/O data formats, system latency, and internal function. The external ports were modeled with clock-cycle temporal precision and bit-true data values. By design, the Executable Specification did not contain information on hardware implementation or structure, except where compatibility with external interfaces required it. This allowed maximum flexibility in architecture selection and detailed design. The internal function did not contain timing, except for input- to-output latency. Data was expressed as floating point values.

The purpose of the Executable Specification was to detail processor requirements and to provide a fully functional test bench to verify more detailed VHDL-structural models of the SAR processor. Output images from the Executable Specification simulations were compared with outputs from functional simulations [VHDL virtual prototype (abstract and detailed behavioral), matlab simulations, and Processing Graph Method (PGM) Processing Graph Support Environment (PGSE) simulations] to determine the maximum pixel error difference (Figure 3- 4).

The processor model and test bench consists of about 2400 lines of VHDL code, and MIT/LL reported that the Executable Specification took about 1300 hours to develop. Some of this effort was attributable to first-time learning. Find more information on the Executable Specification in the following:

Although some experts believe a functional analysis can be independent of the system partitioning, the SAR Benchmark developers believe it to be impractical because each low-level function has to be allocable to only one subsystem and verifiable by a single test, demonstration, inspection, or analysis. In addition, some required functionality, such as subsystem-to-subsystem interfaces, may exist only because of the implementation. Ignoring this additional required functionality during a functional analysis can compromise the system-partitioning activity by ignoring its impacts on hardware loading and software timelines.

The functional decomposition of the SAR began with a simple behavior diagram that showed the SAR function, the outside world, and the data that was exchanged among these two functions. Figure 3- 5 shows the top-level behavior diagram generated from the RDD- 100 database. (See RDD- 100 Behavior Diagram Notation Tutorial.) This figure indicates that there are two major input-data types and two major data-output types. The SAR processor received control information and sensor data, sent diagnostic data, and processed output data to the outside world. It was not important for the design to know how the data was created or used in the outside world because the interface was well defined in the BTD.