The RASSP Digest

Vive La Difference

The erudite readers of The RASSP Digest may be curious as to the differences between the ``current design process (circa 1993)" as opposed to a newer RASSP-like design process. Indeed, this editor has put much thought to this issue given the relevance, importance, and timeliness, of such a comparison. Some preliminary ideas that emerged from months of exposure to various facets of RASSP and also to current design practice are presented in the next few sections for your consideration, where this editor compares and contrasts two different (radically?) design processes. In the interest of space, high-level differences in design flow will be the focus of this discussion, as opposed to more involved architecture- and methodology-dependent facets that are well documented elsewhere. Thus, this editorial concerns itself with one (iterative) pass from concept to product. Higher-level loops that iterate over model-years will be the subject of future articles. We may recall that RASSP is targeted towards the design and prototyping (from concept to product) of large embedded DSP systems (we do not target ASICs as their technology is somewhat mature and sufficient resources are already addressing their rapid design and realization). Examples of systems of interest range from efficiently packaged single-board embedded DSP systems (as found in high-performance workstations using MCM-based chassis) to large multi-chassis STAP radar signal processor systems which typically have performance requirements ranging between 20-1000 BFLOPs of computational intensity at pixel rates of 10 Mhz, within the form constraints of size, weight, and power of 2-50 ft3, 100-1400 lbs, and 1-10 KW, respectively. Boards represent subsystems, while multiboard configurations can represent complete systems, and involve hardware fabrication, assembly, and integration with application, control and diagnostic software. Figure 1 (listed below) represents a high level depiction of current design practice, and Figure 2 on page 19 represents a preliminary RASSP design flow. Both process flow diagrams start at the level of the representation of the application requirements. The algorithm to be implemented (e.g., a STAP radar signal processor system) is specified in an executable form (a VHDL/Ada, or a C/Matlab program) together with stimuli and test benches. In addition, the system has certain performance characteristics and constraints that must be met by the prototype (representative values being given in the preceding paragraph). After an appraisal of the application characteristics is completed, a partitioning of the application onto hardware (HW) or software (SW) is carried out manually by an experienced hardware system designer, and is to some degree ad hoc. Those portions of the systems that are to be cast as ASICs are selected, and common-off-the shelf (COTS) components such as processors and memories are chosen as targets for mapping SW components, and inital estimates as to the allocation of these parts are drawn and reviewed. The application is partitioned into subsystems (boards) so that each of these boards executes a portion (in SW or HW) of the algorithm, and their ensemble (the multiboard system) will hopefully prototype the required radar system with satisfactory performance. Since software (SW) cannot execute without target hardware, application and control software developed for each of these boards can only be tested and debugged after the hardware fabrication (assembly) and test of the board is completed (which can take 2-4 months per board, that too if complex ASIC design is not involved). After the hardware board is fabricated, application and control code is debugged in an iterative design cycle a of Figure 1. After successful design and test of the board-level HW/SW subsystem, the multi-board system is integrated manually, wherein the software and the hardware are merged and tested via diagnostic software and input from the application (stimuli and test). This integration is done manually and involves silicon fabrication, manufacture and assembly/test, and is iteratively refined until an acceptable test prototype is synthesized. The three software design loops a, b, and c all include hardware fabrication, and the final field prototype is realized after satisfactory integration and test, often involving a total concept to prototyping delay of 3-4 years, at the cost of 20-30 man-years. In one representative radar signal processor system studied by this author, the final HW count was about 150 boards incorporating a total of about 25,000 LSI/COTS components including an ASIC front-end filter and a 64-processor TMS320C30-based processing engine. The final SW count in lines of source code (LOSC) was 5K LOSC for the DSP/radar signal processor application, 30K LOSC for control, 60K LOSC for diagnostics, and 25K LOSC for functional and performance verification, representing a 20:1 ratio of system-level design code size to DSP application code size. Designers focussing on hardware/software codesign are requested to include in their codesign software related to diagnostics and functional verification in addition to application (algorithmic) code generation. In the preliminary RASSP design flow of Figure 2, the primary difference (from Figure 1) is that the hardware fabrication and assembly at the subsystem and system-level is eliminated from the in-cycle design loop. The software is run on virtual hardware (in the form of VHDL models or hardware modelers and emulators) long before any HW fabrication and assembly is begun. This ``virtual prototyping" environment significantly speeds up the design cycle through the use of models at multiple levels of design abstraction in the constituent VHDL libraries. The board-level and the multi-board integration is simulated and tested, additional control and diagnostic software is developed and debugged entirely in a user-friendly software environment. If the model libraries were accurate, the next stage could itself be that of the field prototype. However, at least one RASSP prime has planned to include the actual hardware test prototyping stage within the preliminary RASSP design process to validate and improve upon the process of virtual prototyping. The preliminary RASSP process, however, retains the manual HW/SW partitioning block as observed by the reader. The advanced RASSP-like design flow (Figure 3), scheduled for late 1996-1997, is envisioned by this editor as incorporating an additional stage defined as ``conceptual prototyping" which involves early design, and replaces the manual HW/SW partitioning block of the ``current practice'' of Figure 1. Conceptual prototyping utilizes automated tools that allow rapid estimation and evaluation of algorithmic, functional, architectural and enterprise-related trade-offs early in the design process. A few candidate conceptual prototypes are then culled from the dozen or so generated at this stage, and then passed on to the virtual prototyping stage. Here, extensive evaluation and detailed design






is done in virtual hardware and software leading to successful and rapid integration, again through the use of HW/SW reuse libraries, interoperable tools, and enterprise integration. The entire process depends heavily on automation, and feedback currently being obtained from benchmark designs on candidate RASSP-like processes by the primes and other RASSP participants will be used to refine and improve upon both the rapidity, as well as the correctness of the first-time prototyping efforts of large DSP systems. The envisioned process presents a number of open problems related to both conceptual and virtual prototyping and verification that must be effectively addressed by various RASSP participants and the larger electronic systems design and application community, promising an exciting time for digital system designers trying to cut the prototyping times by a factor of four!. In summary, a RASSP-like process differs from current practice design process in the following ways: 1. No hardware fabrication, assembly, and test is present in in-cycle design loops. 2. Late binding of hardware allows the design product to be state-of-shelf at time of manufacture or use, 3. Extensive use of conceptual and virtual prototyping optimizes efficiency of the final product, and guarantees right-first time designs, 4. Design reuse supported by generation, maintenance, and upgrades of application-specific VHDL libraries for rapid design of signal processors, 5. Enterprise integration and interoperability between various point design tools facilitates design portability and standardization, 6. Extensive use of automation to facilitate --- a nested-loop and iterative design process, automated metrics collection and distributed collaboration facilities for large design project management speeds up the prototyping, a documentation and life-cycle maintenance process. comments.

Disclaimer: The views in this article are solely those of the author, and do not necessarily reflect the views of Advanced Research Projects Agency (ARPA), U.S. Department of Defense, Lockheed Sanders Inc., Martin Marietta Corporation, SCRA, or Georgia Tech.