next up previous contents
Next: 2 Introduction Up: Appnotes Index Previous:Appnote Hardware / Software Codesign Index

RASSP Hardware / Software Codesign Application Note

1.0 Executive Summary

1.1 Overview

Hardware/Software (HW/SW) Codesign refers to the simultaneous consideration of hardware and software within the design process. Historically, signal processing systems have been designed by specifying the hardware and subsequently making the software fit. On the RASSP program, Lockheed Martin Advanced Technology Laboratories has changed this paradigm by tightly coupling the evaluation of software performance with the selection of hardware architecture and incorporating continuous re-verification throughout the process. Hardware/Software Codesign is the co-development and co-verification of hardware and software through the use of simulation and/or emulation. The emphasis of the RASSP program is on signal processing systems, which provides a very well defined application domain.

The RASSP process shown in Figure 1 - 1 begins with an architecture-independent data flow graph(s) representing the signal processing algorithms for the intended application. The graphs may initially be non-functional in the sense that they represent the desired data flow but not the functional details. During the process of selecting an architecture, the nodes of the data flow graph(s) are allocated to hardware or software. Allocation to hardware implies that special-purpose hardware will be used, while allocation to software implies that the processing nodes will be implemented on specific programmable processors. This allocation is initially performed using engineering judgement but may be modified as tradeoff studies proceed. The graph nodes allocated to software are mapped to the multiple processors in the architecture, and performance estimates are generated using VHDL token-based simulation. Timing data used in the simulations may either be estimates or benchmarked data on specific processors. During the architecture selection process, alternative hardware architectures are developed and iteratively optimized by modifying either the software mapping or the hardware architecture. Software is automatically generated for all of the mapped partitions and execution time is estimated for the target hardware.

Although the RASSP process fosters maximum reuse of both hardware and software, new software primitives or custom hardware is often required for an application. When custom hardware is required, HW/SW codesign refers to the process of model generation and the verification of the software on the hardware models prior to hardware build. In the case of new software primitives, HW/SW codesign refers to the process of software generation and verification on a hardware testbed or model(s) of the hardware to ensure both function and timing.

Figure 1 - 1: RASSP Design process.

Lockheed Martin ATL has implemented its Hardware/Software Codesign process as part of an overall RASSP design process. As shown in Figure 1-1, the RASSP design process is composed of three major functional processes called system design, architecture design, and detailed design. Hardware/Software Codesign is implemented from the initial partitioning of functions to hardware and software elements all the way to manufacturing release. At each step in the RASSP process, interactive simulation using hardware and software models is performed at equivalent levels of abstraction to verify behavioral operation.

1.2 The System Design Process

The system design process captures customer requirements and converts these system-level needs into processing requirements (functional and timing). Functional and timing analyses are performed to properly decompose the system-level description. The system process has no notion of either hardware versus software functionality or processor implementation.

The system requirements are translated into simulatable functions, which we refer to on RASSP as an executable specification. This represents the first level at which requirements are specified in a manner that we can readily match to simulators to verify performance and functionality in an automated manner. In this phase, processing time is allocated to functions and functional behavior is defined in the form of algorithms that are executable. At this point, all functions are implementation-independent. The executable specification represents a major portion of the systems design information model.

1.3 The Architecture Design Process

The architecture design process transforms processing requirements into a candidate architecture composed of hardware and software elements. This process initiates the trade-offs between the different architecture alternatives. During this process, the system level processing requirements are allocated to hardware and/or software functions. The architecture process results in a detailed behavioral description of the processor hardware and the definition of the software required for each of the processors in the system. The intent is to verify all of the code during this portion of the design process, ensuring hardware/software interoperability early in the design process.

The architecture process is driven from a data flow graph (DFG) description of the processing which is required. The DFG is an architecture independent description of the processing which must be performed by the signal processor. During the architecture process some of the functionality described in the DFG may be allocated to hardware while other functionality may be allocated to software to be executed on COTS DSPs. The architecture independent version of the DFG represents an application description which is the starting point for Hardware/Software Codesign on any particular architecture of interest.

This application note describes:


next up previous contents
Next: 2 Introduction Up: Appnotes Index Previous:Appnote Hardware / Software Codesign Index

Approved for Public Release; Distribution Unlimited Dennis Basara