Executable Requirements: Opportunities and Impediments

Transcription

1 Executable Requirements: Oppotunities and Impediments Executable Requirements: Opportunities and Impediments G. A. Shaw and A. H. Anderson * Abstract: In a top-down, language-based design methodology, requirements can be specified in an executable format, reducing the ambiguity typically encountered with written requirements, and serving as the starting point for the evolution of more detailed requirements and design specifications. As part of the Rapid Prototyping of Application Specific Signal Processors (RASSP) program, a VHDL executable requirement was constructed to capture the interface timing and functional requirements for an embedded processor intended to form images in real-time for a synthetic aperture radar. This paper includes a brief description of the application, then describes the implementation strategy and issues associated with the development of the VHDL executable requirement, emphasizing the importance of the VHDL test bench concept. Anticipated benefits of widespread utilization of VHDL executable requirements are discussed along with potential impediments to adoption. Areas for additional research and development are identified. Introduction Traditionally, requirements for an embedded signal processor are conveyed in the form of paper documents. This method of conveying technical requirements is subject to omissions, ambiguities, and errors on the part of the requirement generators (authors) and recipients (readers). In many instances, the written requirements are supplemented with supporting analysis and simulations, but this aggregate of requirements documentation must still be manually interpreted and judiciously applied to evaluate the adequacy of candidate hardware and software designs. During the course of design, it may be necessary to map written requirements into several different tools to assist in requirements tracking and allocation, performance analysis, simulation, and test development. Each mapping of requirements into a tool adds to the total design cost, and introduces opportunities for mis-communication and error. Executable requirements, when used in conjunction with a language-based design methodology, reduce the need for manual mapping of written requirements into diverse design tools. Requirements for embedded signal processing systems may address a wide range of issues including: Performance measures (e.g. P /P, SNR) Signal transformations (algorithms)

2 Modes of operation and control Interfaces, including timing and data formats Test capabilities and standards Implementation constraints (size, weight, power) This paper describes our experience with the development of an executable requirement detailing the algorithms, modes of operation, interface timing, and performance, of a synthetic aperture radar (SAR) processor. VHDL VHDL was developed in support of the DARPA Very High Speed Integrated Circuits (VHSIC) program, and became an IEEE standard (1076) in VHDL was developed to support the simulation and documentation of digital hardware, and a subset of the language is also appropriate for synthesis. In addition to these unique capabilities, VHDL also has many features in common with conventional programming languages, borrowing heavily from Ada and Pascal for language constructs and syntax. Conventional programming languages, such as C, and mathematical modeling languages, such as Matlab, are frequently used to develop simulations of signal processing systems. However, these languages do not provide standard representations for timing, or the concurrence inherent in signal processing algorithms. VHDL provides for the representation of both timing and concurrency, and represents a common language for modeling, simulating and synthesizing digital systems. The use of VHDL to model and synthesize designs at the chip-level is becoming common practice, but application to board level and higher design problems is still rare due to limited availability of models, long execution times for simulation, and lack of established methodology. An important concept in the application of VHDL to any level of design is the test bench. As shown in Figure 1, the purpose of a test bench is to verify correctness of a VHDL model. While the concept originates in the context of testing a model of an integrated circuit, it is applicable to all levels of model abstraction. Properly constructed, a test bench can be used to test and verify successively more detailed models of a design unit, whether the design unit corresponds to an integrated circuit, a board, or an entire system. The test bench concept, combined with the simulation capability of VHDL, provides a basis for the development of executable requirements. Figure 1: VHDL test bench concept. VHDL Executable Requirement

3 The executable requirement described in this paper models the behavior (i.e. the required algorithm functionality and allowable latency) of a polarimetric synthetic aperture radar, with detailed timing requirements modeled at the interfaces between the processor and the radar system. The executable requirement also models eight control commands associated with initialization and execution of the processor. The executable requirement consists of: Input stimulus in the form of synthetically generated or recorded radar data A test bench for supplying the data to the SAR processor model, capturing processed output images, and verifying overall correct performance A behavioral model of the SAR algorithm A set of reference images for use in verifying correctness User's manual Except where compatibility with external interfaces requires it, the executable requirement intentionally avoids providing any information about hardware implementation or structure, allowing for maximum flexibility in architecture selection and detailed design. The two-fold purpose of the executable requirement is to detail the processor requirements, and provide a fully functional test bench for use in verifying more detailed VHDL structural models of the processor, termed virtual prototypes. The algorithm flow, which the processor must implement simultaneously on three independent polarization channels, is shown in Figure 2. Except for the size, weight, and power constraints, all of the performance requirements listed in Table 1 are accounted for in the executable requirement.

4 Figure 2: SAR image formation algorithm flow. Performance and Utilization Using the Vantage VHDL simulator, the executable requirement took 142 minutes to process one range-doppler image on a Sparc-10, and required a minimum swap space of 250 MB for efficient execution. The arithmetic processing required to form an image for one of the four available polarizations is about 390 Mops, comprised mainly of floating point multiplies and adds associated with FFT computation. However, as shown in Figure 3, the time consuming part of the executable requirement simulation is associated with the transfer of the 25 MBytes of information between the test bench and the processor. The range processing requires about 3 minutes, with 85 minutes required to simulate the data transfer. The large amount of time required to simulate the data transfer is a consequence of using VHDL signals to model the bit-level transfers at the interface of the processor. The azimuth processing, which accounts for 64% of the computation (250 Mops), requires only 6% of the total simulation time to complete because it does not use signals to model detailed timing. Instead, a maximum allowable latency is assigned to the computation. Comparison of the output of the VHDL simulation to reference images obtained from a C-language implementation of the algorithms shows agreement to within the 64-bit floating point precision of the machine. Figure 3: Data flow and execution times for one image frame.

5 Table: SAR Processor Requirements In connection with the ARPA RASSP program, the executable requirement was given to two independent development teams, Sanders and Lockheed Martin Advanced Technology Labs, as the basis for designing an embedded real-time processor. The developers were required to define several different implementations, perform a trade-off analysis of these implementations, choose one system, develop a VHDL virtual prototype of the chosen system, and build a physical prototype based on the virtual prototype. Both developers experienced difficulty in their attempts to use the executable requirement as a development tool, primarily due to its long running time. It was used to generate partially processed data sets which were used as input to a Matlab simulation. The developers were successful in building VHDL virtual prototypes which were simulated with the test bench included in the executable requirement [2]-[3]. The virtual prototypes produced SAR images which satisfied the error criterion of the requirement. ATL's virtual prototype was built to be scalable so that smaller sets of data could be processed with sufficiently short elapsed time to be useful for development purposes. As the executable requirement was exercised, several inconsistencies between the written requirements and the executable requirement were uncovered and corrected. A number of requirements were also found to have been omitted from the written document, but were, by necessity, defined in the executable requirement. Examples of information inadvertently omitted from the written requirements, but incorporated in the implementation of the executable requirement, include the initial conditions for convolution filters, and the number of bits involved in preamble detection of radar pulses. The executable requirement for the SAR processor is fully documented, and has been utilized not only in the RASSP program, as discussed above, but also as a benchmark for performance of commercial and military multiprocessors, and as a test case for the development of design automation tools. Opportunities

6 Design Verification: The executable requirement complements the written requirement by offering greater detail and precision, and proving, through successful execution, that all necessary parameters are defined. Properly constructed, the test bench for the executable requirement may serve to test more detailed models of the hardware and software throughout the design process. Life Cycle Support: Since VHDL is an IEEE standard, the executable requirement, written in VHDL, represents a portable, machine-readable standard for documentation, and a vehicle for facilitating future upgrades and design trade-offs. Reuse: Components of an executable requirement, such as algorithm definitions and interface requirements, are candidates for reuse in developing new system requirements. The reuse components have high value due to the fact that they have been verified to be correct. Virtual Prototype: The use of VHDL executable requirements facilitates and promotes the development of VHDL virtual prototypes. Virtual prototypes have proven value in uncovering and correcting design defects prior to the costly step of physical prototyping. Impediments A number of practical considerations and potential impediments must be considered in developing a top-down design methodology employing executable requirements. Simulation Resources: Realistic problems can require an excessive amount of simulation memory and compute cycles if the amount of detail included in the model is not carefully managed. Detailed models, which capture clock cycle events, should be used only to verify proper interface timing over small intervals of time. The process of establishing the appropriate levels of model detail (abstraction), and the combinations of models necessary for verification, is a critical element in successful implementation of a top-down design methodology. Language Expertise: While VHDL is widely used by hardware designers, and might serve the needs of system analysts, most system analysts currently rely on more familiar tools, such as mathematical modeling languages or conventional programming languages, to develop simulations and analyze performance. Widespread adoption of VHDL-based executable requirements is therefore best served by augmenting existing system analysis and design tools with the capability to generate VHDL models of algorithms and architectures, rather than attempting to convert system analysts to the use of VHDL. Language Interfaces: The VHDL-93 language standard includes a FOREIGN attribute predefined in package STANDARD to allow a subprogram or an architecture body to have non-vhdl implementations. However, mechanisms for passing parameters are not included in the language standard, with the result that there is no fully-defined standard for interfacing VHDL to other languages. In the SAR executable requirement, the algorithm implementation was translated from C to VHDL to insure portability. For reasons of efficiency and portability, a fully defined foreign language interface is needed. Verification Methods: The application for which the executable requirement described here was generated corresponds to an existing sensor, data, and fully defined algorithms. Since both the sensor and image formation algorithms are well defined, a verification metric for the VHDL test bench is relatively straight-forward to define and implement, consisting of a pixel-by-pixel comparison of a known good reference image to the output image produced by the VHDL model. In cases where the sensor and algorithms are less well defined, the

7 challenge in developing executable requirements is to accommodate the uncertainties in both the algorithm representation and the accuracy criteria. Conclusion A VHDL executable requirement for an embedded signal processor has been successfully utilized as the basis for conveying and verifying performance requirements at the processor system level. Experience with the executable requirement has shown it to be a valuable tool for documenting and verifying system requirements. VHDL provides a standard, portable environment in which executable requirements can be elaborated into virtual prototypes to capture the data concurrency, structure, and timing of a processor design. The cost of this added capability, relative to functional-only simulations, is increased simulation time and program memory. The added cost can be minimized by sparing use of signals, scalable data sets, and judicious selection of levels of abstraction in modeling. VHDL executable requirements and specifications have the potential to significantly reduce the life cycle cost of embedded processors by providing accurate, enduring documentation of both the required performance and the actual design of a system. Additional details regarding the implementation and performance of the executable requirement, and its application to design, can be found in [1]-[4], and at the web site llrassp/. References 1 A. H Anderson, G. A. Shaw, C. T. Sung, `` VHDL Executable Requirements,'' Proceedings First Annual RASSP Conference, Arlington, VA, August 1994 pp E. Rundquist Jr., ``RASSP Benchmark-1: Virtual Prototyping of a Synthetic Aperture Radar Processor,'' Proceedings Second Annual RASSP Conference, Arlington, VA, July 1995 pp J. Pridgen, R. Jaffe, W. Kline, ``RASSP Technology Insertion into the Synthetic Aperture Radar Image Processor Application,'' Proceedings Second Annual RASSP Conference, Arlington, VA, July 1995 pp A. H Anderson, G. S. Downs, G. A. Shaw, `` RASSP Benchmark-1 and -2: A Preliminary Assessment,'' Proceedings Second Annual RASSP Conference, Arlington, VA, July 1995 pp Dr. Gary A. Shaw Allan H. Anderson This work was sponsored by the Advanced Research Projects Agency, Electronic Technology Office. Top Home Quick Links Search RASSP Home Disclaimer Direct comments and questions to: ruscitti@ll.mit.edu

8

9

10

11

12

13

14