Chapter 1: SystemC, Joined design at system level

(based on SystemC 2.2)

B. Miramond M2 S2IC/ESA

B. Miramond - UCP

Plan du chapitre
I. II. III. IV. Introduction Programmer en SystemC Noyau de simulation Niveaux dabstraction : une mthodologie de conception VI. Modlisation matrielle en SystemC VII. Modlisation TLM VIII. Concepts avancs (30min) (1h30) (1h) (30min) (30min) (1h) (30min)

B. Miramond - UCP

I.

SystemC What else ?

B. Miramond - UCP

Plan de la section I
1. 2. 3. 4. 5. 6.

Motivations Historique Quest ce que SystemC Les concurrents Les librairies SystemC Quelques dfinitions pour dmarrer

B. Miramond - UCP

1) Motivations

Changement dchelle : conception de systmes sur puce. Sur des technos plus anciennes, la conception reliait un microprocesseur, une mmoire et un ASIC (acclrateurs matriels). Des experts ralisaient alors le partitionnement de lapplication entre les parties logicielles et matrielles. Pour la partie Hw, la spcification des ASICs correspondait qqs milliers de portes. Ce qui restait exprimable dans un langage HDL un niveau RTL.

RTL : Register Transfer Level

B. Miramond - UCP

Register Tranfer Level A legacy from HDL

RTL description is a way of describing the operation of a synchronous digital circuit. In RTL design, a circuit's behavior is defined in terms of the flow of signals (or transfer of data) between hardware registers, and the logical operations performed on those signals.
Vhdl process(clk) begin if rising_edge(clk) then Q <= not Q; end if; end process;

The term refers to the fact that RTL focuses on describing the flow of signals between registers
B. Miramond - UCP

Et maintenant

Aujourdhui, la technologie des SoCs autorise la prsence de

plusieurs proc., microcontrleurs 32 bits ou DSP. On-chip memory Acclrateurs matriels pour fonctions ddies Contrleurs de priphriques Le tout reli par un rseau complexe de communication.

A ce niveau de complexit, le partitionnement nest plus vident entre logiciel et matriel. La conception matrielle sexprime en millions de portes.
B. Miramond - UCP

SoC Architecture
Debug port JTAG ARM 946E core ICache DCache HW coprocessor RISC core DMA Controler Boot ROM SDRAM/Flash Multiport memory

Arbiter Bridge

Timer Arbiter

UART RAM DSP ADC/DAC

B. Miramond - UCP

Conception cost evolution

[Roadmap for Semiconductors 2001]
IC Implementatrion Small block Reuse Intelligent Testbecnh

Conception cost
Small thin Eng. In House P&R Large block Reuse $ 100.000.000.000

System Level Methodology

predicted

$ 10.000.000.000

measured
$ 1.000.000.000

$ 100.000.000

$ 10.000.000 1985 1990 1995 2000 B. Miramond - UCP 2005 2010 2015 2020

Conception niveau systme

La prise de dcision de limplantation est repousse car elle doit tre explore. Donc, pour dcrire des systmes encore la fois logiciels et matriels il faut aller au-del du niveau RTL, et ce niveau les HDLs ne sont plus adapts. On parle de conception au niveau systme. Et du besoin de langage de modlisation supportant ce niveau.
B. Miramond - UCP

2) Positionnement du langage
Requirements Specifications HW/SW Behavior Functional Verification Test bench RTL Gates Transistor
B. Miramond - UCP

Matlab, SPW, S. Studio

SystemC System Verilog

Verilog

VHDL

Objectifs

Environnement unifi de description matriel et logiciel Explorer les solutions de conception en travaillant un niveau systme

=> Amliorer la productivit des concepteurs de systmes lectroniques.

B. Miramond - UCP

3) Donc quest ce que SystemC ?

SystemC est un langage de modlisation au niveau systme

Rseau de processus communiquant (HDL) Supportant diffrents modles de traitements (MoCs) Permettant de modliser des systmes logiciels et matriels

Cest aussi un environnement de simulation temporelle (eventdriven simulation, cf. HDL). Bas sur une librairie de classes C++

Open Source

SystemC nest pas une mthodologie, mais vous avez besoin dune mthodologie pour lutiliser !
B. Miramond - UCP

Mthodologie de conception
Spcifications

Software (C/C++)

Modle TLM

Environnement de test (SystemC)

Cosimulation

Modle RTL (HDL/SystemC) Synthse Portes Layout

Software

Hardware B. Miramond - UCP

Testbench

Quelques dfinitions

Niveau dabstraction = est un niveau de description dun systme apportant un niveau de dtails donnes. Un flot de conception est une succession de niveaux dabstraction. Raffinement = Le raffinement est le mcanisme permettant de passer dun niveau dabstraction un autre. Celui-ci doit tre le plus possible automatisable. Spcification excutable = est un modle fonctionnel qui fournit le comportement dun composant quelque soit le niveau dabstraction et de manire indpendante de limplmentation (plateforme).
B. Miramond - UCP

Caractristiques du langage SystemC

1. 2. 3. 4. 5. 6.

Spcification et conception diffrents niveaux dabstraction Intgration de portions de logiciel embarqu, la fois sous la forme de modles et de code : rutilisation, Cration de spcification excutables. Cration de plateformes excutables sur lesquelles seront mappes les spcifications. Simulations rapides pour permettre lexploration de lespace de conception (spcifications + plateformes) Structuration des modles autorisant la sparation de la fonctionnalit et de la communication

Adaptation flexible (IPs) Besoin de rutilisation

B. Miramond - UCP

Proprits supplmentaires

Bas sur un langage de programmation existant pour bnficier des outils de compilation, de debug, Un langage orient objet fournirait les mcanismes de base pour la flexibilit des modles et la rutilisation. (hritage, templates)

B. Miramond - UCP

4) Historique
Synopsys- SCENIC IMEC CoWare N2C Master-Slave Lib Channels Bug fix Dynamic Processes RTOS / Software SystemC 1.0 SystemC 1.2.1 Beta SystemC 2.0 SystemC 2.0.1 SystemC 2.1 puis 2.2 SystemC 3.0 B. Miramond - UCP LWG / OSCI Adelante AJRT Lib Fixed Point Types

Future

4) Les concurrents
Sur le crneau de la modlisation niveau systme : SpecC D. Gajski de lUniversit de Irvine

http://www.ics.uci.edu/~specc/ http://www.imec.be/design/ocapi/unified_design.shtml http://www.forteds.com/technology/esl2gdsii.asp

OCAPI - IMEC

Cynlib CynApps

B. Miramond - UCP

5) Librairies SystemC (sup.)

The SystemC Verification Library (SCV)

Ajoute de fonctionnalits pour la vrification des design (Cadence) Langage de dveloppement de testbench (Testbuilder) Constrained randomization, introspection, transaction recording http://www.testbuilder.net Extension de SystemC pour la description de processeurs http://www.archc.org Protocole de communication http://www.systemc.org Free peer-reviewed portable C++ source libraries http://www.boost.org
B. Miramond - UCP

Architecture Description Language : ArchC

Master/Slave library

The Boost Library (C++)

Bibliographie
Books System Design with SystemC (4th edition), Grtker et al., Kluwer Academic Publisher, 2004

Ensea, emprunt Bib. Ensea, dispo Bib. Ensea, dispo

From the ground-up (SystemC 2.1), D. Black & J. Donovan, Kluwer Academic Publisher, 2005

Transaction level modeling with SystemC : TLM concepts and applications for embedded systems, by Frank Ghenassia, Springer 2005.

SystemC kernel extensions for heterogeneous system modeling : a framework for Multi-MoC modeling & simulation, by Hiren D. Patel and Sandeep K. Shukla, 2004

Ensea, dispo

Weblinks http://www.systemc.org
B. Miramond - UCP

I. Programmer en SystemC

B. Miramond - UCP

Plan de partie II
1. 2.
1.

Architecture du langage Les structures

sc_module

1.

Sensibilit
1. 2. 3. 4.

3.
1. 2. 3. 4.

Ports, Channels et Interfaces

Port Channels Interfaces Hierarchical Channels

Statique Dynamique Composition dvnements Timeout

2. 3. 4.

4. 5.
1. 2.

Processus vnements
sc_events notification

Exemple de synthse Quelques exemples supplmentaires Debugging

1. 2. 3. 4.

Debug Environnement Testbench results Waveform tracing Resulting waveforms

B. Miramond - UCP

1. Architecture du langage

http://www.systemc.org

Librairies SystemC tlchargeables gratuitement http://www-ti.informatik.uni-tuebingen.de/~systemc

European SystemC Users Group

B. Miramond - UCP

Standard Channels
Kahn Process Network, Static Dataflow, Etc.

Methodology Specific Libraries

Master/Slave Library, etc.

Elementary Channels
Signal, Timer, Mutex, FIFO

Core Language
Modules Ports Processes Events Interfaces Channels

Data-Types

4-valued logic types (O1XZ) 4valued logic vectors Bits and bit-vectors Arbitrary-precision integers Fixed point numbers C++ user-defined types

Event-driven simulation Kernel C++ Language Standard

B. Miramond - UCP

Architecture de SystemC
User Applications
Standard Channels
Kahn Process Network, Static Dataflow, Dataflow, Etc.

Methodology Specific Libraries

Master/Slave Library, etc.

Elementary Channels
Signal, Timer, Mutex, FIFO

Core Language
Modules Ports Processes Events Interfaces Channels

Data-Types
4-valued logic types (O1XZ) 4valued logic vectors Bits and bit-vectors Arbitrary-precision integers Fixed point numbers C++ user-defined types

SystemC Standard

Event-driven simulation Kernel C++ Language Standard

WorkStation Environment
B. Miramond - UCP

Compilation dun projet SystemC

g++ -I$ (SYSTEMC) /include \ -L$ (SYSTEMC) /lib-$ (ARCH) lsystemc \ $(SRC) systemc
STL

Le rsultat contient la fois votre code applicatif et le code de la machine de simulation SystemC !!
File1.h File1.cpp Filen.h Filen.cpp systemc.h File1.o Filen.o

g++

ld

.exe

B. Miramond - UCP

2. Structures
Processes (Concurrency) Modules (Structure) Channels (Communication) Events (time, Spares synchronisation) Port (Structure) Fonctionnalit Communication Interfaces (Communication Data types (Hardware, / Traitement refinement) fixed point)

Port Module Process 1 Channel Interface

B. Miramond - UCP

Module P2

P3

a. Modules

sc_module

Un module est un conteneur (container). Il contient :

Des ports qui permettent de communiquer avec dautres modules Des processus qui dcrivent la fonctionnalit du module Des donnes internes reprsentant ltat et des canaux internes pour la communication entre les processus du module Et hirarchiquement, dautres modules

B. Miramond - UCP

Dclaration par la macro SC_MODULE

class Adder : public sc_module { // Ports, processes, internal data Adder (sc_module_name name, int other_param) : sc_module(name){ // Body of constructor : // Process declaration, sensitivities } };

Cette dclaration cre une nouvelle classe dobjets de type Adder. Les dfinition sont ralises dans des fichier .CPP. Les dclaration dans des fichiers .H
B. Miramond - UCP

Instanciation de SC_MODULE
Les SC_MODULE peuvent tre instancis lors de la phase dlaboration uniquement (cf. section III) En prcisant un nom de module Avec la syntaxe suivante : Adder MyAdder(MyAdder);

B. Miramond - UCP

3. Interfaces, Ports et channels

En modlisation matriel classique (RTL), le signal est le moyen de communication entre processus. Au niveau systme, le moyen de communication na pas encore dimplantation tablie (bus Hw, appel de service logiciel comme FIFO, mutex). SystemC offre cette flexibilit par la sparation entre

Les canaux qui sont le moyen de transmission des donnes Les interfaces qui fournissent les prototypes des services daccs au canal Les ports qui sont une instanciation des interfaces dans un module client.
B. Miramond - UCP

a. Interfaces

Un canal exporte son interface travers la classe abstraite sc_interface. Linterface spcifie donc uniquement la signature (le prototype) des oprations/services fournies par son canal.

Rappel : Les sc_interface sont des classes templates C++. Une classe template permet de paramtrer le type des donnes quelle manipule en placant le type entre <T>.
B. Miramond - UCP

Exemple
sc_signal_in_if<T> Drive directement de sc_interface et est paramtre par le type T. Elle ne fournit quun seul service : read() qui retourne une rfrence la valeur de type T. sc_signal_inout_if<T> Celle-ci fournit en plus une fonction virtuelle write() qui prend en paramtre la valeur placer. Cette seconde interface drive de sc_signal_in_if et hrite donc de la fonction read().

B. Miramond - UCP

sc_interface register_port()
(virtual)

sc_signal_in_if<T> read() sc_signal_inout_if<T> write()

B. Miramond - UCP

class sc_signal_in_if : virtual public sc_interface { public : virtual const T& read() = 0; }

sc_signal est utilis pour la communication lintrieur dun module entre processus.

Built-in primitive Channels

sc_signal<int> S1, S2; sc_buffer<T> B; sc_fifo<T> F; sc_mutex M; sc_semaphore P(1); S1.write(S2.read());

B. Miramond - UCP

// dclaration

// Affectation

b. Ports

Les ports sont utiliss comme dclaration de connexion un canal via son interface. La dclaration doit spcifier linterface laquelle il correspond. Dclaration

sc_port<sc_signal_inout_if<int> > p; p->read(); p->write();

Ceci est un exemple dIMC (Interface Method Call).

B. Miramond - UCP

Ports prdfinis dans SystemC

Template <class T> class sc_in : public sc_port<sc_signal_in_if<T> > ; Template <class T> class sc_inout : public sc_port<sc_signal_inout_if<T> > ;
B. Miramond - UCP

Exemple (suite)
class Adder : public sc_module { // Ports, processes, internal data sc_in <int> a; sc_in <int> b; sc_in <int> c; Adder (sc_module_name name, int other_param) : sc_module(name){ // Body of constructor : // Process declaration, sensitivities } };

Adder

La dclaration des ports doit intervenir en premier dans le module!! Et lordre a une importance.

B. Miramond - UCP

c. Channels

sc_channel

Alors que les ports et interfaces dfinissent quelles fonctions sont disponibles, le canal dcrit limplmentation de ces fonctions. Tous les canaux hritent de sc_prime_channel. La classe canal doit grer les accs multiples (tel que sur un bus). Ses mthodes daccs suivent un schma dit : Request-Update
B. Miramond - UCP

d. Hierarchical Channels

Plusieurs canaux peuvent implmenter la mme interface. Ainsi, un primitive channel ne contient pas dautres structures SystemC (modules, process). Au contraire, il est parfois ncessaire de modliser des structures de communication plus complexes :

Le standard OCB = On-Chip Bus de VSIA : Arbitrer Control Program Unit Decoder Unit

Lavantage des ports et interfaces est donc clair, ils permettent de dcoupler linterface de son implmentation et donc de raffiner les communications (par ex.) dun B. Miramond - UCP un canal hirarchique. canal simple

4. Processus

Process

La nature parallle des systmes lectronique ncessite la description de fonctionnalits concurrentes. A process SystemC doit tre contenu dans un module. Le code associ au process doit tre une fonction membre du SC_MODULE Les processus accdent aux canaux extrieurs par lintermdiaire des ports de leur module.
B. Miramond - UCP

Exemple (suite)
class Adder : public sc_module { // Ports, processes, internal data sc_in <int> a; sc_in <int> b; sc_out<int> c;

Adder

void compute (){ c = a + b; } SC_HAS_PROCESS(Adder); Adder (sc_module_name name, int other_param) : sc_module(name){ // Process declaration, sensitivities SC_METHOD(compute); sensitive << a << b; } };
B. Miramond - UCP

Piges

Le fait de dclarer une nouvelle mthode dans un SC_MODULE ne fait pas delle un process. Cest lappel SC_METHOD qui enregistre la mthode en paramtre auprs du scheduler de SystemC. Cet enregistrement (lappel SC_METHOD) ne peut tre fait qu la phase dlaboration, pas pendant la simulation. Les SC_METHOD ne peuvent tre intrrompus, il ne doivent donc pas contenir de boucle infinies !!
B. Miramond - UCP

Plusieurs sortes de process

SC_METHOD()

Processus ne pouvant tre interrompus (ils ne peuvent appel wait()) Le code doit tre fonction membre dun SC_MODULE Le plus rapide la simulation. Processus pouvant tre interrompus (par wait) Ses variables sont persistantes (contrairement au SC_METHOD) Le code nest pas ncessairement fonction membre du module Autorise la cration dynamique de processus, donc aprs la phase dlaboration. Le code nest pas ncessairement fonction membre du module

SC_THREAD()

sc_spawn() // cf. Chapitres suivants

B. Miramond - UCP

Structure of a process
SC_METHOD : simulation engine call them repeatedly void my_process (){ // run to completion scheme // treatment } SC_THREAD : void my_thread(){ // infinite loop scheme while (1){ // treatment wait(); // static event } }

B. Miramond - UCP

5. Events

Un processus dispose dune liste de sensibilit dcrivant les vnements auxquels il doit ragir. Lorsque lexcution dun processus rencontre un wait(), il est interrompu. Il attend le dclenchement (implicite) dun des vnements de sa liste de sensibilit statique. Lorsquun de ses vnements est dclench, le scheduler place le Thread dans la liste des processus READY.
B. Miramond - UCP

a. sc_event

Un event est un objet de classe sc_event.

sc_event e;

Il na ni dure, ni valeur. Lacte dindiquer une modification dun vnement est appel notification.

e.notify(); notify(e);

Lvnement garde une liste des processus qui lui sont sensibles (par wait(e)). Lorsque un event est notifi, il informe le scheduler des processus (re)lancer.
B. Miramond - UCP

b. Notification

Immediate : e.notify();

Notification immdiate, le processus en attente est replac immdiatement dans la liste Ready Notification aprs un cycle dvaluation appel Delta-cycle, lorsque tous les processus en attente se seront excuts. Place lvnement en fil dattente jusqu la dure indique.
B. Miramond - UCP

Delta_delay : e.notify(SC_ZERO_TIME);

Non-zero delay : e.notify(t);

6. Sensitivity

a. Sensibilit statique =

La liste des vnements dactivation dun process est dtermin avant la simulation (dans les constructeurs). sensitive << a << b; Permet de remplacer la liste statique par un vnement dsign lors de la simulation. Le processus nest alors plus sensible aux vnements de sa liste statique. wait(e);
B. Miramond - UCP

b. Sensibilit dynamique =

Exemple (suite)
class Adder : public sc_module { // Ports, processes, internal data sc_in <int> a; sc_in <int> b; sc_out<int> c;

Adder

Cas particulier : Ici a et b sont des sc_ports. void compute (){ La sensibilit se fait par c = a + b; lintrmdiaire de la } fonction default_event SC_HAS_PROCESS(Adder); associe. Adder (sc_module_name name) : sc_module(name){
// Process declaration, sensitivities SC_METHOD(compute); sensitive << a << b; } };
B. Miramond - UCP

c. Composition dvnements

Conjonction :

wait (e1 & e2 & e3); ou wait (timeout | e1 | e2); Activation si les 3 event sont dclenchs

Disjonction :

wait(e1 | e2 | e3); ou wait (timeout | e1 | e2); Activation si 1 des 3 event est dclench ou bien un timeout Il nest pas possible de savoir quel vnement a provoqu le dclenchement. Par contre il est possible de savoir si cest le timeout :

wait(t_Delay | ack_event | bus_error_event); if (timed_out()) // action associated to timeout

B. Miramond - UCP

d. Attente dun TimeOut

Attente de 200 nanosecondes :

wait(200, SC_NS); Ou bien sc_time t(200, SC_NS); wait(t);

Attente dun Delta-cycle :

wait(0); wait(200, SC_NS, e);

B. Miramond - UCP

Combinaisons event(s) | timeout:

7. Final Example

A la manire des classes et des objets, les modles sont opposs aux instances (de modules et de canaux) en SystemC comme en HDL. Exemple hirarchique :
in1 in2 in3
Adder1

sum
Adder2

Add3
B. Miramond - UCP

class Add3 : public sc_module { sc_in<int> in1; sc_in<int> in2; sc_in<int> in3; sc_out<int> sum;
// signal (channel) interne

in1 in2 in3

Adder1

temp

sum
Adder2

Add3

sc_signal<int> Adder* adder1; Adder* adder2;

temp;

Add3(sc_name name) : sc_module(name){ adder 1 = new Adder(Adder1); (*adder1)(in1, in2, temp); // Connectique forme positionnelle adder 2 = new Adder(Adder2); adder2->a(temp); adder2->c(sum); adder2->b(in3); } }
B. Miramond - UCP

// Connectique forme nomme // Pas dordre impos

int sc_main(int argc, char* argv[]){ // initialisation // simulation top_level(); // Nettoyage des structures return 0; } top_level(){ sc_signal <int> sig_a, sig_b, sig_c; Add3 my_adder(my_adder); //Autres modules et tesbenchs qui positionnent // les valeurs de sig_a et sig_b

temp
in1 in2 in3
Adder1

sum
Adder2

Add3

//Lance la phase dElaboration puis celle de Simulation //Excution durant 1000 secondes (de temps de simulation) sc_start(1000, SC_SEC); //Suite de la simulation pendant 100 ms sc_start(100, SC_MS); }
B. Miramond - UCP

8. Debugging
#include systemc.h Class nand2 : public sc_module { sc_port<sc_signal_in_if<bool>, 1> A; sc_in<bool> B; sc_out<bool> F; void do_nand2(){ F.write( !(A.read() && b.read()) ); } SC_HAS_PROCESS(nand2); nand2 (sc_name name) : sc_module(name){ // Constructor SC_METHOD(do_nand2);// register do_nand2 with scheduler sensitive << A << B; } };
B. Miramond - UCP

//input signal port //other writing //output signal port

2-input xor
F = A B = ( A + B).( A + B )
A S2 F S1 S3

B. Miramond - UCP

#include systemc.h #include nand2.h

xor2(sc_name name) : n1(N1), n2(N2), n3(N3), n4(N4) class xor2 : public sc_module { { n1.A(A); sc_in<bool> A, B; n1.B(B); sc_out<bool> F; n1.F(S1); nand2 n1, n2, n3, n4; sc_signal<bool> S1, S2, S3;
A S2 F S1 S3

(*n2)(A, S1, S2); n3.A(S1); n3.B(B); n3.F(S3); n4.A(S2); n4.B(S3); n4.F(F);

} };
B. Miramond - UCP

a. Debug Environnement
A S2

xor2
F S1 S3

Stimuli Generator
B

Monitor
B CK

Clock
B. Miramond - UCP

#include systemc.h class stim : public sc_module{ sc_out<bool> A, B; sc_in_clk Clk; void StimGen(){ A.write(false); B.write(false); wait(); A.write(false); B.write(true); wait(); A.write(true); B.write(false); wait(); A.write(true); B.write(true); wait(); sc_stop(); } SC_HAS_PROCESS(stim); stim(sc_name name) : sc_module(name){ SC_THREAD(StimGen); sensitive << Clk.pos(); } };

#include systemc.h #include <iomanip.h> class monitor : public sc_module{ sc_in<bool> A,B, F; sc_in<bool> Clk; void do_monitor(){ cout << setw(10) << time; cout << setw(2) << A; // while(true){ cout << setw(10) << sc_time_stamp(); cout << setw(2) << A.read(); // wait(); } } SC_HAS_PROCESS(monitor); monitor(sc_name name) : sc_module(name){ SC_THREAD(monitor): sensitive << Clk.pos(); } };
B. Miramond - UCP

b. Testbench results
#include systemc.h #include stim.h #include exor2.h #include mon.h int sc_main (){ sc_signal<bool> ASig, BSig, FSig; sc_clock TestClk(TestCk, 10, SC_NS, 0,5); stim Stim1(Stimulus); exor2 DUT(exor2); monitor Monitor1(Monitor); // Connection with ASig, BSig et FSig sc_start(); // run forever return 0; }
B. Miramond - UCP

Time A B F ,,,,,,1 ns 0 0 0 11 ns 0 0 0 21 ns 0 1 1 31 ns 1 0 1 41 ns 1 1 0

#include systemc.h #include stim.h #include exor2.h #include mon.h int sc_main(int argc, char *argv[]){ sc_signal<bool> ASig, BSig, FSig; sc_clock TestClk(TestClock, 10, SC_NS, 0,5, 1, SC_NS); instance of stim exor2 DUT(exor2); DUT.A(ASig); DUT.B(BSig); DUT.F(FSig); instance of monitor sc_trace_file* Tf; Tf = sc_create_vcd_trace_file(traces); Tf->set_time_unit(1, SC_NS);
//deprecated : //((vcd_trace_file*)Tf)->sc_set_vcd_time_unit(-9);

c. Waveform tracing
Declare the trace Create trace file (optional : specify the trace time unit) Register signals or variables for tracing (even hierarchically : DUT.S1) // DUT = Design Under Test

sc_trace(Tf, ASig, A); sc_trace(Tf, BSig, B); sc_trace(Tf, FSig, F); sc_trace(Tf, DUT.S1, S1); sc_trace(Tf, DUT.S2, S2); sc_trace(Tf, DUT.S3, S3); sc_start(); sc_close_vcd_trace_file(Tf); return 0;

Run the simulation Close the trace file

B. Miramond - UCP

d. Resulting waveforms

B. Miramond - UCP

III. Simulation Kernel

B. Miramond - UCP

Concurrence simule

Lobjectif du scheduler SystemC est de simuler lexcution parallle de la plateforme matrielle dcrite bien que la simulation tourne sur une station de travail mono-processeur. La concurrence simule en SystemC nest pas premptive, cest le code de chaque processus qui redonne la main au scheduler (wait).

B. Miramond - UCP

Section organisation
1. 2. 3.
1. 2. 3. 4. 5. 6.

Time management SystemC scheduler SystemC scheduling steps

Delayed notification Timed notification Immediate notification Simulation steps synthesis Dont_intialize ! Ending simuation

4. 5.
1. 2. 3.

The case of Channels : Evaluate-update Concurrency and time

Perceived concurrency Zero-time execution Scheduled concurrency

6.

Event-driven simulators (not yet)

B. Miramond - UCP

1. Gestion du temps a) sc_time

Le simulateur SystemC est discret. Il utilise un quantum de temps minimal qui peut tre dfinit par sc_set_time_resolution(int, sc_time_unit) Par dfaut, la plus petite rsolution du temps est 1 picoseconde (10-12s) SystemC dfinit un type numr des units de temps, sc_time_unit :

SC_FS SC_PS SC_NS SC_US SC_MS SC_SEC

femtoseconde picoseonde nanoseconde microseconde milliseconde

(10-15s) (10-12s) (10-9s) (10-6s) (10-3s)

Default

B. Miramond - UCP

SC_TIME
sc_time est le type utilis pour dclarer des variables de temps Dclaration : sc_time t1(42, SC_PS);

sc_time sc_time_stamp()

retourne le temps courant de simulation double sc_simulation_time() retourne le temps courant de simulation en unit de temps par dfaut
B. Miramond - UCP

b) Dclaration dhorloges : sc_clock

Utilises pour la synchronisation Les arguments sont :

Un label, La priode de lhorloge : valeur + unit Le temps pass ltat haut La date du premier front Et un boolen indiquant si le premier front est montant ou descendant.

sc_clock(Clk, 1, SC_NS); sc_clock(Clk, 1, SC_NS, 0.5, 0, SC_NS, true);

B. Miramond - UCP

Services de lhorloge

En SystemC les horloges sont des canaux hirarchiques, Ils offrent les services suivants : period(); // returns sc_time duty_cycle(); // returns a double (fraction of the period) posedge(); // returns a reference to the positive clock edge; negedge(); // negative read(); // return the current value event(); // detects if there has been a change on clock posedge_event(); // returns an event notification for pos clock edge negedge_event(); // returns an event notification for neg clock edge B. Miramond - UCP

Ports ddis

Un module peut utiliser les ports ddis de lhorloge pour pouvoir tre synchrone :
sc_in_clock sc_out_clock sc_inout_clock

Les horloges ne sont lances quaprs lappel sc_start()

Ce ne sont rien de plus que des sc_in<bool> Mais ils fournissent les mthodes pos() et neg() qui font appel pos_edge_event() et neg_edge_event()
B. Miramond - UCP

2. Scheduler SystemC

Le squencement des opration ralis par SystemC est

Dterministe : lordre des oprations sera toujours le mme dans les mme conditions Mais lutilisateur na pas de moyen de connatre ce squencement lavance Il est donc dconseill de faire communiquer 2 processus par variable partag globale, car lordre de lecture/criture nest pas spcifi.

B. Miramond - UCP

sc_main()

3. Simulation steps
.notify(); // immediate

SystemC Simulation Kernel

Elaboration Advance Time

sc_start();

Initialize

Evaluate

while process ready

Cleanup
.notify(SC_ZERO_TIME); // delayed
B. Miramond - UCP

.notify(t); // timed

Simulation steps

Elaboration

Les modules SystemC sont construits Les SC_METHOD et SC_THREAD sont cres. Dbute aprs lappel sc_start() Les processus cres llaboration sont lancs. Tous les processus sont placs dans la file READY. Les processus sont excuts en fonction de leur sensibilit Time management Clean objects and structures
B. Miramond - UCP

Initialisation

Evaluate-Update

Advance time

Cleanup

Rappel

Seul les SC_THREAD font des appels wait()

Ils ne sont excuts quune seule fois, mais peuvent tre interrompus.

Tous les SC_METHOD ont une liste statique et sont re-dclench chaque nouvelle notification.

Ils sont excuts autant de fois que ncessaire.

B. Miramond - UCP

Files dattente duDurant son excution, un scheduler processus peut raliser des a. Delayed notification notifications qui rveillent dautres
Ready P1 P2 P3 Running P4 processus en attente (Waiting). Events Waiting P5 P6 Un par un, les processus sont pris alatoirement de la file Ready et dsigns Aprs un Delta-cycle comme Running jusqu rencontrer un wait() ou un return().
B. Miramond - UCP

E1@0 E2@t1 E3@t2 E4@()

sc_main()

Simulation steps

SystemC Simulation Kernel

Elaboration

Les processus attendant un vnement notifi avec un dlai SC_ZERO_TIME(.notify(0)) sont replacs dans la file Ready au prochain cycle de simulation. Ce cycle est appel Delta-Cycle Delay.

sc_start();

Initialize

Evaluate

Advance Time

while process ready

Cleanup
.notify(SC_ZERO_TIME); // delayed
B. Miramond - UCP

b. Timed notification
Ready P1 P2 P3 Aprs un temps t1 Running P4 Waiting P5 P6 Events E1@0 E2@t1 E3@t2 E4@()

B. Miramond - UCP

sc_main()

Simulation steps

SystemC Simulation Kernel

Elaboration

Les processus attendant un vnement notifi avec un dlai non-nul sont placs dans la file Waiting et le temps est avanc jusquau temps du premier vnement de la liste. A cet instant les processus en attente sont placs en file Ready.

sc_start();

Initialize

Evaluate

Advance Time

while process ready

Cleanup
.notify(t); // timed
B. Miramond - UCP

c. Immediate notification
Ready P1 P2 P3 Dans le mme cycle Running P4 Waiting P5 P6 Events E1@0 E2@t1 E3@t2 E4@()

B. Miramond - UCP

sc_main()

Simulation steps

SystemC Simulation Kernel

.notify(); // immediate

Elaboration Advance Time

sc_start();

Initialize

Evaluate

while process ready

Cleanup

Une notification immdiate place directement les processus en attente durant le mme delta-cycle. Ceci peut se produire plusieurs fois jusqu rencontr une notification time.
B. Miramond - UCP

d. Synthse des tapes de simulation du scheduler SystemC

1. 2. 3. 4. 5. 6. 7. 8.

Initialisation Evaluation Sil y a encore des processus prt, retour en 2 Update Sil y a eu des notifications Delta-cyle, dterminer les processus READY et retour en 2. Sil ny a plus de non-Zero notifications, la simulation est termine Sinon, avancer le temps au prochain temps de notification Dterminer les processus READY, retour en 2.
B. Miramond - UCP

e. La fonction dont_initialize()

Normallement tous les processus sont excuts la premire fois durant la phase dinitialisation. SystemC permet de spcifier que certains processus ne seront pas excuts cette phase :

SC_METHOD(waiting_method) sensitive << a << b; dont_initialize();

La fonction ncessite une liste de sensibilit statique !! Sinon, le processus ne sera pas dmarr.

B. Miramond - UCP

f. End of simulation
1.

2.

3.

sc_start(argument); // where argument precise the amount of simulation time. Only used with timed models !! sc_stop(); // inside a component. It terminates simulation when a specified functional condition is atteined. Too local ! Terminator module, which call the sc_stop() primitive only when the logical sum of products on the endproces boolean condition is true. Global untimed halt condition.

B. Miramond - UCP

4) Le cas des channels : evaluate-update

Les canaux simples utilisent une procdure de mise jour particulire appele : request_update/update scheme. Ce schma permet de construire des canaux supportant des changements dtat intervenant sur des dures infinitsimales (Cycle) et donc dexprimer la concurrence son niveau le plus prcis.
B. Miramond - UCP

Exemple 1
On cherche swapper la valeur prsente dans 2 registres au moment de lhorloge. Si on modlise les registres par des variables, il est ncessaire dutiliser une 3e variable temporaire pour faire le swap. Si on utilise des signaux, 2 sont suffisants car lcriture et la lecture ne se font pas dans le mme cycle.
B. Miramond - UCP

Exemple 2
Reg1
Q1 DATA D Q D Q

Reg2
Q2

Reg3
Q3 D Q

Reg4
Q4 D Q

SYNC

Comportement attendu : 2. Q4 = Q3 3. Q3 = Q2 4. Q2 = Q1 5. Q1 = DATA

Pour que la fonctionnalit soit respecte, Lordre est important Chaque registre est un processus indpendant. Or le simulateur ne prcise aucun ordre sur les processus.
B. Miramond - UCP

Solution : 2 donnes du canal Signal

Chaque signal a deux lieux de mmorisation :

New value Et current value

Lors dune criture, 3. le signal place la valeur dans New value 4. Puis le processus appelle request_update() pour que le simulateur appelle son tour la fonction update() du canal lors de la prochaine phase. 5. Lorsque la phase dvaluation est rellement termine (il ny a plus de processus en tat Ready), le simulateur appelle update() pour chaque canal ayant fait un appel request_update(). 6. Le canal recopie la nouvelle valeur et notifie un sc_event pour indiquer un changement de valeur. Donc si un process crit sur un signal et lit immdiatement, il trouvera la valeur inchang !!
B. Miramond - UCP

New/Current value
Delta-Cycle

New Value
S1 = V2

Current Value
S1= V0 S2= V1

Canaux

S2 = V3

Update()
B. Miramond - UCP

sc_main()

The Update Simulation step

SystemC Simulation Kernel

Elaboration Advance Time

sc_start();

Initialize

Evaluate

Cleanup Update
B. Miramond - UCP

// Declaration Int count; sc_string message_tmp; sc_signal<int> count_sig; sc_signal<sc_string> message_sig; // Intializing during first delta cycle count_sig.write(10); message_sig.write(Hello); count = 11; message_temp = Bonjour; print_state(count, count_sig, message_temp, message_sig); wait(SC_ZERO_TIME); // 2nd delta cycle count = 20; count_sig.write(count); print_state(count, count_sig, message_temp, message_sig); wait(SC_ZERO_TIME); // 3rd delta cycle message_sig.write(message_temp = New message); print_state(count, count_sig, message_temp, message_sig);
B. Miramond - UCP

Exemple

// Konsole

// First delta cycle count is count_sig is message_temp is message_sig is // 2nd delta cycle count is count_sig is message_temp is message_sig is // 3rd delta cycle count is count_sig is message_temp is message_sig is

11 0 Bonjour 20 10 Bonjour Hello 20 20 New Message Hello

Guide dutilisation

Pour bien utiliser ces canaux :

1.

2.

3. 4.

Utiliser comme convention de nommage pour les signaux avec le suffixe _sig Lire tous les ports et signaux dans une variable locale Raliser les traitements sur ces variables locales crire le rsultat sur les ports et les signaux

Concept proche dun automate de Moore

B. Miramond - UCP

Rsum du schma request_update/update

Ce schma correspond dire que la mise jour de ces signaux est retarde dun Delta-cycle. Ce schma ne sapplique quaux canaux primitifs, mais pas tous :
sc_signal sc_fifo mais pas sc_mutex et sc_semaphore (cf. section IV)

B. Miramond - UCP

5) Concurrence et volution du temps

Process A(){ // @ t0 codeA1; codeA2; wait(t1); codeA3; codeA4; wait(t2); codeA5; codeA6; wait(t3); } Process B(){ // @ t0 codeB1; codeB2; wait(t1); codeB3; codeB4; wait(t2); codeB5; codeB6; wait(t3); } Process C(){ // @ t0 codeC1; codeC2; wait(t1); codeC3; codeC4; wait(t2); codeC5; codeC6; wait(t3); } Process D(){ // @ t0 codeD1; codeD2; wait(t1); codeD3; wait(0); codeD4; wait(t3); }

B. Miramond - UCP

Activit perue lors de la simulation

A
A1; A2; A3; A4; A5; 16;

B1; B2;

B3; B4;

B5; B6;

C1; C2;

C3; C4;

C5; C6;

C
D1; D2; D3; D4;

D
t1 t2
B. Miramond - UCP

t3

Activit relle lors de la simulation (1)

A
A1; A2; A3; A4; A5; 16; Chaque portion de code est excute en temps nul !!! B1; B2; B3; B4; B5; B6; Ce sont les wait(t) qui font avancer le temps !

C1; C2; D1; D2;

C3; C4;

C5; C6;

D3; D4;

D
t1 t2
B. Miramond - UCP

t3

Activit relle lors de la simulation (2)

A1; A2; A3; A4; A5; 16; A1; A2;

A
B1; B2; B3; B4;

Les oprations qui apparaissent concurrentes lutilisateur sont squences B5; B6; par le scheduler SystemC. B1; B2; Cet ordre est dterministe mais non prvisible ! C5; C6; C1; C2;

C1; C2;

C3; C4;

C
D1; D2; D4; D1; D2;

D
Rq: Extansion du temps t1 t2
B. Miramond - UCP

t3

6. Event-based simulators

VHDL, Verilog

B. Miramond - UCP

End of Green

B. Miramond - UCP