The RASSP Digest - Vol. 3, September 1996
COMET Project: Hardware/Software Cosynthesis for DSP Systems
by Ranga Vemuri
1. Project Objectives
The goal of the COMET project is to develop languages, techniques and tools for hardware, software cosynthesis of board- and MCM-level DSP (Digital Signal Processing) systems from very high level requirements specifications.
COMET target architectures can be either self-contained embedded processors in a primarily non-computing environment or special purpose co-processors that perform compute intense tasks delegated by a master computer system. In both cases, the DSP architecture may contain custom hardware components, custom software components executing on an off-the-shelf DSP/GP processor or both. Hardware components may in turn be application specific integrated circuits (ASIC), multichip modules (MCMs), field programmable gate arrays (FPGA) or a combination of these, mounted along with off-the-shelf parts on a printed circuit board (PCB).
2. The COMET Design Environment
Typical top-down design of the target architectures begins with requirements specification and analysis and continues to the design synthesis of both hardware and software components. COMET architecture is centered around (1) VSPEC, a declarative interface requirements specification language for VHDL entities, (2) hardware/software partitioning techniques for embedded DSP systems, and (3) codesign performance analysis methods and tools. COMET design environment is shown in Figure 1.
COMET design tools can be used in a variety of design processes or as stand-alone tools. The flow in Figure 1 suggests a top-down cosynthesis approach from high-level requirements specifications.
3. COMET Technology
3.1 Requirements Specification
VSPEC is the requirements specification language of COMET. VSPEC is a declarative annotation language for VHDL entities. Through VSPEC, designers specify requirements the system design should meet and constraints on its implementation. A VSPEC specification consists of a collection of logical statements and declarations that annotate a VHDL entity construct.
VSPEC adds seven clauses to a VHDL entity that allow a specifier to define “what” the entity must do without defining “how” it will be done. The requires, ensures and sensitive to clauses are used to specify the functional requirements of the device. Non-functional constraints are described in the constrained by and modifies clauses. The internal state of the component is declared in the state clause and the includes clause is used to make predefined types and operators visible in a VSPEC component [1].
VSPEC specifications can be used to evaluate component reusability. Specifications are used to compare the behavior of existing components to the requirements of a new system. Effective component reuse requires a tool for finding potential reuse candidates from within a component library. A component classification and retrieval tool, named REBOUND, is developed to provide efficient retrieval of VSPEC components [2].
3.2 Hardware/Software Partitioning
The goal of system partitioning is to generate a first level hardware-software architecture of the system by partitioning the system specification into specifications of hardware components and software components. The hardware components will be further processed by hardware synthesis tools. The software components will be bound to execute on a selected DSP or general purpose processor configuration. The hardware and software components will be connected to constitute a VSPEC - VHDL architectural description of the system. The functional requirements and constraints stated in the VSPEC specification drive the derivation of the specific hardware-software mix.
Initially, the VSPEC system specification is refined based on queries into the design library. As a result of the queries, components are selected based on their ability to satisfy the system function and constraint attributes. In case the existing components do not meet the requirements, a design that partially satisfies the requirements may be generated. Alternatively, the designer may be queried for additional components. Scoreboard algorithm for hardware software partitioning and binding is based on the iterative improvement and allows inclusion new constraints as they arise.
3.3 Codesign Performance Analysis
Accurate performance estimation is critical to the success of a design synthesis system. The COMET performance estimator is used to evaluate the performance, in terms of area, speed, throughput rate, and power dissipation, of the library components as well as the performance of a contemplated hardware-software architecture of a system. The estimator can be used interactively or through the partitioning engine to filter inferior architectures and to select a constraint-satisfying hardware-software binding for a given specification. Various hardware-software alternatives can be selected for each component in the architecture and for each selected configuration performance envelopes can be generated.
COMET performance estimator is based on the PDL (Performance Description Language) system for performance modeling and analysis. Tradeoff analysis is a central aspect in the codesign process. PDL system supports performance analysis and tradeoff visualization for rapid prototyping of codesigns [3, 4].
3.4 Hardware Partitioning and Synthesis
COMET hardware synthesis system consists of a multicomponent partitioning engine and a set of synthesis tools for ASIC , FPGA and MCM synthesis. The multicomponent partitioning engine [5, 6] is a hierarchical partitioning and package binding tool that accepts behavioral specifications in VHDL, constraints on area, power consumption, pin counts, speed and cost and generates a hierarchical partition of the specification with each component in the partition bound to a package among a set of available packages. The partitioning engine uses a back-tracking algorithm for constraint- directed search. Power estimation is based on data gathered by dynamic profiling of the VHDL specification using typical stimuli.
The ASIC synthesis system DSS (Distributed Synthesis System) [7] accepts behavioral specifications in VHDL and constraints on clock period and area. It generates register level designs in VHDL. Register level designs contain two parts: a data path and a finite state controller. The data path is in the form of structural VHDL in which each component is instantiated from a predefined parameterized register level component library.
MCM synthesis environment MSS [8] is embedded in COMET to facilitate synthesis of multichip modules. Multichip designs can be generated in two ways: (1) Register level designs generated by DSS can be partitioned into multiple chip designs, or (2) an integrated behavior synthesis and partitioning step can be performed to obtain multichip designs directly. These multichip designs are then processed by package level place and route tools. We currently use Mentor Graphics MCM Station.
3.5 Software Compilation
The software synthesis tools in COMET translate DSP-based software behavioral specifications expressed in a subset of VHDL into efficient machine code. The overall approach to software synthesis is to translate behavioral descriptions expressed in VHDL into C and then use commercial C compilers to translate C into machine code to execute on the target processor. The currently supported processors are the Texas Instruments TMS430C51, Sun Microsystems SPARC, and Intel 80386. The compiled code can be statically analyzed for timing performance to ensure compliance with timing constraints expressed in the VSPEC specification.
The VHDL subset used as input for software synthesis is similar to that used for asic synthesis [7]. VHDL behavioral constructs are fully supported along with a limited subset of structural constructs. Explicit timing , such as VHDL after clauses or specific time in wait statements, is not supported.
The execution environment consists primarily of a small multitasking operating system kernel which will provide interprocess communication service, task management, and input/output support. The task scheduler will create, maintain and monitor all tasks in the run-time space, while the interprocess communication protocol will support a simple message passing mechanism where a process writes its request and data in a message channel whenever it tries to communicate with others, and then optionally waits until a response is received.
4. Availability of COMET Technology and Tools
COMET tools are freely available to the RASSP community. Some of the COMET tools (DSS behavioral synthesis tool, MSS multicomponent synthesis tool, PDL performance modeling and analysis environment, VHDL to C compiler, VSPEC parser) are relatively mature. Other tools (Rebound, Scoreboard) are under development with release versions expected shortly. Triquest Design Automation Inc., is in the process of receiving a subcontract to quality enhance and distribute some of the COMET tools.
A WAVES Level 2 usage guide is available to aid in the preparation of test benches in the IEEE standard WAVES language [9]. COMET tools have been successfully used to synthesize various designs including reconfigurable coprocessors [10]. Further information on the COMET project is available through worldwide web page http://www.ece.uc.edu/~ ddel/comet.html.
References
[1] P. Baraona, J. Penix, and P. Alexander, “VSPEC: A Declarative Requirements Specification Language for VHDL,” Current Issues in Electronic Modeling, vol. 3, pp. 51-75, 1995.
[2] J. Penix, P. Baraona, and Perry Alexander, “Classification and Retrieval of Reusable Components Using Semantic Features,” Proc. 10th Knowledge-Based Software Engineering Conference,” pp. 131-138, 1995.
[3] R. Vemuri, R. Mandayam, and V. Meduri, “Performance Modeling Using PDL,” IEEE Computer, April 1996.
[4] J. Walrath, et al., “Performance Modeling and Tradeoff Analysis During Rapid Prototyping,” Proc. Application Specific Array Processors, 1996.
[5] N. Kumar, V. Srinivasan, and R. Vemuri, “Hierarchical Behavioral Partitioning for Multicomponent Synthesis,” Proc. European Design Automation Conference, 1996.
[6] M. Vootukuri, R. Vemuri and N. Kumar, “Partitioning of Register Level Designs for Multi-FPGA Synthesis,” Proc. VIUF Conference, Spring 1996.
[7] J. Roy, R. Dutta, N. Kumar, and R. Vemuri, “DSS: A Distributed Synthesis System for VHDL Specifications,” IEEE Design and Test of Computers, pp. 18-32, June 1992.
[8] R. Vemuri et al., “An Integrated Multicomponent Synthesis System for MCMs,” IEEE Computer, pp. 62-74, April 1993.
Ranga Vemuri
University of Cincinnati
ECECS Department, M.L. 30
Cincinnati, Ohio 45221-0030
ranga.vemuri@uc.edu
Newsletter Index
The RASSP Digest - Vol. 3, September 1996
newsletter/html/96sep/news_8.html