Keywords

18.1 Introduction

18.1.1 Embedded Systems

Embedded systems are special-purpose systems which are typically embedded within larger units providing a dedicated service to that unit [1]. In most embedded systems, the product manufacturer provides a function-specific software application, and end-users have limited access to altering the application running on the system. Examples of embedded systems include consumer electronics products (i.e. cell phones, PDAs, microwaves, etc.), transport control systems, plant control systems and defense systems.

Vahid et al. [2] describe the characteristics of embedded systems that differentiate them from other digital systems:

  • Single-functioned. Embedded systems repeatedly perform a specific function.

  • Reactive and real time. Many embedded systems, especially in the control domain, are reactive systems and must continually react to changes in the environment and meet timings constraints without delay.

  • Tightly constrained. Embedded systems have tight constraints on design metrics. For example, embedded systems must have minimum design costs, must have small form factors and consume minimum power, especially for portable systems, must meet real time requirements, must be safe and reliable, and must have short time-to-market cycle.

A typical heterogeneous embedded system consists of: dedicated hardware parts (ASIC), programmable processors such as microprocessor and ASIPFootnote 1 components (i.e. DSP and microcontrollers), memory for data and code, peripherals such A/D, D/A and I/O units, and buses connecting the above components [3].

Traditionally, hardware synthesis tools (logic synthesis and behavior synthesis) have been used to increase productivity. However, hardware synthesis is not sufficient since embedded systems use more software content [4]. In addition, hardware synthesis methods focus on designing a single hardware chip, where more embedded systems are using heterogeneous architectures.

The complexities in designing embedded systems motivate the need for using more efficient tools and design methodologies. System Level Design is a methodology to help address these complexities, and enable SoC designs.

18.2 System Level Design

System Level Design is concerned with addressing the challenges encountered in designing heterogeneous embedded systems. In System Level Design, complexities are managed by (1) starting the design process at the highest level of abstraction (System Level), (2) utilizing automated design methodologies to enable step-wise refinements during the design process (3) reusing Intellectual Property (IP) components when feasible [5, 6].

The goal of System Level Design is to implement System Level specification on target architecture by refining the specification into a set of target-specific specifications.

Designing at a higher level of abstraction reduces the number of components with which the designer has to deal with, and thus increasing design productivity. This paradigm shift in design requires methodologies and automated tools to support design at higher levels abstractions.

18.2.1 System Level Design Approaches

There are three main system level design approaches: hardware/software co-design, platform-based design and component-based design [7].

  • Hardware/Software co-design (also referred to system synthesis) is a top-down approach. Starts with system behavior, and generates the architecture from the behavior. It is performed by gradually adding implementation details to the design.

  • Platform-based design. Platform-based design maps the system behavior to predefined system architecture. An example of platform-based design is shown in [8].

  • Component-based design is a bottom-up approach. It assembles existing heterogeneous components by inserting wrappers between these components. An example of component-based design is described in [9].

18.3 Hardware/Software Co-design

Hardware/Software co-design can be defined as the cooperative design of hardware and software in order to achieve system-level objectives (functionality & constraints) by exploiting the synergism of hardware and software [6, 7]. While hardware implementation provides higher performance, software implementation is more cost effective and flexible since software. The choice of hardware versus software in co-design is a trade-off among various design metrics like performance, cost, flexibility and time-to-market. Figure 18.1 shows the flow of a typical Hardware/Software co-design system.

Fig. 18.1
figure 1_18figure 1_18

Flow of a typical co-design system

Full size image

Generally, Hardware/Software co-design consists of the following activities: specification and modeling, design and validation [6].

18.3.1 Specification and Modeling

This is the first step in the co-design process. The system behavior at the system level is captured during the specification step [3]. Section 18.4 provides details about specification and modeling, including Models of Computation.

18.3.2 Design and Refinement

The design process follows a step-wise refinement approach using several steps to transform a specification into an implementation. Niemann [3] and O’Nils [6] define the following design steps:

Tasks assignment, Cost estimation, Allocation, Hardware/Software partitioning, Scheduling, and Co-synthesis. Niemann [3] classifies several design steps as part of co-synthesis: Communication synthesis, Specification refinement, Hardware synthesis and Software synthesis.

18.3.3 Validation

Informally, validation is defined as the process of determining that the design, at different levels of abstractions, is correct. The validation of hardware/software systems is referred to as co-validation. Methods for co-validations are [9, 10]: Formal verification andSimulation. A comparison of co-simulation methods is presented in [11].

18.4 Specification and Modeling

Specification is the starting point of the co-design process, where the designer specifies the system’s specification without specifying the implementations. Languages are used to capture system specifications. Modeling is the process of conceptualizing and refining the specifications. A model is different from the language used to specify the system. A model is a conceptual notation that describes the desired system behavior, while a language captured that concept in a concrete format. A model can be captured in a variety of languages, while a language can capture a variety of models [2].

Two approaches are used for system specification, homogeneous modeling where one specification language is used for specifying both hardware and software components of a heterogeneous system and heterogeneous modeling which uses specific languages for hardware (e.g. VDHL), and software (e.g. C) [6, 12].

18.4.1 Models of Computation

A computational model is a conceptual formal notation that describes the system behavior [2]. Ideally, a Model of Computation (MOC) should comprehend concurrency, sequential behavior and communication methods [10]. Co-design systems use computational models as the underlying formal representation of a system. A variety of Models of Computation have been developed to represent heterogeneous systems.

The following is an overview of common MOCs based on the work in Cortes et al. [10] and Bosman [13].

18.4.1.1 Finite State Machines (FSM)

The FSM model consists of a set of states, a set of inputs, a set of outputs, an output function, and a next-state function [14]. A system is described as set of states and input values can trigger a transition from one state to another. FSMs are commonly used for modeling control-flow dominated systems. The main disadvantage of FSMs is the exponential growth of the number of the states as the system complexity rises due the lack of hierarchy and concurrency. To address the limitations of the classical FSM, researches have proposed several derivates of the classical FSM. Some of these extensions are described below.

  • SOLAR [15] is based on the Extended FSM model (EFSM), which can support hierarchy and concurrency. In addition, SOLAR supports high level communication concepts including channels and global variables. It is used to represent high-level concepts in control-flow dominated systems, and it is mainly suited for synthesis purposes. The model provides an intermediate format that allows hardware/software designs at the system-level to be synthesized.

  • Hierarchical Concurrent FSM (HCFSM) [3] solve the drawbacks of FSMs by decomposing states into a set of sub-states. These sub-states can be concurrent sub-states communicating via global variables. Therefore, HCFSMs supports hierarchy and concurrency. Statecharts is a graphical state machine language designed to capture the HCFSM MOC [2]. The communication mechanism in statecharts is instantaneous broadcast, where the receiver proceeds immediately in response to the sender message. The HCFSM model is suitable for control oriented/real time systems.

  • Codesign Finite State Machine (CFSM) [16, 17] adds concurrency and hierarchy to the classical FSM, and can be used to model both hardware and software. It is commonly used for modeling control-flow dominated systems. The communication primitive between CFSMs is called an event, and the behavior of the system is defined as sequences of events. CFSMs are widely used as intermediate forms in co-design systems to map high-level languages, used to capture specifications, into CFSMs.

18.4.1.2 Discrete-Event Systems

In a Discrete Event system, the occurrence of discrete asynchronous events triggers the transitioning from one state to another. An event is defined as an instantaneous action, and has a time stamp representing when the event took place. Events are sorted globally according to their time of arrival. A signal is defined as set of events, and it is the main method of communication between processes [10]. Discrete Event modeling is often used for hardware simulation. For example, both Verilog and VHDL use Discrete Event modeling as the underlying Model of Computation [11]. Discrete Event modeling is expensive since it requires sorting all events according to their time stamp.

18.4.1.3 Petri Nets

Petri Nets are widely used for modeling systems. Petri Nets consist of places, tokens and transitions, where tokens are stored in places. Firing a transition causes tokens to be produces and consumed. Petri Nets supports concurrency and is asynchronous; however, they lack the ability to model hierarchy. Therefore, it can be difficult to use Petri Nets to model complex systems due to its lack of hierarchy. Variations of Petri Nets have been devised to address the lack of hierarchy. For example, the Hierarchical Petri Nets (HPNs) proposed by Dittrich [18].

  • Hierarchical Petri Nets (HPNs) supports hierarchy in addition to maintaining the major Petri Nets features such as concurrency and asynchronously. HPNs use BipartiteFootnote 2 directed graphs as the underlying model. HPNs are suitable for modeling complex systems since they support both concurrency and hierarchy.

18.4.1.4 Data Flow Graphs

In Data Flow Graph (DFG), systems are specified using a directed graph where nodes (actors) represent inputs, outputs and operations, and edges represent data paths between nodes [3]. The main usage of Data Flow is for modeling data flow dominated systems. Computations are executed only where the operands are available. Communications between processes is done via unbounded FIFO buffering scheme [10]. Data Flow models support hierarchy since the nodes can represent complex functions or another Data Flow [6, 10].

Several variations of Data Flow Graphs have been proposed in the literature such as Synchronous Data Flow (SDF) and Asynchronous Data Flow (ADF) [18]. In SDF, a fixed number of tokens are consumed, where in ADF the number of tokens consumed is variable. Lee [19] provides an overview of Data flow models and its variations.

18.4.1.5 Synchronous/Reactive Models

Synchronous modeling is based on the synchrony hypothesis, which states that outputs are produced instantly in reaction to inputs and there is no observable delay in the outputs [12]. Synchronous models are used for modeling reactive real time systems. Cortes in [11] mentions two styles for modeling reactive real time systems: multiple clocked recurrent systems (MCRS) which is suitable for data dominates real time systems and state base formalisms which is suitable for control dominated real time systems. Synchronous languages such as Esterel [15] is used for capturing Synchronous/Reactive Model of Computation [11].

18.4.1.6 Heterogeneous Models

Heterogeneous Models combine features of different models of computation. Two examples of heterogeneous models are presented.

  • Programming languages [20] provide a heterogonous model that can support data, activity and control modeling. Two types of programming languages: imperative such as C, and declarative languages such as LISP and PROLOG. In imperative languages, statements are executed in the same order specified in the specification. On the other hand, execution order is not explicitly specified in declarative languages since the sequence of execution is based on a set of logic rules or functions. The main disadvantage of using programming languages for modeling is that most languages do not have special constructs to specify a system’s state [3]

Program State Machine (PSM) is a merger between HCFSM and programming languages. A PSM model uses a programming language to capture a state’s actions [20]. A PSM model supports hierarchy and concurrency inherited from HCFSM. The Spec Charts language, which was designed as an extension to VHDL, is capable of capturing the PSM model. The Spec C is another language capable of capturing the PSM model. Spec C was designed as an extension to C [2].

18.4.2 Comparison of Models of Computation

A comparison of various Models of Computation is presented by Bosman [13], and Cortes et al. [10]. Each author compares MOCs according to certain criteria. Table 18.1 compares MOCs based on the work done in [10, 13].

Table 18.1 Comparison of models of computation [16, 20]
Full size table

18.4.3 Specification Languages

The goal of a specification language is to describe the intended functionality of a system non-ambiguously. A large number of specification languages are currently being used in embedded system design since there is no language that is the best for all applications [3]. Below is a brief overview of the widely used specification languages [2, 6]:

18.4.3.1 Formal Description Languages

Examples of formal languages are LOTOS and SDL.

  • LOTOS is based on process algebra, and used for the specification of concurrent and distributed system.

  • SDL used for specifying distributed real time systems, and based on extended FSM.

18.4.3.2 Real Time Languages

Esterel & StateCharts are examples of real time languages.

  • Esterel is a synchronous programming language based on the synchrony hypothesis. It is used for specifying real time reactive systems. Esterel is based on FSM, with constructs to support hierarchy and concurrency.

  • StateCharts is graphical specification language used for specifying reactive system. StateCharts extend FSM by supporting hierarchy, concurrency and synchronization.

18.4.3.3 Hardware Description Languages (HDL)

Commonly used HDL are VHDL, Verilog and HardwareC.

  • VHDL is IEEE standardized HW description language.

  • Verilog is another hardware description language, which has been standardized by IEEE.

  • HardwareC is a C based language designed for hardware synthesis. It extends C by supporting structural hierarchy, concurrency, communication and synchronization.

18.4.3.4 System Level Design Languages (SLDL)

System Level Design Languages (SLDL) are used to capture specification and model embedded system at the system abstraction level. With the increased time-to-market pressure, and to enable SoC designs, SLDS need to be able to specify and model all aspects of the system at higher abstraction level (at the System Level). This will allow early design space exploration to evaluate various design alternatives early in the design process. Most current SLDLs lack built-in support for specifying and modeling ALL aspects of a heterogeneous embedded system at the System Level. Some of these deficiencies are lack of support for:

  • RTOS modeling at the System Level. This is important for modeling real time embedded system, and determining if the scheduling policy will meet time constraints and deadline at the System Level before committing to a specific RTOS implementation.

  • Composing Heterogeneous models with multiple MoCs.

  • Estimating power consumption at the System Level.

Examples of SLDL are SpecC and SystemC.

  • SpecC [14] is system level design language based on ANSI C. It was developed at the University of California, Irvine to improve traditional HDL languages such as VHDL. The SpecC language models systems as a hierarchal network of behaviors and channels [3]. SpecC supports behavior and structural hierarchy, concurrency, state transition, exception handling, timing aspects and synchronization. Built on the SpecC language is the SpecC design methodology.

  • SystemC [21] is a C\(++\) library based language designed by the OpenSystemC Initiative (OCSI) group to improve traditional HDL languages.

18.4.4 Requirements for Specification Languages

Gajski in [14] and Niemann in [3] describe the requirements for specification languages:

  • Hierarchy is an important feature of a specification language. Two types of hierarchy: (1) behavior hierarchy which allows a behavior to be decomposed of sub-behaviors, (2) structural behavior which allows a system to be specified as a set of interconnected components, where these components can be specified as sub-components as well.

  • State transition is important for modeling control and reactive embedded systems.

  • Concurrency a large number of embedded systems consist of tasks that are working concurrently.

  • Synchronization needed when concurrent parts of exchange data.

  • Exception handling exceptions such as reset and interrupts often occur in embedded systems. When an interrupt occurs, the system has to transition to a new state to handle the interrupt. Once the interrupt is serviced, the system has to go back to point prior to interrupt. Specification languages should be able to model exceptions.

  • Timing is an important aspect of specifying real time embedded systems. Two timing aspects have to be specified when dealing with embedded systems: Functional timing which represents the time consumed for executing a behavior, and timing constraints which represent a range of time for executing a behavior.

  • Formal verification desirable for specification languages since it provides a mechanism to verify the use of formal mathematical methods.

  • Support for RTOS modeling is important for the specification of real time systems that will use a RTOS to implement dynamic scheduling.

Table 18.2 shows a comparison of different specification languages.

Table 18.2 Comparison of specification languages
Full size table