Embedded Software Generation from SystemC for Platform Based Design

Embedded Software Generation fromSystemC for Platform Based Design

by

Carsten Schmitt

December 2004

1

This document describes conventional and new software generation approaches for embeddedsystems. It justifies the need of another abstraction layer and points out why the specificationlanguage SystemC meets these needs. The SC2RTOS implementation library is presented, therealization of HW/SW partitioning is mentioned and an overview about the whole software gen-eration from SystemC is given.

2

Contents

1 Introduction 31.1 SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 What is SystemC ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Advantages of SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.3 Components of SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.4 Do we really need another abstraction level ? . . . . . . . . . . . . . . . 4

2 Basics 72.1 RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Software Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Communicating Finite State Machine (CFSM) . . . . . . . . . . . . . . 82.2.2 Petri net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Data Flow Graph (DFG) . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Control Flow Graph (CFG) . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Software Design for Embedded Systems 133.1 The problems of software design for embedded systems . . . . . . . . . . . . . . 133.2 Conventional Software Generation Techniques . . . . . . . . . . . . . . . . . . . 13

3.2.1 Hand written Assembler-Code . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Classical Co-Design Methodologies . . . . . . . . . . . . . . . . . . . . 13

3.3 New Approaches To Lower Software Costs . . . . . . . . . . . . . . . . . . . . 143.3.1 Specify Explore Refine Methodology . . . . . . . . . . . . . . . . . . . 143.3.2 API-Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.3 SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Glossary 234.1 General Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

Contents

2

1 Introduction

1.1 SystemC

1.1.1 What is SystemC ?

SystemC is an extension of the conventional C++ programming language - not a design method-ology. It enables modeling hardware properties of a micro electronic system on a high level ofabstraction. This approach aims on an efficient system design to fulfill the time to market require-ment. More detailed SystemC is a C++ class library which allows hardware modeling similar toVHDL. Additional information can be found at [10] [14].

1.1.2 Advantages of SystemC

SystemC is an executable specification

SystemC is an executable specification. It is simple to create an executable (binary file) whichincludes a SystemC Simulation Kernel. This means that it is quite simple to test a specificationwhich is written in SystemC by simulating - that means simply executing the binary file. Moredetails can be found at [8].

High simulation performance

C++ is a high level language which can well optimized executables can be generated from. Thereason for this is the existence of sophisticated compilers like the gcc. Since SystemC is still anextension of C++ which is completely written in C++ itself. It is possible to use all advantages ofit - especially its performance.

Simple refinement of the C++ specification

It is easy to refine the SystemC specification because it supports the so called Single SourceApproach. This means that the specification is the one and only thing which is to be modifiedby the engineer. The main advantage is that the same code is used for system level specificationand verification, and, after HW/SW partitioning, for HW/SW co-simulation and embedded SWgeneration. It is no longer necessary to transform the specification to a Hardware DescriptionLanguage HDL. This avoids a semantical break which would add another source of error to theproject. Figure 1.1 shows the refinement of the HW specification with and without semanticalloss.

Tools are available for graphical simulation and hardware synthesis

Many software companies realized the advantages of SystemC and began to develop SystemCplugins for their software products. For example CoWare and Synopsis extended their productsnamed ConvergenSC and CoCentricSystemStudio (CCSS) to support SystemC.

3

1 Introduction

Figure 1.1 Refinement with and without semantical break

SystemC is free

SystemC is freely provided by the OSIC (Open System Initiative). The OSIC consists of sev-eral companies having their field of activity on technical sectors. The SystemC library and itsdocumentation can be downloaded at [10].

1.1.3 Components of SystemC

1. Processes (similar to VHDL)

2. Modules (Containers for processes and other modules). Figure 1.2 shows the UML repre-sentation of the module relationship.

Figure 1.2 UML description of the module construct

3. Signals (similar to VHDL)

4. Clocks (special signals to control the simulation progress)

5. Abstract communication channels

1.1.4 Do we really need another abstraction level ?

Many experienced VHDL and Verilog designers are highly critical of using C++ as a hardwaredescription language (HDL), saying that the world does not need another HDL (especially a more

4

1.1 SystemC

complex one). Of course a C++HDL will not be a better HDL than VHDL or Verilog, but it willbe a better language for HW/SW co-simulation. This is because SystemC has many advantages:It provides a standard description for different abstraction levels. Moreover, it provides highsimulation speed and it is possible to simulate the whole system before the hardware constructionprocess finished.

The increasing complexity of technology and market pressure justifies the introduction of an-other abstraction level. The gap between the amount of possible transistors and productivity in-creases again. Figure 1.3 shows the progress of technology which is described by Moore’s Law(Source: [11]). To close this gap a new abstraction layer which increases productivity is necessary.

Figure 1.3 Moores Law

5

1 Introduction

6

2 Basics

2.1 RTOS

The difference between a Real Time Operating System (RTOS) and a conventional op-erating system is the execution time of commands. A conventional operating system cannot guar-antee the execution of a command within a given time period. Nevertheless, this is an importantrequirement in technical applications. This leads to RTOSswhich can guarantee the execution of acommand within a given time. More information about RTOSs can be found at [7]. The technicalrealization can be met by special operating system kernel architectures. An RTOS is a very usefulabstraction interface between applications with hard real-time requirements and the target systemarchitecture.There are different Real Time Operating Systems - some are commercial others are academic:

OS-Name license vendor

eCos academic Red HatµC/OS-II commercial MicriumVxWorks commercial Wind RiverQNX commercial QNX Software SystemsAMX commercial KADAKC Executive commercial JMI SoftwareRTX commercial CMX SystemsINTEGRITY commercial Green Hills SoftwareLynxOS commercial LynuxWorksNeutrino commercial QNX Software SystemsNucleus commercial Mentor GraphicsRTOS-32 commercial OnTime SoftwareOS-9 commercial MicrowareOSE commercial OSE SystemspSOSystem commercial Wind RiverQuadros commercial RTXCRTEMS commercial OARThreadX commercial Express LogicLinux/RT academic TimeSysVRTX commercial Mentor Graphics

Table 2.1: Some commercial and academic Real Time Operating Systems (Source: [15])

2.2 Software Models

Typically two models are used to describe software: state oriented and activityorientedmodels. State orientedmodels use a set of states and transitions which connectthe states. Examples for state oriented models are Communicating Finite State Machines

7

2 Basics

CFSMs and Petri nets.An activity orientedmodel is described as a set of operations related by data or executiondependencies. Examples for those models are Data Flow Graphs DFGs and Control FLow GraphsCFGs. For a more detailed description see [4].

2.2.1 Communicating Finite State Machine (CFSM)

A Communicating Finite State Machine (CFSM), like a classical Finite State Ma-chine, transforms a set of inputs into a set of outputs with only a finite amount of internal states.The difference between the two models is that the synchronous communication model of classi-cal concurrent FSMs is replaced in the CFSM model by a finite, non-zero, unbounded reactiontime. This model of computation can also be described as Globally Asynchronous, Locally Syn-chronous. Each element of a network of CFSMs describes a component of the system which hasto be modeled. The whole network of CFSMs define a protocol. In this case states (conditions)of the process are represented by Nodes. Edges represent transitions (events) of the process.Transitions include actions taken the process (e.g. sending a message) or external stimuli (e.g. thereception of a message). The sending message transition is labeled as -Msg where Msg is thetype of messages being sent. The receiving message transition is labeled as +Msg where Msg isthe head message on the incoming FIFO queue of the CFSM. The channels that connect CFSMsare assumed to be FIFO queues. Starting at the initial node (starting state of a CFSM), aCFSM traverses the nodes and transitions. The node currently being visited is called the currentnode. When a machine traverses a sending transition, it sends/appends a message with the samelabel to its outgoing channel. A machine at a node cannot traverse its receiving transition unlessthere is a message matched with the same label on the head of its incoming channel. When amachine traverses a receiving transition, it removes the matched head message of its incomingchannel. Figure 2.1 shows such a CFSM with three states. The abbreviations c1 and c2 define thein- and outgoing channels. The edges between the states show the sending (-Req) and receiving(+Ack) of messages.

Figure 2.1 Communicating Finite State Machine (CFSM)

2.2.2 Petri net

A Petri net is a graphical and mathematical modeling tool. It consists of places,transitions, and arcs that connect them. Input arcs connect places with transitions,while output arcs start at a transition and end at a place. There are other types of arcs, e.g.inhibitor arcs. Places can contain tokens; the current state of the modeled system (themarking) is given by the number (and type if the tokens are distinguishable) of tokens in eachplace. Transitions are active components. They model activities which can occur (the transition

8

2.2 Software Models

fires), thus changing the state of the system (the marking of the Petri net). Transitions are onlyallowed to fire if they are enabled, which means that all the preconditions for the activity mustbe fulfilled (there are enough tokens available in the input places). When the transition fires, itremoves tokens from its input places and adds some at all of its output places. The number oftokens removed / added depends on the cardinality of each arc.Petri nets are a promising tool for describing and studying systems that are characterized as beingconcurrent, asynchronous, distributed, parallel, nondeterministic, and/or stochastic. As a graphicaltool, Petri nets can be used as a visual-communication aid similar to flow charts, block diagrams,and networks. In addition, tokens are used in these nets to simulate the dynamic and concurrentactivities of systems. As a mathematical tool, it is possible to set up state equations, algebraicequations, and other mathematical models governing the behavior of systems.To study performance and dependability issues of systems it is necessary to include a timingconcept into the model. There are several possibilities to do this for a Petri net; however, themost common way is to associate a firing delay with each transition. This delay speci-fies the time that the transition has to be enabled, before it can actually fire. If the delay is arandom distribution function, the resulting net class is called stochastic Petri net. Dif-ferent types of transitions can be distinguished depending on their associated delay, for instanceimmediate transitions (no delay), exponential transitions (delay is an exponential distri-bution), and deterministic transitions (delay is fixed). Figure 2.2 shows an examplePetri net which contains the mentioned elements. More information about Petri nets can befound at [2].

Figure 2.2 Petri net

2.2.3 Data Flow Graph (DFG)

A Data Flow Graph (DFG) is a graph which represents a data dependency between a number ofoperations. Any algorithm consists of a number of ordered operations. Graphical representationsof computations have been developed to provide an insight into sequence of computations. Acomplete process has been developed that begins with the translation of the requirements for asignal processing problem description into a DFG. This process allows the designer to rapidlyprogress from the signal processing algorithm to executable code that is automatically generatedto run on the target. More information about DFGs can be found at [1]. Figure 2.3 shows anexample DFG which illustrates the computation of the following expression:

X =(b2 − 4ac

) 12 − b

2a

9

2 Basics

Figure 2.3 DFG

2.2.4 Control Flow Graph (CFG)

A Control Flow Graph (CFG) is an abstract data structure which is used like DFGs in compilers. Itis an abstract representation of a procedure or program, maintained internally by a compiler. Eachnode in the graph represents a basic block, i.e. a straight-line piece of code without any jumps orjump targets; jump targets start a block, and jumps end a block. Directed edges are used to repre-sent jumps in the control flow. There are, in most presentations, two specially designated blocks:the entry block, the control enters into the flow graph through, and the exit block, all control flowleaves through.The CFG is essentially to several compiler optimizations based on global data flow analysis (def-use chaining, use-def chaining).A CFG is a static representation of the program which represents all alternatives of control flow.This allows a compiler to detect non-syntactic loops, such as those created with the GOTO state-ment.Reachability is another graph property useful in optimization. If a block/subgraph is not connectedwith the subgraph containing the entry block, that block is unreachable during any execution andso is dead code - it can be safely removed. Figure 2.4 is a CFG (Control Flow Graph).

10

2.2 Software Models

Figure 2.4 CFG

11

2 Basics

12

3 Software Design for Embedded Systems

3.1 The problems of software design for embedded systems

Some purpose design techniques like the Rational Unified Process (RUP) are not suit-able because embedded software has a strong interaction with the environment. Moreover, theresources are very limited and there are strong constraints (cost, timing, power, etc.). Anotherproblem is that the hardware has to be finished before software can be tested. These circum-stances made it very hard to find a general methodology of software development. The followingsection describes the evolution of software development methodologies.

3.2 Conventional Software Generation Techniques

3.2.1 Hand written Assembler-Code

During the 1970s and 1980s embedded software was usually hand written in C or assembler code.The result was linked with a hand written real time kernel and then integrated with the hardwarein a final step.Developing new software from ground up always leads to problems. The main problem is thatthere are unforeseen events which have not been considered before. For example the performancerequirements might change or the customer wants another feature. This forces changes late in thedevelopment process and that needs time. Since time is money and money is rare this became anunreliable and ineffective design process.Additionally, the implementation technology evolved towards increasing complex integrated cir-cuits that allowed the integration of the complete embedded systen on a chip - System on Chip(SoC) was born. A SoC normally includes microprocessors, memory blocks, peripheral modulesand hardware components which implement specific system functions (e.g. time critical pro-cesses). The design of hardware and software stands in close relation - so close that they have tobe developed at the same time. To cope with this new requirement a new design methodology wasintroduced - the co-design methodology.

3.2.2 Classical Co-Design Methodologies

In order to design these complex embedded systems on time, new co-design techniques have beenproposed. Originally these were based on a ‘describe and synthesize’ methodology. Figure 3.1shows a classical co-design flow in which the source code of the embedded system is synthesizedfrom a high level specification (System Specification) (e.g. HardwareC), the source code (C) ofthe embedded system is synthesized. Classical co-design tools compile the system specificationinto an internal representation model. Parts of this model might be CFSMs, Petri Nets, DFGand CFGs.After the system specification is compiled successfully into one of the above models (internalrepresentation) the HW/SW partitioning takes place. This must be done under the given designconstraints (cost, power, performance requirements).After this step the software synthesis begins. So called schedulers split the concurrent

13


software tasks on a shared resource - the CPU. Another task of these schedulers is to increaseexecution speed and reduce memory usage. This scheduling takes place before the actualcompilation with a retargetable compiler starts (for example gcc). More details can be found at[16].The main disadvantage of these methodologies is the lack of a code reuse. Many problems arecaused by an input description modification. The early splitting into SW and HW parts causessoftware debugging difficulties and poor code. In the late 1990s the ’describe and synthesize’methodology did not survive because it did not fulfill the time to market constraints.

Figure 3.1 Classical Co-Design Flow

3.3 New Approaches To Lower Software Costs

3.3.1 Specify Explore Refine Methodology

Design reuse and platform based design are key points of the ’specify explore refine’ method-ology. The basic idea is to assign the functions to be implemented to components of the platformor IP (Intellectual Properties) libraries. The system behavior is normally fixed but some method-ologies allow implementing different behaviors. The mapping is an iterative process in whichperformance simulation tools evaluate and compare the mapped architectures and guide the nextassignment. The re-used hard- and software components are added to the design after mapping.Finally the rest of the system is implemented.

14


This methodology maps a previously specified behavior (e.g. with SystemC) to a specific plat-form - that means in a suitable previously by simulation tools selected architecture. The hardware-design reuse has one advantage: The instruction set architecture (ISA) - a set of processor instruc-tions of a specific architecture - is constant. This makes software porting (or re-targeting) mucheasier. Figure 3.2 illustrates the mentioned situation.

Figure 3.2 One interface - many implementations

There are two main concerns for effective platform based design:

1. The Integrated Development Environment (IDE) (compiler, linker, assembler, debugger andsimulator)

2. A set of tools that encapsulate the details of the architecture from the application software -the RTOS and device drivers

The second one defines the Application Programmable Interface (API). More information aboutplatform based design can be found at [9] [5] [3]. Figure 3.3 shows the whole Platform BasedDesign Flow.

3.3.2 API-Platform

An application programming interface (API) is a set of definitions of the ways in which one pieceof computer software communicates with another. It is a method of achieving abstraction, usually(but not necessarily) between lower-level and higher-level software.One of the primary purposes of an API is to provide a set of commonly-used functions - for ex-ample to draw windows or icons on screen. Programmers can then take advantage of the API bymaking use of its functionality, saving them the task of programming everything from scratch.APIs themselves are abstract: software that provides a certain API is often called the implemen-tation of that API.In that case the API or better API-Platform is the interface between the selected archi-tecture (the hardware) and the software. On embedded systems this task is taken over bythe RTOS. Recently mentioned software generation methodologies must take into account thisAPI-Platform.

15


Figure 3.3 Platform Based Design Flow

3.3.3 SystemC

The role of SystemC in platform based design

The role of a system level description language is of great importance because the conventionaldesign-flow will change into an integrated framework in which the input is a system level specifi-cation (e.g. SystemC). In this integrated framework co-design, logical, physical, layout and othertools operate together. In this context SystemC will play a very important role because it allowssystem level specification, performance analysis and verification. Additionally, it facilitates thesoftware analysis and generation. More detailed information can be found at [13].

Single Source Approach

Most common methodologies propose an intermediate step (manual or automatic) when gener-ating software from a specification language. This intermediate step causes a semantical breakwhich makes it more difficult to test and debug an application. This is where the single sourceapproach comes into play: In a single-source approach for the systematic generation of the binarycode, the software synthesis step is eliminated and the same specification code is used. This iswhat is meant with Single Source Approach.The main advantage of this approach is that it facilitates the software generation process and de-

16


bugging.The idea of this approach comes from the observation that there is a high correlation betweenthe software code and the system level specification code. Moreover, the system level descriptioncode and the software code present similar construction elements in order to support concur-rency, synchronization and communication.For example, a SystemC process declaration has a direct relation to the corresponding threaddeclaration in an RTOS API.

Realization of the Single Source Approach - Technology Mapping

The relationship between the system level description code and the software code and their con-structions normally is not so direct. For example SystemC channels normally use notify andwait constructions to synchronize data transfer and process execution. The RTOS normally sup-ports many different implementations for these tasks (e.g. interruptions, mutexes, flags,...). Thus,every SystemC channel can be implemented in several different ways. This circumstance (onesystem channel - several implementations) might bring certain flexibility for an efficient imple-mentation of interfaces. This might have a strong effect on performance of the system implemen-tation. The described single source approach can be implemented in many different ways. Twoexample will be mentioned here:

#ifdef SYSTEMC#include "systemc.h"#else#define SC_MODULES (name) struct name#endif

SC_MODULE(my_module) {#ifdef SYSTEMCpublic: ...

sc_fifo_out<int> out; // SystemC port ...#else

struct fifo *out; // Port equivalent in C ...#endif};

In this example the SYSTEMC variable declaration generates the SystemC description, otherwisethe C source code is generated by the C preprocessor. The advantage of this approach is that theuse of C compilers ensure a wide availability of crosscompilers to different microprocessors andan efficient binary code.The problem is that it might become very hard to handle the system level specification code be-cause everything has to be defined two times. This problem becomes eliminated in the secondapproach:

#ifdef SYSTEMC#include "systemc.h"#else#include "SC2RTOS.h" // This is the only code modification#endif

SC_MODULE(my_module) { ...

17


sc_fifo_out<int> out; ...};

In this approach the SystemC library elements are replaced by behaviorally equivalent ele-ments of a software implementation library - the SC2RTOS library. This libraryuses a platform RTOS API and defines some C++ supporting structures. Since the support libraryis written in C++ a C++ cross-compiler is needed. Of course this could reduce portability andefficiency, but it simplifies significantly the specification process.During SW generation the meaning of the software-part representation code has to be modified.This modification is performed on library level - so this is out of scope of the system specifac-tion. The implementation library will always declare the same elements, but with a differentSW oriented implementation. It is relatively easy to modify the source because the number ofSystemC elements that have to be redefined is very small. Moreover, the file structure of theSC2RTOS library can be similar to the SystemC structure. This makes it possible to port thelibrary systematically. Figure 3.4 shows the redefined SystemC elements. The specific RTOSfunction that replaces the SystemC constructions depends on the selected RTOS.

Figure 3.4 SystemC Elements to Translate

Since SystemC supports hierarchy (S MODULE and SC CTOR), concurrency(SC THREAD), timed specification (wait(sc time)...) and data types (sc int, sc uint, ...)these features have to be implemented in the specific implementation library. The concurrencysupport for example is realized by mapping the SC THREAD macro to the underlying RTOSthreads.

Doing this also requires some kinds of structures to maintain the process list, where all datanecessary for the management of each process are stored. Figure 3.5 shows the mapping of theSystemC specification onto the RTOS via a SC2RTOS implementation library.To give another example a realization of the timed specificationwill be mentioned here:A SW implementation of this feature can be given by directly programming one of the timers ofthe target system or better to make use of the delay services offered by the underlying RTOS API.

The whole development process - an overview

Since this approach uses a single C++ description for specification and software code compila-tion (the main goal of the single source approach) this methodology has to be extended to supportHW/SW partitioning. This will be described in this subsection. The above Figure 3.6 clearlysummarizes the steps which lead from the first specification to the final embedded system. This

18


Figure 3.5 Concurrency Support of the implementation library

process is divided into three levels: specification, algorithm and generation. The first step is thepure specification in SystemC without taking care about HW/SW partitioning. The specifica-tion is written in C++ including the SystemC library (systenc.h). Compiling and linking of thisspecification code creates a binary file which includes the so called SystemC SimulationKernel. This binary is executable on a standard personal computer. Inputs and outputs are madeover a virtual console. This part is assigned to the specification-level.The second step is to partition the specification into HW and SW parts. This can be done by assignthe specific label (SW or HW) to the define-statement IMPLEMENTATION. The following shortexample clarifies the interrelationship:

#include "SC2RTOS.h"

#define LEVEL GENERATION

// module includes

#define IMPLEMENTATION HW#include "module_abc.h"...

#define IMPLEMENTATION SW#include "module_xyz.h"...

sc_main(...) {

19


// channels instancess_channle<type> ch(..., HW_SW);...

// module instances...

sc_start(-1);}

The parts of the specification which are assigned to software now have to be mapped to an RTOSAPI. The methodology from the above code example might be useful here because they show sim-ple ways to implement this mapping. When the engineer has made a decision of which RTOS hewants to use he has to include the specific SC2RTOS header file into the specification code. Thisdepends on the RTOS which was chosen. Now, it is possible to switch between the SystemCSimulation Kernel and the platform RTOS support. The HW part is still executed withthe SystemC Simulation Kernel (thus, the HW part is still a standard SystemC descrip-tion not affected by the LEVEL value. This part of the process is known as the algorithm-level.Finally, the SW partition has to be fully encapsulated from the HW in order to enable platformcompilation. In this level (also called generation-level) only those specification constructions ofthe SW partition will be compiled for the target platform. Figure 3.6 shows a proposed designflow divided into the three steps described above. More details can be found at [6] [12].

Figure 3.6 Implementation Flow

20


Known Problems

When simulating a designed system in SystemC the so called scheduler handles software- andhardware- threads in the same way because the scheduler cannot decide between different threadpriority - levels. It means that systems with hard real-time constraints requiring an RTOS (Real-Time Operating System) based on a pre-emptive priority-based kernel cannot be modeled natu-rally.

The future of SystemC

Several problems in the software generation have to be solved in future - problems which havebeen mentioned in the above subsection. The development is planed as follows:

1. SystemC 2.x - System design flow

a) Dynamic thread generation - join and fork

b) Specification of time limits and constraints

c) Interfaces, ports and channels

2. SystemC 3.x - Software design flow

a) Modeling realtime operating systems

b) Modeling schedulers

3. SystemC 4.x

a) Modeling of analog/mixed signal systems

21


22

4 Glossary

4.1 General Terms

Co - designWhen there is a close relationship between hardware and software parts and it is necessary dodevelop hard- and software at the same time this process is also called co-design.

Single - Source ApproachIn a single-source approach for the systematic generation of the binary code, the softwaresynthesis step is eliminated and the same specification code is used.

SW codeThe SW code is the source for generating the binary file from.

Cross-CompilerA compiler that runs on one computer but produces object code for a different type of computer.Cross compilers are used to generate software that can run on computers with a new architectureor on special-purpose devices that cannot host their own compilers.

POSIXPortable Operating System for Unix. A standard that defines the language interface betweenthe Unix operating system and application programs through a minimal set of supported functions.

SC2RTOSThe SC2RTOS is a SW implementation library which maps the software parts of the SystemCspecification to a RTOS. RTOS is an acronym for any special Real Time Operating System. Forexample there might be a SW implementation library named SC2eCos.

SystemC simulation kernelExecutes the parts of specification - code which is assigned to the HW-part.

RTOSAn RTOS (Real-Time-Operating-System) is a very useful abstraction interface between appli-cations with hard real-time requirements and the target system architecture. As a consequence,availability of RTOS models is becoming strategic inside HW/SW (hardware/software) co-designenvironments.

APIAPI stands for ”Application Program Interface”. It is the interface for the programmer to extendan existing system with additional functionality - i.e. writing a plug-in or a macro.

PlatformThe methodology is based on defining Platforms at all of the key articulation points in the design

23

4 Glossary

flow. Each platform represents a layer in the design flow for which the underlying, subsequentdesign-flow steps are abstracted.

API - PlatformThe API is the abstraction of a multiplicity of computational resources (concurrency modelprovided by the RTOS) and available peripherals (Device Drivers).

RTOS - APIRTOS is an API - Platform. It is the abbreviation for ”Real-Time-Operating-System ApplicationProgram Interface”.

Architectural platformA hardware platform is a family of architectures satisfying a set of constraints imposed to allowreuse of hardware and software components.

SoCSoC stands for System on Chip. A SoC normally includes microprocessors, memory blocks,peripheral modules and hardware components which implement specific system functions (e.g.time critical processes).

constraint analysisThe environment where the usage of the embedded system takes place has non-functionalrequirements like power consumption and performance. The task of the constraint analysis is todiscover and determine those requirements.

CFSMCFSM is the abbreviation for ”Communicating Finite State Machine”. A CFSM, like a classicalFinite State Machine, transforms a set of inputs into a set of outputs with only a finite amountof internal state. The difference between the two models is that the synchronous communicationmodel of classical concurrent FSMs is replaced in the CFSM model by a finite, non-zero,unbounded reaction time.

Petri netA Petri net is a mathematical representation of discrete distributed systems. Petri nets weredefined in the 1960s by Carl Adam Petri. Because of their ability to express concurrent events,they generalize automate theory.

DFGA data-flow graph (DFG) is a graph which represents a data dependency between a number ofoperations. Any algorithm consists of a number of ordered operations.

CFGA control flow graph (CFG) is an abstract data structure used in compilers. It is an abstractrepresentation of a procedure or program, maintained internally by a compiler. Each node inthe graph represents a basic block, i.e. a straight-line piece of code without any jumps or jumptargets; jump targets start a block, and jumps end a block. Directed edges are used to representjumps in the control flow.

ISA

24

4.1 General Terms

The Instruction Set Architecture is a set of processor instructions/commands of a specificarchitecture.

IPIntellectual Properties - a companies knowledge and development results.

IP-based designIP stands for ”Intellectual Properties”. IP based design is the process of composing a new systemdesign by reusing existing components.

IP - libraryAn IP-library contains patterns of code / specifications which might be useful again.

SystemCSystemC allows system - level specification which integrates SW and HW, performance analysisand verification. Additionally it facilitates the SW analysis and generation.

SWThis is the abbreviation for ”Software”.

HWThis is the abbreviation for ”Hardware”.

TFTimed functional

UTFUntimed functional

RTLRegister transfer level

SchedulerThe scheduler, responsible for determining which thread will run next, manages identically bothsoftware and hardware threads.

target system architectureThe architecture of the destination system (e.g. x86).

ISSThe processor is modeled by an ISS (Instruction Set Simulator) which is represented by aSystemC wrapper.

TLMThe communication between hardware modules and software modules is done through an abstractcommunication protocol using a TLM (Transactional Level Model).

VHDLThis stands for ”‘Very High Speed Integrated Circuit Hardware Description Language”’. VHDL

25

4 Glossary

development was initiated originally from the American Department of Defense (DoD). Theyrequested a language for describing a hardware, which had to be readable for machines andhumans at the same time and strictly forces the developer to write structured and comprehensiblecode, so that the source code itself can serve as a kind of specification document. Most importantwas the concept of concurrency to cope with the parallelism of digital hardware. Sequentialstatements to model very complex functions in a compact form were also allowed. In 1987,VHDL was standardized by the American Institute of Electrical and Electronics Engineers (IEEE)for the first time with the first official update in 1993. Apart from the file handling proceduresthese two versions of the standard are compatible. The standard of the language is described inthe Language Reference Manual (LRM).

Platform Program ModelThis is another term for Application Programmable Interface (API).

26

List of Figures

1.1 Refinement with and without semantical break . . . . . . . . . . . . . . . . . . 41.2 UML description of the module construct . . . . . . . . . . . . . . . . . . . . . 41.3 Moores Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Communicating Finite State Machine (CFSM) . . . . . . . . . . . . . . . . . . 82.2 Petri net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 DFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Classical Co-Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 One interface - many implementations . . . . . . . . . . . . . . . . . . . . . . . 153.3 Platform Based Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 SystemC Elements to Translate . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5 Concurrency Support of the implementation library . . . . . . . . . . . . . . . . 193.6 Implementation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

27

List of Figures

28

Bibliography

[1] Information about Data Flow Graphs. http://bears.ece.ucsb.edu/research-info/dp/dfg.html.

[2] University of Paderborn Germany Carsten Rust (C-LAB) Friedhelm Stappert (C-LAB)Tamas Lukovszki (Heinz Nixdorf Institute). A petri net model for the network layer of amobile ad hoc network architecture.

[3] Haobo Yu Rainer Doemer and Center for Embedded Computer Systems University of Cal-ifornia Irvine Daniel Gajski. Embedded software generation from system level design lan-guages.

[4] The World Encyclopedia. http://www.wikipedia.com.

[5] University of Cantabria Santander Spain Fernando Herrera Victor Fernandez Pablo SanchezEugenio Villar. Embedded software generation from systemc for platform based design.

[6] Cadence Berkeley Labs Grant Martin. Systemc and the future of design languages: Oppor-tunities for users and research.

[7] E. M. Aboulhamid J. Chevalier O. Benny, M. Rondonneau G. Bois and ´Ecole Polytech-nique de Montr´eal Canada F.-R. Boyer Electrical Engineering Department. Space: A hard-ware/software systemc modeling platform including an rtos.

[8] University of Tubingen Germany Joachim Gerlach Wolfgang Rosenstiel. System level designusing the systemc modeling platform.

[9] Alberto Sangiovanni Vincentelli The Edgar L. and Chair of EECS University of Californiaat Berkeley Harold H. Buttner. Platform-based design.

[10] Main page of the SystemC Initiative. http://www.systemc.org.

[11] Software fur Systeme auf Silizium (SSS) Aachen University of Technology Germany Prof.Dr. Rainer Leupers. Entwurf eingebetteter systeme mit systemc.

[12] F. Herrera H. Posadas P. Sanchez and University of Cantabria Santander Spain E. VillarTEISA Dept., E.T.S.I. Industriales y Telecom. Systematic embedded software generationfrom systemc.

[13] Design Systems Inc. Stuart Swan Cadence. An introduction to system level modeling insystemc 2.0.

[14] SystemC tutorial. http://www-ti.informatik.uni-tuebingen.de.

[15] Table with commercial and academic Real Time Operating Systems.http://www.netrino.com/articles/rtoses/.

[16] Department of Computer Zebo Peng Petru Eles and Information Science (IDA)Linkoping University Sweden. Hardware/software co-design.

29

Documents

Embedded Software Generation from SystemC for Platform Based Design