The RASSP Digest - Vol. 2, 2nd. Qtr. 1995

Rapid Prototyping of Application Specific Signal Processors:
Current Pratices, Challenges, and Roadmap

by Vijay Madisetti and Jack Corley

Links to all figures for this article
The authors present a "current practice (circa 1993)'' model for the design and prototyping of application specific (e.g., signal processing) parallel processors. A number of limitations in current design practice are highlighted together with challenges faced and a roadmap for candidate solutions. The Rapid Prototyping of Application Specific 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).

1. Introduction

This section introduces classes of high-performance application specific parallel processors. Section 2 presents current practice (circa 1993)'' based on extensive study of industrial practice through first-hand communications with various industrial and defense contractors at Lockheed Sanders, Martin Marietta, Hughes Avionics Systems, Motorola, MIT Lincoln Laboratories, and Raytheon corporations, by the authors as part of the RASSP Education and Facilitation effort over the past year. Section 3 describes the challenges facing application specific parallel processor specification, implementation, verification and support, and section 4 outlines the areas of focus of the RASSP [1] efforts that attempt to improve upon the current practice in a manner expected to have a lasting impact on the way signal processors are procured, designed, and manufactured [2].

1.1 Representative Architecture

A typical high-performance avionics parallel signal processor operation flow is shown in Figure 1, while memory requirements increase towards the right, with the most memory required by the MSP stage (typically 200-400 Mbytes). Typical high-end form factor constraints for volume, power, weight, and I/O rates are in the order of 2-3 ft3, 40-500W, 10-60 lbs, and 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.2 Architectural Design Space

A combinatorially significant number of alternatives exist in the implementation of the SSP, ASPP, and MSP functionality. A few key architectural attributes [3] are listed below:

1.3 Typical System Specifications

A number of specifications/requirements form the input to the prototyping process, and they can be weighted in relative order of importance. These include (in no specific 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 specifications [3].

2. Current Prototyping Practice

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

2.1 System Development Phases

The life cycle of a typical large system roughly follows the six phases shown in Figure 2. The focus of 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 figures for each of these phases in terms of resources (capital and personnel) can run into a 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 cost incurred/committed rises steeply with the onset of phase 3.

Clearly, decisions and tradeoffs made in the early phases have significant financial 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 fielded. While customer input is significant in phases 1-3, it diminishes in phases 4-6 leading to significant risks to the manufacturer in fixed-price contracts, or to the customer via cost overruns when redesign or rework is required. Life cycle support (phase 6) can last between 10-30 years. The capability for rapid upgrade is an effective insurance against technological obsolescence of the fielded system [6].

2.2 Current Practice (Circa 1993)

Figure 3 presents the current practice model for system design. The various stages in a waterfall''-type process flow 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 figures 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.

3. Areas for Improvement

Some observations with respect to the design flow in Figure 3 that provide pointers to areas for improvement [6] are described next.

3.1 Automation and Enterprise Integration

Though progress in automation has been significant in the area of Hardware Design, system-level design, architectural exploration and tradeoffs, far less progress has been made in software design, hardware/software integration, or in integrating manufacturing and product design activities and database libraries. Most of the information transferred between various stages of the design process is manual and is usually documented on paper with little standardization. The price (in cost and time) for this lack of integration is paid by the system designer who has to manually translate descriptions from one CAD tool to another with little, if any, interoperability provided (this is time-consuming and expensive considering that over thirty individual point tools are used at various stages in the design process flow of Figure 3). Standardization efforts have been initiated very recently in an effort to meet these needs through the use of VHDL [7].

3.2 Design with Reuse

Application specific systems can benefit from reuse of design information from past designs. Algorithms can be rapidly designed using reuse libraries of commonly used functional blocks. Architectures can be quickly synthesized using reuse components from past designs. Thus reuse is a feature that can be leveraged with advantage in cutting down the prototyping times incurred in large projects, if there were a mechanism to formally capture reuse information in a form that could rapidly be assimilated in an application specific design. Figure 3 provides little opportunity for design with reuse.

3.3 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 benefit from current design efforts. This can be facilitated if efforts were taken to populate libraries of reuseable components (from the current projects) in a form that the future design efforts can reuse. Contrasting with Design with Reuse which takes place in-cycle,'' Design for Reuse can be initiated “off-cycle'' via population, maintenance, and upgrades of VHDL reuse libraries.

3.4 VHDL-based Co-Development and Codesign 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. A drawback with this approach is that (as shown in Figure 8(i)) software can be designed and tested only if the hardware platform (at board and rack levels) is available. The latter is time- and cost-consuming. Software is not just application specific software, but also control, diagnostic and test software. Often, control, diagnostic, and test software requires an order of magnitude larger man-hour effort to develop than does application software [6]. Conventional hardware software codesign 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 VHDL) of HW are provided to the SW developers and the entire software is designed, tested and integrated with the HW models long before any hardware is fabricated or manufactured. Thus, the design loops L_1 and L_2 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. VHDL can be used with advantage in this true HW/SW codesign philosophy -- one that embraces a hardware-less system design. Our experience has shown that hardware-less HW/SW codesign is very efficient, reduces time for HW/SW integration to a matter of weeks and also allows rapid upgrades, together with significant savings in cost. Once virtual prototyping is completed, the field prototype can be quickly and efficiently manufactured.

3.5 Executable Requirements and Specifications

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 traceability tool. Requirements that are machine readable and executable are invaluable both in terms of efficiency and accuracy of interpretation as well as in regression testing of the design over many abstraction levels. An executable requirement of a complex application specific system would be an effort that pays for itself in later stages of the design process. The final design itself can be documented in the form of an executable specification which would be machine readable and capable of being executed. Executable specifications simplify later upgrades of legacy system and also in reducing life-cycle costs. MIT-Lincoln Laboratories has initiated some work in this area as part of the RASSP effort.

3.6 Modular Software and Hardware Development

VHDL-based software and hardware development supports HW/SW codesign and, in addition, enables reuse of application specific components. Structured system design and development environments such as that shown in Figure 8(ii) utilize effective software engineering principles, significantly 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 would be attractive for rapid prototyping, and its implications in terms of standardization and efficiency remain to be explored [5].

3.7 Integrated Process and Product Development Teaming

Integrated manufacturing, product and design teams provide the tight linkage required to efficiently and concurrently create new products quickly. 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. The current practice model of Figure 3 illustrates recent efforts in this direction, though room exists for further integration.

4. Summary

For the first time a detailed picture of the current practice (1993) design flow in the design, prototyping and deployment of high performance application specific parallel processing systems is presented. Some limitations of the current practice approach are outlined, and improvements sought by the US Department of Defense's RASSP program are presented.
Links to all figures for this article

Acknowledgments

The authors acknowledge with gratitude inputs from various RASSP participants and programs. However, the views expressed in this paper are the authors' own and do not necessarily represent the viewpoints of the US Department of Defense, ARPA, MIT-Lincoln Laboratories, Lockheed Martin-ATL, Lockheed Martin- Sanders, Raytheon, Hughes, Motorola, or SCRA.

References

[1] M. Richards, “The Rapid Prototyping of Application Specific 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, 2nd 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] G. Shaw, V. Madisetti, “Assessing and Improving Current Practice in the Design of Application Specific Signal Processors,'' Proc. of IEEE ICASSP 95.

[7] Proceedings VHDL International Users' Forum (VIUF), Spring 1995.
The RASSP Digest - Vol. 2, 2nd. Qtr. 1995

95q2/news_6.html