Draft version
Colif: a Multilevel Design Representation for Application-Specific Multiprocessor System-on-Chip Design W.O. Cesário, G. Nicolescu, L. Gauthier, D. Lyonnard, and A.A. Jerraya TIMA Laboratory 46 av. Félix Viallet - 38000 - Grenoble - France
[email protected]
Abstract Application-specific multiprocessor system-on-chip is required for high-volume future embedded systems. However, obtaining a good application-specific architecture could be an overly complex problem if we consider all the possible customizations. In this paper, we present Colif, a design representation that clearly separates component behavior and communication infrastructure. In addition, it has a flexible communication model that spans multiple abstraction levels. These features are suitable for a design flow where customizing communications and component behaviors at different abstraction levels are the central issue. The paper introduces the main concepts of Colif and compares it to existing system modeling approaches.
1. Introduction The adoption of "system-on-chip" (SoC) architectures in future embedded-system designs will bring many advantages in terms of performance, cost, reliability, power consumption, system size, etc. However, in order to take full profit from those advantages designers must be able to fine-tune the SoC architecture according to application-specific characteristics and requirements. Application-specific multiprocessor SoC architectures (ASMSA) constitute an ideal hardware platform since, in theory, they can be configured to fit exactly the needs of the application. There are many customizations available in such architectures. The most important aspect is the choice of the topology (point-to-point/system wide bus) and protocols (FIFO/handshake/etc) to use in the communication between processors/memory/peripherals. Optimally ASMSA customization for complex applications is an overly difficulty, even impossible goal, since all those customizations are interdependent. Most researchers agree on the fact that independently refining communication and system behavior [1] is a good way of orthogonalizing the problem to reduce system design complexity, and to achieve solutions that are, in practice, sufficiently close to the optimal solution. Adoption of this rationale leads naturally to a design flow where communication infrastructure and processor/memory customizations follow independent paths while mapping the system specification into an ASMSA [2]. All issues raised in the above paragraphs must be taken into account when proposing a design representation that will be used for the automation of the design flow for ASMSA. The choices discussed imply many tradeoffs between design
1
Draft version
complexity, system performance, degree of automation, verification, design reuse, etc. In our opinion, a design model targeted at efficient synthesis of ASMSA must privilege three main features: • It must be able to model a communication network possibly composed of multiple topologies and protocols for maximum flexibility when customizing an application-specific communication infrastructure; • It must enable refinement of the intrachip communication network more or less independently from the optimizations of the internal behavioral of system components; • It must encompass many abstraction levels, mixing them if required, but for flexibility's sake, communication models must not be imposed on the highest abstraction level. The above requirements are difficult to fulfill when constraints are imposed by using a design model that has a restrained communication model. The design and analysis of a given communication scheme is a complex task, and its properties will severely impact the performance of the whole system. In order to handle this, we have to concentrate on precise modeling of communication mechanisms, primitives and abstractions. The goal of this work is to provide a design representation that is able to model on-chip communication at different abstraction levels while separating component behavior from the communication infrastructure. The next section analyzes the main differences between our modeling approach and the state of the art in system-level modeling. Section 3 introduces our multi-abstraction level design representation aimed at automating a synthesis flow for ASMSA platforms. In order to expose the main features of a Colif model at different abstract levels, we present an example refinement flow for communication and discuss some of the synthesis tasks involved in this process in section 4. Section 5 gives some implementation details. Finally, section 6 presents our conclusion and future work.
2. Related Work The literature provides a plethora of modeling strategies for system design [3][4][7][8]. In this study, we will focus only on modern representations introduced specially for SoC design. These will be analyzed according to their ability to model communication at different abstraction levels. All these modeling strategies have been introduced to resolve a very specific purpose. A first trend in system-level modeling was to create new languages or to extend existing ones. The goal of N2C [4], SpecC [7] and SystemC [3] is to leverage C/C++ knowledge for system specification using language/library extensions that provide the necessary modeling concepts, namely: time, netlist and concurrency. Simple language compilation provides a fast executable model for verification but communication models are strictly bound to the simulation policy. Simulation-based languages are good frameworks for system validation, but too much details are required to build an executable model. Hence, the main disadvantage is that design specification must start at a relatively low level. The newest SystemC version (1.1 beta) [3] enables higher levels of modeling abstraction by offering higher-level communication models (called "abstract protocols") and higher-level functional abstractions. A remote procedure call (RPC) task model was added to support the simulation of the highest abstraction level. RPC is restricted for describing complex distributed systems because of the implied master/slave point-to-point model. Rosetta [8] is a new language proposed by the System Level Design Language (SLDL) committee, it essentially build a formal constraint model while combining heterogeneous semantic domains – called facets. With Rosetta, designers get the
2
Draft version
freedom of defining new task models by writing new facets or combining existing ones. Efforts to produce an executable model from Rosetta have taken the direction of formal verification environments so it is foreseeable that the flexibility of the communication models will be constrained by facet composition and interoperability rules. There is still no simulator for Rosetta since the language specification is not yet completed. More recently, there seems to be a trend towards language-independent semantic models and "meta-models". Open Verilog International' Semantic Reference Manual (OVI-SRM) marks a significant turn from the search of a specific system-specification language. The main objective is the scheduling of run-to-completion tasks into embedded processors. The only communication model accepted is the point-to-point shared-memory interconnection, and it is restricted to a single abstraction level. The virtual Socket Interface Alliance's (VSIA) system level development design working group proposes an "abstract model" where functionality and accuracy is assured by standards: System-Level Interface (SLIF) for communication models, Performance Modeling Standards for design constraints, Data-type Standard for model integration. While very flexible, this model imposes a complex synthesis process where refined properties need to be back verified against the related properties in the more abstract models [5]. Another view was brought by the semantics group of the Gigascale Silicon Research Center (GSRC) [9]. For them, system modeling has four aspects: "abstract syntax", "syntactic transformations", "concrete syntax" and "semantics". Besides being "concrete syntax" (language) independent, the "abstract syntax" is also "semantic" independent [6]. We could think of it as a "meta-model" since it must be able to describe at least: netlists, state transition diagrams, block diagrams, object models and graph structures. Now that SLDL and OVI are both part of the Accellera initiative, they may collaborate with VSIA and GSRC to promote the development of a unified SRM. MoML [13] is an XML derivative that honors GSRC abstract syntax. In this study, the Ptolemy-II [14] semantics is used. For system-level modeling MoML could be used to represent different "models of computation" (MoC) that could be deployed in a composite simulation of the system. There are many other models based on MoC composition: the Abstract Codesign Finite-state Machine (ACFSM) [1] models abstract communication using infinite-size queues; El Greco uses a Cyclo-static Dataflow (CSDF) [15] and low-level fixed-size FIFOs for communication; System Properties Intervals (SPI) [16] is an abstract process network model with system properties annotated as intervals, its main focus is on performance estimation, and it also uses FIFO buffers for communications. To our knowledge, none of the above-described formats is able to separate behavior from communication at different abstraction levels ranging from the system to the register transfer level (RTL). The main contribution of this paper is to present Colif, an object-oriented intermediate model for synthesis of multiprocessor embedded systems. Multiple communication models are supported and their behavior could be described at multiple abstraction levels. Objects are polymorphic, their semantics will change according to the represented abstraction level. Behavior and communication are separated, which allows independent refinement of these features.
3. Multi-Abstraction Level Representation for ASMSA Design This section explains the concepts used in Colif for modeling ASMSA designs. The next subsection shows how to realize a modular specification of a system using the three basic Colif concepts: the module, the port and the net. Section 3.2 presents Colif's object model in detail. In Colif, the communication network – with nets and ports – will have specific
3
Draft version
semantics at different abstraction levels. Section 3.3 presents a detailed explanation of these semantics at the four abstraction levels that we consider for communication refinement: service, message, driver and register transfer levels.
3.1. Modular System Specification As a very general view and regardless the abstraction level, Colif represents the system as an ensemble of interconnected hierarchical modules, and the communication network is composed of nets and ports – as depicted in Figure 1. In this figure, we present the graphical notation that will be used in the next section. Each module is defined by its interface – composed of a set of ports – and its content. The module content may be a netlist of other module instances, or a composition of tasks (more details will be given in next subsection). Modules are represented as white boxes if they contain instances inside, as a blackbox if its contents are not known or irrelevant, and as labeled balls when the module is a leaf in the hierarchy. In this last case, we consider that it contains only one task with known behavior, for simplicity, we will call it a task. Ports are represented as little boxes with diamonds inside, and nets as directed arrows. All these graphical elements can have labels to identify them uniquely.
E
E
E
E E
E
PRGXOH EODFNER[ WDVN QHW SRUW
E
E
Figure 1 - Colif graphical notation
3.2. Colif Object Model A fundamental decision in Colif's design was to clearly separate behavior from structure and encompass multiple abstraction levels. This separation is reflected on the class implementation of each Colif concept. Figure 2 is a simplified representation of the UML class diagram for Colif. As a general principle each basic concept in Colif - the MODULE, the PORT, and the NET - is split into two parts: an interface (that we call ENTITY) and the contents (CONTENT). The ENTITY part has a TYPE that is a predefined Colif class, so it is not user-definable. The CONTENT part holds a reference to an internally or externally described behavior and/or a list of INSTANCE objects. In the latter case, this implicitly states that the container object is hierarchical and the contained objects are situated in a lower level in the hierarchy. An INSTANCE represents a possibility of multiple re-use of an object's definition by changing its name as an alias. In Colif, an INSTANCE holds only a reference to the re-used
4
Draft version
object and an independent, user-definable name. Colif classes are polymorphic, in the sense that their semantics will change according to the considered abstraction level.
1 MODULE_ENTITY description:str ype:MODULE_TYPE 0..1 t ports:listPORT_INSTANCE
MODULE d e s c r i p t i o n : str 0..1 entity:refMODUL E_ENTITY content:refMODULE_CONTENT 0..1 1 1 02'8/(B,167$1&(
1
PORT_INSTANCE SRUW UHI 3257
3257B(17,7< GHVFULSWLRQ VWU W\SH 3257B7
