Heterogeneous System-Level Specification in ... - Semantic Scholar

Heterogeneous System-Level Specification in SystemC Fernando Herrera, Pablo Sánchez & Eugenio Villar University of Cantabria E.T.S.I. Industriales y de Telecomunicación Avda. Los Castros s/n, 39005 Santander, Spain (fherrera, sanchez, villar)@teisa.unican.es Abstract A specification methodology for embedded system design should provide a capacity for heterogeneous specification. This would give the designer an effective tool to capture a heterogeneous specification, required for the multidisciplinary character of embedded systems, due to their wide range of applications together with an increasing integration capability. This specification methodology should be suitable for design tasks in order to improve design productivity. In this context, this paper deals with the general solution of the system-level heterogeneous specification in the framework of a specification methodology based on SystemC. This specification methodology is suitable for system-level modeling, but also for design procedures such as system-level profiling and single-source generation. Specifically, we study and propose a solution for a system-level SystemC specification which combines several untimed models of computations, (MoCs), namely CSP, PN and KPN. In order to situate clearly the heterogeneous specification methodology we will use a general study framework called Rugby metamodel.

1

Introduction

Embedded systems are becoming more common in our daily lives. This fact is reflected in the solid growth of the embedded market, (for instance, 49% for Embedded Micros, and 94% for Embedded Software Development Tools, RTOS and Services) [GDQ01]. This trend is accompanied by a tendency towards an ever-increasing complexity in embedded components and systems. Components are more and more complex and powerful (for example, in 2001 already 67.5% of the processor architectures for embedded development were of 32 bits [GDQ01]). In addition, one single chip is able to cope with the integration of more components, reaching the complete system (System-on-Chip, SoC) [CCHM99]. The increase of integration drives the evolution from the SoC to the NoC (Network-on-Chip) [JaHa03], where networks are the top connection between the main components (systems) inside the same chip. All these facts underline the importance of devising new design paradigms. Another fact that is widely accepted is the variety of applications of embedded systems (telecom, home, automotive, medical, industrial, etc...), which are normally composed of parts that require design techniques from different fields. This fact, together with the increasing ability of integration leads to a global heterogeneity of embedded systems that will probably continue in the future. Global heterogeneity means that heterogeneity is not restricted to the architecture of the system (composed of elements such as general purpose processors, DSPs, application specific HW modules,...), but also affects its functionality (reactive, data dominated, control dominated, etc...). For either architectural modeling or functional specification, depending on the characteristics of each component or part of the system, one or another Model of Computation (MoC) [LeSa98] may be more or less suitable. A MoC fixes the abstraction level and relationships between the different aspects of a system specification. As this complexity and heterogeneity grows, the choice of an adequate MoC becomes more important. An incorrect abstraction-level in one of the MoC features can lead to inefficiency, even unfeasibility, in modeling and design. Therefore, in order to allow the

designer to use the most appropriate specification method for each domain, the design methodology should support heterogeneous specification. Important advances have been made to cope with the growing complexity and heterogeneity. In order to handle complexity the abstraction level has been raised to what is called system-level. This rise can include one or more aspects (or, as we will see, domains of the Rugby metamodel) of the system description, which becomes a system-level specification, and lets us focus on the key aspects of a design or a model. Thus, system-level specification constitutes the initial and essential step of the design and it has a central role in the new integrated design framework [ITRS02]. New specification languages for system-level specification have been proposed. Among them, SystemC has been widely accepted by the user community as a system-level specification language [GLMS02][MuRR03]. Heterogeneous specification is also an active research field. One of the most important contributions is represented by Ptolemy [PTOL], a Java-based modeling and simulation environment able to support heterogeneous specifications. Under the same Java framework, the specification can be composed of different components, where each one can correspond to a different domain, each of them characterized by a different MoC. This work is based on the denotational framework established in [LeSa98]. This denotational framework is also called metamodel. The Rugby metamodel [Jant04] enables an objective and systematic analysis of different models of computation by fixing their coordinates in a rugby ball-shaped diagram (Figure 1 and 2). The Rugby metamodel considers two basic concepts in order to classify any language or specification method: domain and abstraction. Domain is a feature of the model that can be independently analyzed. The metamodel distinguishes four basic domains, namely Computation, Time, Communication and Data. The abstraction level determines the level of detail used in each domain. In the diagram, each line represents a domain. Each domain line goes from the highest abstraction (left) to the maximum specificity (right). A coordinate in each domain is fixed by the abstraction level used. A MoC coordinate is represented by the set of coordinates used in each domain. The Rugby metamodel does not include the hierarchy concept since this usually does not depend on the MoC considered. In this paper, we address the heterogeneous specification in SystemC. The proposed technique is based on a specification methodology able to support different models of computation [HSVF03]. For this purpose, Section 2 uses the Rugby Metamodel in order to systematically situate the design and the specification methodology that we are assuming and extending. The suitability of the whole methodology for a heterogeneous input in a design framework will be demonstrated. Section 3 reviews the two main existing approaches for MoC interfaces. Section 4 deals with the heterogeneous specification in our specification methodology. Firstly, in subsection 4.1, we explain the MoC interface framework for the specification methodology and introduce some new concepts for the analysis and design of those interfaces. Subsection 4.2 deals with the case of untimed MoC interfaces, that is, those involving the untimed MoCs studied in [HSVF03]. Section 5 summarizes the aims, main conclusions and contributions of our work.

2

Specification methodology in the Rugby metamodel

This section aims to clarify our methodology of system-level heterogeneous specification and its position in the design methodology from the point of view of the Rugby metamodel. First of all, Figure 1 highlights the suitability of SystemC for heterogeneous specification, as well as for system-level specification. The shadowed region shows the flexibility of the current language release (2.x) in the different domains, since it allows different abstraction levels in the domains. For example, by using Rugby terminology, SystemC 2.0 covers coordinates ((AlgLB),(IPC-Top/PC),(Sym-LV/PDT),(Caus-CT/PCT)). This is really a coordinate range where slashes separate the SW/HW options at low abstraction level. For example, for the Computation domain, the range goes from the Algorithmic level (Alg), typical of C/C++ programming, to Logic Block in HW. The Rugby metamodel can also illustrate the current limitations. These are basically in not

reaching the highest and lowest abstraction domain limits. For instance, SystemC does not enable the direct capture of a specification as abstract as only one set of relations and constraints in computation, interfaces, data types and time. It is expected that lower resolution levels will be available in Data and Time domains (if, for example, analog extensions are provided in future SystemC releases). Outside the scope of the Rugby metamodel, hierarchy is supported in SystemC through modules and ports. Forthcoming extensions (sc_export) will improve this. Summarizing, SystemC provides considerable flexibility for specification under different MoCs. CT/PCT Caus Time Comp

Specification Documents Comm

Alg

LB/Inst SystemC 2.0

IPC

HW/SW Implemetation Platform

Top/PC

Data

Sym Num

LV/PDT

High

Abstraction

Low

Figure 1. Flexibility of SystemC for heterogeneous specification. The highest abstraction level in this specification methodology is placed under the (Symb, IMC, Alg, Caus) coordinates. It is represented as the shadowed region in Figure 2. It involves the highest abstraction level that can be reached in each domain with SystemC 2.x. This corresponds to untimed MoCs (i.e., PN (Process Networks), KPN (Kahn Process Networks) [Kah74], CSP (Communicating Sequential Processes) [Hoa78] in [HSVF03]). In more detail, those coordinates correspond to Causality in the Time domain (time information can be abstracted to only partial order of events), Algorithmic in the Computation domain (process composed of sequential execution of statements), Inter-Process Communication in the Communication domain (through Interface Method calls, IMC) and Symbolic at Data domain (basically, supporting abstract data types). Time Caus Comp Alg Specification Documents

Design Refinement IMC

HW/SW Implemetation Platform

Comm Sym

High

Data

(b)

Low

Abstraction

Figure 2. System-level specification in the design. The specification could incorporate parts with at least one domain at a lower abstraction level. For example, a part specified under a Synchronous MoC involves greater detail in the Time domain. This detail would be higher, not only in the Time domain, but also in the Data domain if certain parts contain HW descriptions. Reaching the implementation involves one or more design steps (represented by the bold arrow), which through refinement in one or more domains (and more or less automatic), remove abstraction.

The MoC interface problem must be considered both at the specification (especially when we connect parts managing domains at different abstraction levels) and also at the design steps (which translate at least part of the system to lower abstraction levels).

3

General Resolution of MoC Interfaces

A fundamental problem in heterogeneous specification is the communication and synchronization of events among the system parts under different models of computation. This implies the development or use of a MoC interface. Taking into account the metamodel, this involves an adaptation (including or extracting information) in one or more domains. In some cases, this adaptation does not necessarily involve changing the abstraction level. Then, some other features (that differentiate one MoC from another) have to be considered. This will be seen in this paper when considering untimed PN, KPN and CSP MoCs. The adaptation has different complexities in each domain. The adaptation in the Time Domain can, in many cases, be considered more complex. However, in each domain, complexity depends on the decisions about which adaptation actions are finally performed (for example, at data domain, truncate or round, extend to 0 or interpolate) irrespective of whether the abstraction level is raised or lowered. In [Jant04], two main approaches for MoC interface solutions are shown: •

Interface definition for each MoC pair connection with separate frameworks. (Figure 3a).

•

Usage of a common framework for the communication of the parts specified under different MoCs (Figure 3b).

Before further discussion, we introduce two concepts: the specification and execution frameworks. The specification framework gives the specifier a set of elements with their own semantics and properties and rules for their interconnection. By using them, the specifier constructs a system specification, from which specific behavior and properties are expected to be obtained (system semantics). An execution framework sustains the specification framework and allows the structure and elements of the system specification to be executed without ambiguity in order to perform a functional and/or performance verification of the specification without the need of the final platform. As can be seen, in this case we are basically referring to the simulation engines running over a general purpose OS (linux, unix, windows, etc…), which runs in a host machine (PC, workstation). In this context, several types of simulation engines can be found, for execution (SystemC kernel), interpretation (i.e., a java runtime machine) or simulation (usual case of a VHDL simulator) of the specification. An execution framework for implementation provides the elements (technological libraries, embedded RTOS, etc,…) supporting the execution over the final platform. Notice that a physical distinction has been avoided. A simulation is actually running over a physical platform, the host machine. In a similar way, it is still usual to find physical platforms intended for development instead of final usage. They are also called target platform and are quite close to the final platform. It is important for the correction of the design flow that the design steps maintain the semantics when passing from a simulation to an implementation execution framework. This is especially important when those steps become automatic (since the specifier loses control over the less abstract design representations). Director 1

MoC1-MoC3 channel MoC 1

MoC 3

Matlab MoC1-MoC2 channel

HW simulator

MoC 2

Component Based Framework

atomic actor port composite actor

MoC2-MoC3 channel SPECIFICATION FRAMEWORK

ISS

(a)

EXECUTION FRAMEWORK

Director 2

receiver

atomic actor

Hierarchical Heterogeneity

Domain 1 (DE)

Figure 3. Two approaches for MoC link.

Domain 2 (CT)

(b)

With these concepts we will review these two MoC interface approaches. In the first MoC interface approach (Figure 3a), connection is more specific, explicit and localized. It usually deals with separate specification and execution frameworks. There are several examples. A typical one would be the traditional cosimulation of SW with HDL modules. Each part has quite different specification (i.e., HDL contrasting with a SW code style) and execution (discrete event HDL simulator versus instruction set simulator) frameworks. These differences are translated into different coordinates in Rugby domains (i.e., bit types, symbolic types in Data domain). The communication between them is usually performed by adaptation functions/processes that normally use a C-like interface provided by the HW simulator. These functions enclose and mask the necessary adaptations performed in the different Rugby domains. The most representative example of the second approach is Ptolemy, which provides a common specification framework. It is a component-based specification framework where the specifier manages actors (components) with ports. Actors communicate among themselves through receivers (a common type of channel of the send-rev type). This has one important advantage: each time a new MoC is added, it only requires the implementation of the interface between the new MoC and the framework. Below and somehow hidden, several different (although managed with the same interface) execution frameworks are provided. In Ptolemy, those execution frameworks for simulation are called domains1 and their main element is the director class and its interaction with receivers. These domains are associated with a composite actor and control the execution of actor components (other atomic or composite actors). In this way, there can be a domain hierarchy matched with a component hierarchy. Because of this, Ptolemy is said to support hierarchical heterogeneity. The MoC interface task focuses on receivers and, as commented, the adaptation task avoids considering each MoC combination. A possible disadvantage for the management of this kind of “common channels” is that it could be too general for some MoC channels or too restrictive for others. A difficult barrier that these approaches have to overcome (especially in the first case, where neither the specification nor the execution framework is common), is the separation of the different parts of the system in different frameworks, not only for writing MoC interfaces, but also for the rest of design tasks.

4 4.1

Heterogeneous Specification in SystemC MoC Interfaces in the SystemC specification methodology

The main difference between previous methodologies (Figure 3) and the proposed methodology (Figure 4) is that the latter one provides common specification and implementation frameworks. MoC 1

process Concurrency-Based Specification Framework supporting component hierarchy

BC

Amorphous Heterogeneity

BP channel

MoC 2

SystemC 2.0 simulation kernel (Strict-Timed Discrete Event)

BC: Border Channel BP: Border Process Common Execution Framework

Figure 4. Specification and Execution frameworks in our SystemC methodology. A system-level heterogeneous specification methodology based on SystemC provides the common specification framework. The homogeneity of the specification framework is due to the use of the same language for all the MoCs and the systematic use of processes and channels for 1

Note that here the meaning of ‘domain’ is different than in the Rugby metamodel.

specifying concurrent functionality. The heterogeneity is achieved through the definition of each MoC by the different set of channels and process styles. Therefore, the issue of MoC interfaces will basically deal with the nature of the processes and channels on the border of the parts specified under different MoCs. In this approach, suitable MoC interfaces will be provided for each MoC pair. Hierarchy at several levels is also supported. However, although possible, no match between components and MoC is necessary. We can find one module containing parts under two or more MoCs or a MoC distributed in several modules. Therefore, hierarchy will not be relevant (a flattening is considered) in terms of MoC location. This does not mean that hierarchy is completely discarded in the MoC study. The capacity for hierarchical composition from the MoC primitives will be considered when several MoCs are involved in the specification. The common execution framework for simulation is based on a strict-timed discrete event simulation kernel. Due to the abstraction provided by the OO capabilities of C/C++, the underlying SystemC MoC can be hidden and other more abstract MoCs can be built on top [GLMS02]. This enables the construction and execution of a SystemC specification combining several MoCs, and thus a heterogeneous specification. For instance, the same simulation can execute some processes where only causality relations are taken into account, while other processes are being triggered by a timed clock source. The specifications constructed and executed in this way show amorphous heterogeneity (instead of hierarchical). That is, the SystemC simulation kernel, the topology of processes and channels and their blocking semantics control the execution, obliging a partial or a total order, or a time placement. Because of this, no match between component hierarchy and distribution of MoCs is needed. As commented before, communication and synchronization of events is an important main problem to be solved in heterogeneous specification. δ

untimed-untimed I.

Untimed MoC PN, KPN, CSP,... untimed-SR I. untimed-timed I. timed-timed I. Timed MoC

Synchronous SR, CS

(ti,δi) synch-synch I.

timed-SR I.

(tj,δi)

(tk,δi)

t

untimed MoC: Ti = (ti,δj) >=< Tj = (tm,δn) (events partially ordered) SR MoC: ti inputs = tj outputs (perfect synchrony)

Figure 5. MoCs taking into account Time domain. Figure 5 shows how the MoC interface problem is confronted in our methodology. It starts by considering a MoC classification that takes Time domain information into account [Janst04]. Three basic MoC groups are distinguished, namely, untimed, synchronous and timed. The classification can be interpreted in our SystemC methodology by means of the abstraction of the necessary time properties from the whole set of time information that the strict-timed discrete event simulation kernel maintains during the execution (basically coordinates (ti,δi)). In [HSVF03], the PN, KPN and CSP untimed MoCs and the synchronous reactive (SR) MoC [BeBe91] (which assumes the perfect synchrony hypothesis) were treated. The basic feature which defines untimed MoCs is that process events are related by a partial order (their time tags are partially ordered Ti=(ti,δj)>=