Seminar Embedded Systems (WS 06/07)

SystemC for Embedded System Design

Leopold-Franzens-University of Innsbruck Institute for Informatics

Manuel Lang 30.11.2006

CONTENTS

Contents
1 SystemC Background 1.1 Why another design language? . . . . . . . . . . . . . . . . . . . 1.2 History and Evolution of SystemC . . . . . . . . . . . . . . . . . 1.3 Comparison with other languages . . . . . . . . . . . . . . . . . . 2 Overview of SystemC 2.1 What is SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 SystemC Environment . . . . . . . . . . . . . . . . . . . . . . . . 3 SystemC language Concepts 3.1 Language Architecture . . . . . . . . . 3.2 An Embedded System in SystemC . . 3.3 SystemC Components . . . . . . . . . 3.3.1 Datatypes . . . . . . . . . . . . 3.3.2 Modules and Ports . . . . . . . 3.3.3 Events, Sensitivity, Notication 3.3.4 Processes . . . . . . . . . . . . 3.3.5 Channel and Interfaces . . . . . 3.4 SystemC Renement . . . . . . . . . . 4 Conclusion 3 3 4 4 5 5 5 6 6 6 7 7 8 9 9 9 10 10

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

SYSTEMC BACKGROUND

1
1.1

SystemC Background
Why another design language?

There are Verilog, VHDL and a lot of other languages to implement and simulate hardware. The main driver to introduce a new language, is the increasing design complexity of (embedded)systems. Like Verilog and VHDL, SystemC supports also modeling at register-transfer-level, but the major reason for using it, is to work on a higher abstraction level like TLM. Transaction-Level-Modeling is an intermediate level which is abstract enough to allow complete system architecture design, while beeing accurate enough to allow performance analysis. Figure 1 compares the traditional design-ow with the SystemC design-ow. The SystemC-ow starts with an executable specication in SystemC as base for hard- and software design. This has the benet, that the hard- and softwaremodel exist in a homogeneous environment. It allows stepwise renement of the hardware-design without any language barrier. As shown in the right chart, Hardware-Syntheses could be done directly from SystemC-Code.

Figure 1: HDL/SystemC Design Flow

SystemC addresses increasing complexity of embedded systems with early verication of the entire System. Verication could be done very fast. It promotes early software development, so the software-part is not necessary on the critical-path. SystemC also forwards design reuse and automation. The diagram in Figure 2 presented in [1] emphasizes the importance of SystemCs higher abstraction level. It illustrates the complexity of three sample designs from three generations. Tomorrows systems will exceed one hundred million gates, or one million lines of RTL Code. Writing the code using oldestablished methodologies it could be very impractical.

SYSTEMC BACKGROUND

Figure 2: Design Complexity

1.2

History and Evolution of SystemC

SystemCs rst version (0.9) was released in September 1999, it was cycle-based and modeling was done on RT-Level. Today it has evolved to a complete system design language that includes hard- and software concepts, the evolution-process is still going on. Early Development was done by Synopsys,UC Irvine and CoWare. 2000 the Open SystemC Initiative (OSCI) was founded. 2005 SystemC becomes a IEEEstandard. These days SystemC is sustained by a big still growing community. It is under the Open Community License, available on [4].

1.3

Comparison with other languages

SystemC is not the perfect solution for all tasks, but it combines many design characteristics that are missing in other language. Figure 3 published in [1] compares the operational area of some design languages.

Figure 3: Language Comparison

OVERVIEW OF SYSTEMC

2
2.1

Overview of SystemC
What is SystemC

Strictly SystemC is not a language, its a class library written in C++ plus a simulation kernel. SystemC builds the bridge between hard- and software design. It extends C++ with macros, functions and other constructs to allow a hardware-oriented design. SystemC enhances C++ with a notion of time which is essential for simulationpurposes. To master the inherently concurrency of todays embedded-systems, it provides parallel execution within the simulator. Some new hardware data types are introduced. It also provides a stable platform for development of system-level tools.

2.2

SystemC Environment

Figure 4 shows the SystemC development environment. It uses the tools, well known from normal software development with C++ and includes following components: SystemC-supported platform like Linux SystemC-supported C++ compiler like g++ SystemC library make le or something else

Figure 4: SystemC Environment

At the end of the compilation ow you get an executable le, containing the simulation kernel and the design functionality. From SystemC it is also possible to produce trace-les for wave-form illustration.

SYSTEMC LANGUAGE CONCEPTS

3
3.1

SystemC language Concepts

Language Architecture

Figure 5 illustrates the SystemC architecture, the green shaded blocks are part of the SystemC core language standard. The blue part on the top of the architecture consists of design libraries and standards, they are separate from the core language. Lower layers can be used without upper layers. Upper layers are built clean on lower layers. Over time other methodology specic libraries may be added and incorporated into the core language.

Figure 5: SystemC 2.0 Architecture

The base of the core language consists of an event driven simulator. It works with events and processes. Modules and Ports are used to represent the structure of a design. Interfaces and channels are used to describe the communication. The library provides a set of data types needed for hardware modeling. The core specication contains some frequently used built-in primitives like signals and FIFOs. A deeper functionality of the mentioned SystemC-components is explained under 3.3.

3.2

An Embedded System in SystemC

Figure 6 shows the hierarchical structure of a typical system, designed with SystemC. SystemC provides a lot of concepts to break down hierarchically to manage complexity. A Module is used as the main entity to model hardware hierarchies. Modules are connected to other modules using channels.

SYSTEMC LANGUAGE CONCEPTS

Channels provide a powerful method to manage the communication. They could model a very simple communication, or represent complex schemes like a special bus. Channels are specied by the interfaces, witch they implement them. Finally, modules connect to channels via ports. A port is bound to an interface. It is the object through which modules, and its processes, can access the methods of a channel.

Figure 6: Hierarchical Structure of a System Design

To simulate concurrency SystemC uses the concept of processes explained under 3.3.4. Like other hardware description languages (Verilog, VHDL. . . ) SystemC provides a simulation kernel that switches between the dierent concurrent processes. The simulation code itself determines this switches by the use of events.

3.3
3.3.1

SystemC Components
Datatypes

Beside the native C++ data types, SystemC denes a number of data types to support the hardware design. The decision for a special data type is driven by the range of values to represent, required precision, required operations. Choosing the right data type is important, because it aects speed of simulation and the synthesizability. List of common data types: sc bit boolean bit (0 and 1) sc logic multi-value data type (i.e. tri-state) sc int<n> integer with xed bit-length sc bv<n> boolean Bit-vector of length n sc lv<n> multi-value Bit-vector of length n

SYSTEMC LANGUAGE CONCEPTS

Listing 1: Simple Adder Module, using a thread process to compute the result
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 SC MODULE( Adder ) { // d e c l a r e some p o r t s s c i n <i n t> a ; s c i n <i n t> b ; s c o u t <i n t> c ;

sc event

event1 ;

// member f u n c t i o n o f m o d u l e void compute ( ) { wh i l e ( t r u e ) { c = a + b; wait ( ) ; // s u s p e n d p r o z e s s // w a i t ( e v e n t 2 | e v e n t 3 ) ; // s u s p e n d w i t h dynamic s e n s i t i v i t y // s u s p e n d f o r a s p e c i f i c t i m e / / w a i t ( 7 5 , SC NS ) ; / / w a i t ( e v e n t 3 , 7 5 , SC NS ) ; / / s u s p e n d a n d r e a c t i v a t e w i t h e v e n t 3 event1 . n o t i f y ; } } SC CTOR( Adder ) { / / map m e m b e r f u n c t i o n SC THREAD( compute ) ; to thread process , registering with scheduler // f i r e an event

or

after

specified

time

// p r o c e s s i s s t a t i c s e n s i t i v e // a d e f a u l t e v e n t i s f i r e d on sensitive < < a < < b; }

t o hw s i g n a l s s i g n a l change

on

input

ports ,

3.3.2

Modules and Ports

As shown in Fig. 6 components often contain hierarchies of smaller components. The smallest components represent the behavior. SystemC uses the SC MODULE macro to declare a module-class. SC MODULE( module name ) { MODULE BODY } SC MODULE macro: #define SC MODULE( module name ) struct module name : public s c m o d u l e The following elements make up the module-body: ports, member channel instances, member data instances, member module instances, constructor, destructor, processes and helper functions. Ports are proxy objects which are bound to channels through interfaces (3.3.5). Modules communicate with their surroundings through ports. Port declaration using a read-write-interface: s c p o r t <s c s i g n a l i n o u t i f <int>> r w p o r t ; // same w i t h p r e d e f i n e d s y n t a x s c o u t <int> r w p o r t ;

SYSTEMC LANGUAGE CONCEPTS

3.3.3

Events, Sensitivity, Notication

SystemC uses the sc event class to model events. Events are the key elements for an event driven simulator. An event has no duration or time. With an event you can perform only two actions: wait (Listing 1 line 16-20) for it or re (Listing 1 line 22) it. So an event is the main tool to synchronize between dierent processes. A process could be declared sensitive to one or more events (Listing 1 line 18-20, 33). If the event(s) occur, the simulation kernel starts with the execution of the sensitive processes. 3.3.4 Processes

As with most event driven simulators, concurrency is not true concurrent execution. Each process in the design executes a small piece of code and than releases control to an other process, in the same simulated time space (quasi-parallelism). SystemC provides two major process types, SC THREAD and SC PROCESS. SC THREAD: A thread is started only once by the simulator, therefore it typically contains an innite loop, containing at least one wait-method. After a thread starts its execution, it could be suspended with the wait-method, to return the control back to the simulation-kernel. (Listing 1 shows a simple example using thread process) SC METHOD: In dierence to a SC THREAD, a SC METHOD process could not suspend itself, it runs completely and returns. SC METHOD is less expressive than SC THREAD, but allows faster simulation. 3.3.5 Channel and Interfaces

Signals are sucient to describe connections in Hardware design, but to describe whole systems, more complex connections like delayed, buered, disturbed connections, software connections RMI, RPC and others are needed. As mentioned earlier a Channel implements the methods described by an interface. Channels are used for communication between processes inside modules and between modules. We distinguish two dierent types of channels primitive and hierarchical ones. Primitive channels: They cannot contain processes or connect directly to other primitive channels. sc signal sc fo sc mutex sc semaphore sc buer

CONCLUSION

10

Hierarchical channels: They could model very complex communications, because they are still modules they dont have the above mentioned restrictions. With hierarchical channels its possible to model the underlying structure of a communication.

3.4

SystemC Renement

Hierarchical channels and the interface concept forward a very powerful renement strategy. It is easy to replace a channel with an other one, they only have to share the same interfaces. Inserting an adapter channel is also a common way to specialize a given design.

Conclusion

After seven years of development SystemC has become a very expressive language. It allows fast and ecient design of system architectures on a high level. Today a lot of companies use SystemC instead of C/C++ environments to model their systems. The Language is developed continuously by the OSCIWorkin-Groups. Additionally other subsets improve the interfaces to simulators and the test-bench support.

REFERENCES

11

References
[1] David C. Black, Jack Donovan: SystemC from the ground up. 2004 [2] Thorsten Groetker, Stan Liao, Grant Martin, Stuart Swan: System Design with SystemC. 2002 [3] Frank Ghenassia: Transaction-Level Modeling with SystemC TLM Concepts and Applications for Embedded Systems. 2005 [4] OSCI website available under: www.systemc.org [5] ESLX Electronic www.eslx.com System Level Xperts website available under: