Today’s boards will become tomorrow’s “Systems-on-a-Chip,” consisting of specific architectures with embedded software components that can cooperate with dedicated co-processors. Due to the costly integration, processing, and testing phases in the design cycle of such system chips, the modeling of the complete system or of specific aspects and components at various levels of abstraction is key. Moreover, high-level models will allow us to specify and verify the system requirements, to analyze, explore, compare, and select different components of the system, and to explore several architectural choices. An essential element for efficient design practice in the
future will be the capability to extensively reuse existing blocks or functions, called Virtual Components (VCs). The VSI System-Level Design Development Working Group (SLD DWG) addresses those interfaces that can benefit the reuse of VCs in system-level design through standardization.

In a first standardization effort, the SLD DWG defined a common nomenclature for VC components that relate to the System-Level Design activity. The goal of system, or high-level, models is to allow the VC user to evaluate and select the various VCs that are to be used for the System-on-a-Chip (SoC). Evaluation within the system environment, trade-off analysis, and subsequent decisions on items such as bandwidth, function, code size, and performance can be determined within this environment in the context of the overall SoC specification.

However, meeting these system design challenges requires the unambiguous transfer of design information and communication about modeling modes between developers and VC providers. To address the need for conventions in modeling and terminology, the participating companies of the SLD DWG established the underlying document, based on the earlier RASSP Taxonomy and Terminology efforts. It contains an extended definition of a precision scale for taxonomy, together with an elaborated classification of the different models used in design, implementation, and verification at all levels, which are classified in “system, architecture, hardware, and software specific models.”

The underlying idea is to agree in the design community, which includes system designers, software developers, feasibility groups, and hardware design teams, on a common acceptable nomenclature and classification of models in use.

Where conflicting meanings exist in the different communities involved, this document endeavours to either chose the most common or to synthesize an enveloping definition. Where this process is incomplete or impractical, all the relevant definitions and their context will be given, along with a recommended context-free default meaning.

The intent of Member Review and Release to the Public of this document is to get comments on any points of concern or suggestions. We highly welcome participation in the refinement and subsequent development and adoption of this document.