Next: 8 Specifications Up: Appnotes Index Previous:6 Model Year Software Architecture

RASSP Model Year Architecture (MYA) Appnote

7.0 Implementation of a Model Year in a Reuse System

7.1 Library Reuse Elements

LM/ATL's RASSP team has developed a formal definition of reuse library development by extending the concept of object-oriented design (which has been successfully applied to software development) to signal processor architecture design, encompassing both hardware and software. Architectural library elements, such as a processor element, can be described as:

an abstract entity defined by an object class which possesses a standard interface definition, with
a defined functional capability or set of methods implemented via a combination of hardware and software.

Architectural reuse elements are written at a level of abstraction to hide hardware and software implementation details from users and limit the impact of design changes.

Implementing the object's functionality requires a co-dependency of its hardware and software aspects, necessitating hardware-software codesign. For example, operating systems must be configured to take advantage of whatever hardware resources are available to support its functionality. Likewise, application libraries may need to be configured or optimized to take advantage of specific hardware implementations.

7.2 Model Hierarchy

Users iteratively verify a model-year architecture signal processor throughout the codesign process; they require the reuse libraries to support models at various levels of hierarchy. The ATL team has worked with models at four levels of the VHDL modeling hierarchy

Performance Models (synonym: Uninterpreted Model) provide timing-only and control functionality for processor nodes buses/interconnects, etc. to support high-level architectural trade-offs (number and types of processors, type and topology of network)
Abstract Behavioral Models provide behavior at the data output level with (potentially) some level of timing. This level includes both algorithm-level and Instruction Set Architecture (ISA)-level models.
Interface Models (synonym: Bus-functional) describe the operation of a component with respect to its surrounding environment.
Detailed Behavioral Models, previously known as Full-functional models, describe functionality at the signal level and timing fidelity at the clock level. This includes Register Transfer Level (RTL) and logic models.

These models are more fully defined in the RASSP Terminology and Taxonomy document and the Token-Based Performance Modeling application note. Through these models, the functional architecture constructs are supported. The use of these models has been tested in a series of benchmark programs to define reuse library elements for RASSP. More details can be found in the case studies that document these efforts. See the SAR, ETC4ALFS on COTS Processor, and SAIP case studies.

7.3 Additional Requirements

Aside from the VHDL or software code and test benches that define the functionality and performance of each element, non-functional requirements, such as size, weight, power, cost, or reliability numbers are incorporated into the structure of the reuse objects. This provides users with important data about the reuse elements that they require to judiciously select appropriate pieces for reuse. The long-term goal is to provide, in a standardized format, data that can be used by high-level (architecture trade-off and synthesis) tools to support design trade-offs and optimization. By incorporating this full set of functionality and features as part of the object-oriented reuse hierarchy, RASSP promises to realize reuse to a greater extent and with greater efficiency than ever before.

Next: 8 Specifications Up: Appnotes Index Previous:6 Model Year Software Architecture

Approved for Public Release; Distribution Unlimited Dennis Basara