Rapid Prototyping of Application-Speci c Signal ... - Semantic Scholar

Rapid Prototyping of Application-Speci c Signal Processors: Educator/Facilitator Current Practice (1993) Model and Challenges Vijay K. Madisetti 1, Jack Corley 2, Gary A Shaw 3 1 ECE - Georgia Tech, Atlanta, GA 30332-0250 2 ATG - SCRA, N. Charleston, SC 29418 3 MIT Lincoln Laboratory, Lexington, MA 02173-9108 1

Abstract The Rapid Prototyping of Application-Speci c Signal Processors (RASSP) project of the US Department of Defense (ARPA and Tri-Services) targets a 4X improvement in the design, prototyping, manufacturing, and support processes (relative to current practice). The authors present a \current practice (circa 1993)" model for the design and prototyping of application-speci c signal processors developed as part of the RASSP Educator/Facilitator (E/F) Program. A number of limitations in current design practice are highlighted together with challenges faced by candidate solutions. The E/F Program proposes that this model be used as a baseline in the evaluation of newer RASSP prototyping methodologies and processes.

1 Introduction

In this section we introduce classes of highperformance application-speci c parallel processors that are the subject of the Educator/Facilitator current practice (1993) study. In Section 2 we present \current practice (circa 1993)" based on extensive study of industrial practice rst-hand and through communications with various industrial and defense contractors at Lockheed Sanders, Martin Marietta, Hughes Avionics Systems, Motorola, MIT Lincoln Laboratory, and Raytheon corporations, by the authors as part of the RASSP Education/Facilitation and Benchmarking efforts over the past year. However, the viewpoints presented in this paper are solely those of the authors, and not necessarily of these organizations. Section 3 describes the challenges facing application-speci c parallel processor speci cation, implementation, veri cation and support, that the RASSP program attempts to address in the near future.

1.1 Representative Architecture

A typical high-performance avionics parallel signal processor operation ow is shown in Figure 1 [3]. The

1 This research has been supported by the Advanced Research Projects Agency (ARPA), Electronic Systems Technology Oce (ESTO) as part of the RASSP program.

Sensors

Displays

20-100 MB/s Sensor

Raw Data

Mission

Specific

Specific

Specific

OPs

OPs

OPs

200 GOPS

Fig 1.

Application

1-100 GOPS

0.05 - 0.1 GOPS

Typical System Architecture.

inputs are recorded by sensor arrays, and the data is pre-processed by an array of (typically hardwired) computational elements, comprising the sensor-speci c processing (SSP), that are optimized with the sensor array and the recording environment. Typical SSP operations include range adjustment, background subtraction, and matched ltering. Given the high computational throughput and restricted functionality, and severe form constraints (size, volume, area and power), the SSP functions are typically ASICs with non-standard interfaces. SSP functions are also referred to as time-dependent processing. After this time-critical processing is completed, the application-speci c (ASP) parallel processing (about 30-100 processors) is commenced on an array of processors and communications elements, with appropriate test, control, and maintenance structures. Typical ASP operations include coordinate transformation, track-to-track correlation, Kalman ltering, tracking, and parametric estimation and involve application related functionality. The ASP functions also require relatively high throughput, and it is desired that they have as much exibility (i.e., programmability) as possible, together with certain form factors. In an ASP implementation lie the multi-objective function optimization and tradeos among form factors, performance, programmability, ease of upgrades, and capability for test and diagnostics. ASP functions can also be referred to as object-dependent processing. The mission-speci c (MSP) processing typically requires interpretation of the ASP processing, and can be con ned to a few processors that are often co-located

within the ASP box. These functions include clutter analysis, track hando, decision analysis, kill assessment, etc. The relative orders of processing in GOPS are also depicted (decreasing to the right) in Figure 1; while memory requirements typically increase towards the right, with the most memory required by the MSP (typically 100-400 Mbytes) stage (because decisions could be made over multiple frames). Typical form factor constraints for volume, power, weight, and I/O rates are in the order of 2-10 cuf, 40-500W, 10-60 lbs, and 4-30 Mbytes/second, while for low-end low power portable applications they are considerably more severe (in size and power). Interprocessor communication bandwidth requirements can range between 40-1000 Mbytes/second.

1 Pre-Concept Exploration

Lifecycle Support Upgrade

6

2 Concept Definition/ Specification

3 Demonstration Validation (DEMVAL)

Production Deployment 5

Engineering Manufacturing Development (EMD) 4

Scope of this study

1.2 Architectural Design Space

Typical Signal Processor Development Phases

Fig 2.

A combinatorially signi cant number of alternatives exist in the implementation of the SSP, ASP, and MSP functionality, and a few key architectural attributes [3] are listed below: Computational Elements - types (data, control, ASICs, or DSP) of processors, coarse or ne-grain task assignment, heterogeneous or homogeneous processing, size of memory elements, degree of coupling between memory and processors, software and algorithms utilized, SIMD or MIMD types of control. Communication Elements - buses used, backplane architectures, interface to buses within system, interfaces to environment, routing and communications protocols. Topologies - allocation of physical resources (number of processors, memories, communication elements), interconnection topologies (ring, bus, etc) and technologies ( ber, parallel/serial, etc), I/O con gurations, integrated test and fault-tolerance capabilities.

Systems Requirements Definition 6-12 months

System Architecture Definition Optional

1.3 Typical System Speci cations

Manufacturing Planning

A number of speci cations/requirements form the input to the prototyping process (and they can be weighted in relative order of importance). These include, in no speci c order: (1) Functionality and Performance, (2) Environment, (3) Interfaces and Packaging, (4) Security, (5) Schedule for deployment, (6) Cost, (7) Software and hardware restrictions, (8) Size and volume, (9) Weight, (10) Power, (11) Reliability, (12) Maintainability, (13) Fault-tolerance, (14) Scalability, (15) Standardization. A successful design has to achieve a satisfactory degree of compliance with each of these speci cations [3].

Hardware Design

Software Design Interface

Hardware Manufacture & Test

Deliverables

2 Current Prototyping Practice

We now examine current practice (1993) in the prototyping of application-speci c parallel signal processors.

Design

25-49 months

Software Code & Test

Documentation

Hardware/Software Integration & Test

Production & Deployment

Field Test

6-12 months

E/F \Current Practice (1993)" Signal Processor Design Process. Fig 3.

2.1 System Development Phases

The lifecycle of a typical large system roughly follows the six phases shown in Figure 2. The focus of 2

this study is on phases 3 ? 6. Often, phase 3 is bypassed, and the sequence shown by the dotted-line is followed. In some cases, phase 3 follows 4, and is followed by phases 5 and 6. The dollar cost gures for each of these phases in terms of resources (capital and personnel) can run into few tens of millions in the initial phases of Figure 2, and as high as a few hundreds of millions (or more) in the later phases of system development, deployment and maintenance. The ratio of cost incurred/committed rises steeply with the onset of phase 3. Clearly, decisions and tradeos made in the early phases have signi cant nancial impact later in the system development lifespan. In addition, the long time span (often 8 ? 10 years) between phases 2 and 5 render some aspects of the technology obsolete by the time a concept is elded. While customer input is signi cant in phases 1 ? 3, it diminishes in phases 4 ? 6 leading to signi cant risks to the manufacturer in xed-price contracts, or to the customer via cost overruns when redesign or rework is required. The lifecycle support (phase 6) for the deployed system can last between 10 ? 30 years. The capability for rapid upgrade is an eective insurance against technological obsolescence of the elded system [7].

Mission requirements (functional and form constraints and goals - power, weight, volume, throughput, ...) Production Requirements (Manufacture/Test) - cost/schedule - methodology (HW, SW, test) Operational Description - environment, user, signal

Optional Sensors & Actuators Choice of DSP Algorithm

Representative Tools

4-6 months

Systems Requiremens

Editors Spreadsheet (BONeS) RDD-100, RTM F2D2 etc

Definition

- Operational scenarios - Algorithm - Risk areas/mitigation

3 E/F Current Practice (Circa 1993)

Requirements ‘‘db" Analysis report - Completeness report clarity, testability, compatibility meets operational scenarios - Cost Tools - Traceability VHDL Simulators

- Development plan

Figure 3 presents the E/F current practice model for system design. The various stages in a \waterfall"type process ow are demarcated together with time ranges (min, max) for each stage. Figures 4, 5, 6, and 7 describe each of the stages of Figure 3 in greater detail, again presenting details of the time required for each substage, together with tools used, process inputs and outputs. Because the gures are very detailed, it is hoped that they are self-explanatory. The time lines have also been validated via communications with the industrial entities involved in large system design and implementations.

Performance Analysis tools Design Environments

1-3 months

1-3 months

Tradeoff Studies

Overall Architectural Definition

3.1 Areas for Improvement

Performance model Architecture HW/SW Requirments documents Traceability matrix Development plan Simulation, test/stimulus response Sizing

Some observations may be made at this point with respect to the design ow in Figure 3 that provide pointers to areas for improvement [7].  Automation and Enterprise Integration | Though progress in automation has been significant in the area of Hardware Design and to a lesser extent in Software Design, very little impact has been felt on system-level design, architectural exploration and tradeos, hardware/software integration, integrating manufacturing and product design activities, and reuse database libraries. Most of the information transferred between various stages of the design process is manual and usually documented on paper with little standardization. It may be argued, for instance, that algorithms designed in a high-level graphical environment can be translated to lower-level hardware and software implementation through code-generation mechanisms. However, these approaches are seldom ecient (unless optimized and

HW Requirements

Technology Assesment (packaging....) Alternative approaches COTS vs. Custom (Bus, processors, protocols, interfaces) Bottlenecks and degradation. Scalability, fault tolerance, ...

SW Requirements 1-3 months

B-2 Specifications Interface Control Documents (ICD)

B-5 Specifications Interface Control Documents (ICD)

System Requirements/Architecture De nition (1993) Fig 4.

3

Interface Control Document

B-5 Specs

Preliminary SW Design

3 months

Block Diagram Descriptions Communication Protocols Pointers to Reuse Libraries

Tools

CSCI

Editors

Preliminary SW Design/Model Preliminary Test Plan Preliminary Interface Design Document

Detailed Software Design

Tools Editors Debuggers Emulators Case Tools

CSC CSC Design, source code, and debug (CSU)

Source Code Listing SW Design Documents SW Test Descriptions CSC Integration and Test

B-2 Specs

Preliminary Parts List Preliminary Test Plan Preliminary Block Diagram

CSCI Integration and Test

Tools McDraw Schematic editors

Preliminary Hardware Design (Make/Buy)

2-3 months

SW Test Descriptions Source Code Listing

Interface Control Documents (ICD)

6-8 months

Updated Source Code Software Test Report Operation and Support Documents Version Description Documentation

Redesign

8-12 months Architecture Tradeoffs Preliminary Function Partitioning Make/Buy Decisions

CSCI Functional and Physical Conf. Audits

Detailed Hardware Design Backplane

Module/ Board

ASIC

SW Product Specifications

Rework

HW/SW Integration & Test

FPGA/PLD

MCM Mfg. Field Test

Microcode Firmware

3 months

Full Production

Field Test LRIP

0-3 months

Post-layout simulations Release Packages (drawings, BOM, drill pkgs, auto-insertion, mill, gerber files) Production Test Vectors Bonding Diagrams Netlists

Procurement

10-24 months

6-12 months

Fig 6.

Software Design Flow (1993)

Redesign

Manufacturing/ Assembly

2-4 months 10-24 months

Rework

Hardware Design

Field Test

8-12 months

Software Design Cost and product goals

SW/HW Integration & Test

Subsystem Integration

Physical Configuration Audit (PCA) Functional Configuration Audit (FCA)

Full Production

HW/SW Interface Design

Plan

Equipment delivery schedule

Schedules from HW/SW Design

1-3 months

B-2, B-5 Specs

Mfg. Field Test

LRIP (Limited Rate Initial Production)

Subsystem Integration Plan

Subsystem Test

0-3 months

1-3 months

Plan Test Plan Multiframe Test Plan Frame Test Plan Backplane Test Plan Module Test Plan

Functional Test Benches

Module level integration & test

Fig 5.

Backplane level integration & test

Hardware Design Flow (1993)

Subsystem level integration & test

8-18 months

Redesign/Rework

To Mfg. Field Test

Fig 7.

4

HW/SW Integration (1993)

usually hand-coded module libraries are accessible), and the challenge is to provide a uni ed representation mechanism for designs at multiple levels of abstraction (e.g., algorithmic, functional, and also at hardware/software levels). Little is available in terms of unifying the design environment either by \integration" or by \encapsulation", though these ideas are well understood within the design automation industry. The price is paid (in cost and time) by the system designer who has to (partly manually) translate descriptions from one CAD tool to another with little, if any, interoperability provided (this is timeconsuming and expensive considering that over thirty individual point tools are used at various stages in the design process ow of Figure 3). Standardization eorts have been initiated very recently in an eort to meet these needs through the use of VHDL [9].  Design with Reuse | Application-speci c systems can bene t from reuse of design information and functional block (e.g., FIR, DCT, etc) libraries from past designs. Algorithms can be rapidly designed using reuse libraries of commonlyused functional blocks, architectures can be quickly synthesized from reuse components from past designs. Thus reuse can signi cantly cut down prototyping times incurred in large projects, if there were a mechanism to formally capture reuse information and libraries in a form that could rapidly be assimilated in a current application-speci c design (this trend is facilitated by block-oriented design environments available from a number of commercial vendors). Figure 3 provides little opportunity for design with reuse.  Design for Reuse | In continuation of the previous point, any successful attempt at resolving the prototyping bottleneck must include a methodology to ensure that future designs can bene t from current design eorts. This can be facilitated if eorts were taken to populate libraries of reuseable components (from the current projects) in a form that the future design eorts can reuse. Contrasting with Design with Reuse which takes place \in-cycle", Design for Reuse can be initiated \ocycle" via population, maintenance, and upgrades of VHDL reuse libraries.

elers). It must be understood that the software is not just application-speci c software, but also control, diagnostic and test software. Often, control, diagnostic, and test software requires an order of magnitude larger man-hour eort that does application software [7]. Conventional hardware software co-design methods assign a token interest in the issue of software required for control, diagnostic and test purposes, and attempt to catch all integration issues under the term \interface". The approach shown in Figure 8(ii) represents a \true" HW/SW codesign wherein software models (in a HDL such as VHDL) of HW are provided to the SW developers and the entire software is designed and tested and integrated with the HW models long before any hardware is fabricated or manufactured. Thus, the design loops L1 and L2 are quick, and require no hardware fabrication & engineering cost, and in addition provide capability for complete system design using a process known as virtual prototyping [4]. The assumption, of course, is that libraries of HW models in software are available and that simulation times can be kept manageable. VHDL can be used with advantage in this true HW/SW codesign philosophy | one that embraces a hardware-less system design. Recent experience with hardware-less HW/SW codesign has shown that it is ecient, dramatically reducing time for HW/SW integration to a matter of weeks, and also allows rapid upgrades, together with savings in cost [9]. Once virtual prototyping is completed, it is expected that that pathway through which a eld prototype can be manufactured, supported and upgraded would be straighforward.  Executable Requirements and Speci cations | Figure 3 highlights the fact that current practice is to provide processor and system requirements in written form, often in hundreds of pages of documentation which must be interpreted and captured by a requirements analysis traceability tool. Requirements that are machine readable and executable are invaluable both in terms of eciency and accuracy of interpretation as well as a basis for regression testing of the design over many abstraction levels. An executable requirement of a complex application-speci c system would be an eort that pays for itself in later stages of the design process. The nal design itself can be documented in the form of an machine readable executable speci cation which would be machine readable and capable of being executed. Executable speci cations simplify later upgrades of legacy system and also in reducing life-cycle costs. MIT Lincoln Laboratory has initiated some work in this area as part of the RASSP eort [10].  Modular Software and Hardware Development | HDL-based software and hardware development supports HW/SW codesign, and in addition enables reuse of application-speci c components. Structured system design and development environments such as that shown in Figure 8(ii) utilize eective software engineering principles and

 Model-based

Co-Development and Co-Design Methodologies and Virtual Prototyping

| True HW/SW codesign allows both hardware and software to be designed within a common framework, and simulated together before being fabricated. Current practice attempts to automate this process via HW/SW/Interface partitioning followed by three individual paths to HW, SW and Interface design and implementation, respectively (as shown in Figure 3). A drawback with this approach is that (as shown again in Figure 8(i)) software can be designed and tested only if a hardware platform (at board and rack levels) is available. The latter is time- and cost-consuming (even if it utilized FPGA technology or HW mod5

4 Summary and Conclusions

HW/SW Partitioning & Allocation

HW Design

This paper has presented for the rst time a detailed picture of the current practice (1993) embedded signal processor design ow in the design, prototyping and deployment of high performance applicationspeci c parallel processing systems. Some limitations of the current practice approach have been outlined and investigations as part of the RASSP program outlined.

SW Design + Code

+ Build Interface Design L_1 rework

L_2 HW/SW Integration

rework

Acknowledgements

The authors acknowledge with gratitude inputs from various RASSP participants and programs. The views expressed in this paper are the authors' own, however, and do not necessarily represent the viewpoints of the US Department of Defense, ARPA, MIT Lincoln Laboratory, Martin Marietta, Lockheed Sanders, Raytheon, Hughes, Motorola, and SCRA. Thanks to M. Rubeiz of Wright Patterson Labs (USAF) for carefully reviewing the manuscript.

(i) Pre-RASSP - Hardware Fabrication/Manufacture in the design loops L_1 and L-2 Reuse HW/SW Libraries

HW/SW Partitioning & Allocation

HW Design + Model

L_1

SW-only Environment (VHDL)

SW Design

Interface Design & Model

L_2

Integration HW Models + SW

References

System Build

[1] M. Richards, \The Rapid Prototyping of Application-Speci c Signal Processors Program," Proc. of First Annual RASSP Conference, August 1994. [2] L. Scanlan, \RASSP: Road to 4X," The RASSP Digest, Issue 2, Vol 2, 2cnd Qtr 1995, (http://rassp.scra.org). [3] F. Shirley, \The RASSP Architecture Guide Rev. C," Document AVY-L-S-00081-101-C, Lockheed Sanders Inc., Nashua, NH, April 14, 1995. [4] V. Madisetti, T. Egolf, S. Famorzadeh, L-R. Dung, \Virtual Prototyping of Embedded DSP Systems," Proc. of IEEE ICASSP 95. [5] G. Caracciolo, J. Pridmore, \Architectures for Rapid Prototyping of Embedded Signal Processors," Proc. of IEEE ICASSP 95. [6] C. Myers, R. Dreiling, \VHDL Modeling for Signal Processor Development," Proc. of IEEE ICASSP 95. [7] G. Shaw, V. Madisetti, \Assessing and Improving Current Practice in the Design of ApplicationSpeci c Signal Processors," Proc. of IEEE ICASSP 95. [8] The RASSP Information Server - WWW URL http://rassp.scra.org. [9] T. Egolf, V. Madisetti, S. Famorzadeh, P. Kalutkiewicz, \Experiences with VHDL Models of COTS RISC Processors in Virtual Prototyping for Complex System Synthesis," Proceedings VHDL International Users' Forum (VIUF), Spring 1995. [10] A. Anderson, G. Shaw, C. Sung, \VHDL Excutable Requirement," Proc. of First RASSP Annual Conference, August 1994.

(ii) Post-RASSP - Hardware Fabrication/Manufacture eliminated from design loops L_1 and L_2.

HW/SW Codesign - (i) Current practice (1993-1994) and (ii) Post-RASSP. Note elimination of hardware fabrication, assembly and board/system level manufacture from the design loops. Savings result in time and cost, and the capability for customer input and concurrent life-cycle support and upgrade is enhanced. Shaded areas imply hardware.

Fig

8.

sign cantly reduce the loss in design quality and requirements traceability while passing from one stage to another in the current practice model of Figure 3, and are a requirement for any new design methodology for rapid prototyping. The notion of a standardized virtual interface (SVI) between all constituent hardware and software components to ensure rapid \plug-and-play" capability is appealing, and its implications in terms of standardization and eciency remain unexplored [5].

 Integrated Process and Product Development Teaming | Integrated manufacturing, product

and design teams provide the tight linkage required to eciently and concurrently create new products (and upgrade old ones) quickly (via virtual prototyping). Enterprise integration allows this tight coupling between hardware and software design, manufacturing procurement, reliability, maintainability, and supportability when utilized in conjunction with a top-down design methodology. 6