systemc

Introduction aux bases du langage SystemCModule Co-Design - II3

Élaboré par:Saber FERJANI

École Nationale des Sciences Informatiques

18 Octobre 2012

Saber F. (ENSI) SystemC 18 Octobre 2012 1 / 42

ObjectifSystemC a pour objectif de modéliser des systèmes numériques matériels etlogiciels à l'aide de C++. Il permet donc de modéliser non seulement des systèmesmatériels, mais aussi des systèmes logiciels, mixtes ou non-partitionnés.

Plan de l'exposé

1 Introduction

2 Organisation Structurelle

3 Les types de données

4 Processus & Événements

5 Exemples Introductifs

I- Introduction

Terminologie

UTF (UnTimed Functional) : s'applique à l'interface et à la fonctionnalitéd'un modèle. Le modèle comporte seulement un ordre éventuel dansl'exécution des événements. Chaque événement s'exécute en un temps nul.

TF (Timed Functional) : s'applique à l'interface et à la fonctionnalité d'unmodèle. Le modèle comporte des notion de durée.

BCA (Bus Cycle Accurate) : s'applique à l'interface d'un modèle. Il signi�eque la modélisation des transactions sur l'interface sont correctes au cycleprès.

CABA (cycle accurate / bit accurate) : s'applique à l'interface d'un modèleet à la fonctionnalité d'un modèle. Il signi�e que la modélisation destransactions sur l'interface est BCA, et porte aussi sur les signaux del'interface. La modélisation est précise au bit près.

RTL (Register Transfert Level) : s'applique à l'interface et à la fonctionnalitéd'un modèle matériel. Tout est modélisé.

Méthode classique

Inconvénients de la méthode classique

L'un des inconvénients majeurs des �ots habituels vient de la multitude deslangages mis en ÷uvre :

le partitionnement matériel / logiciel est e�ectué, le plus souvent en C /C++ (ou dans un langage spécialisé)un modèle matériel transactionnel (TF) est alors produit, qui sert de modèlede référence. C'est un exécutable modélisant le comportement du systèmematériel. Il est écrit le plus souvent en C / C++ ou dans un langagepropriétaire.ce modèle est alors manuellement transcrit dans un langage de descriptionmatériel, puis ra�né jusqu'à la synthèse.une fois le module matériel arrivé au stade CABA, un autre modèle C / C++de référence est produit (manuellement) incorporant les éventuellesmodi�cations qui ont eu lieu tout au long du cycle de développement.à chaque étape, les environnements de test doivent eux aussi être transcodés.

Toutes ces transcriptions manuelles introduisent des erreurs. L'objectif principal deSystemC est de maintenir un seul et même langage d'un bout à l'autre du �ot deconception.

le partitionnement matériel / logiciel est e�ectué, le plus souvent en C /C++ (ou dans un langage spécialisé)

un modèle matériel transactionnel (TF) est alors produit, qui sert de modèlede référence. C'est un exécutable modélisant le comportement du systèmematériel. Il est écrit le plus souvent en C / C++ ou dans un langagepropriétaire.ce modèle est alors manuellement transcrit dans un langage de descriptionmatériel, puis ra�né jusqu'à la synthèse.une fois le module matériel arrivé au stade CABA, un autre modèle C / C++de référence est produit (manuellement) incorporant les éventuellesmodi�cations qui ont eu lieu tout au long du cycle de développement.à chaque étape, les environnements de test doivent eux aussi être transcodés.

le partitionnement matériel / logiciel est e�ectué, le plus souvent en C /C++ (ou dans un langage spécialisé)un modèle matériel transactionnel (TF) est alors produit, qui sert de modèlede référence. C'est un exécutable modélisant le comportement du systèmematériel. Il est écrit le plus souvent en C / C++ ou dans un langagepropriétaire.

ce modèle est alors manuellement transcrit dans un langage de descriptionmatériel, puis ra�né jusqu'à la synthèse.une fois le module matériel arrivé au stade CABA, un autre modèle C / C++de référence est produit (manuellement) incorporant les éventuellesmodi�cations qui ont eu lieu tout au long du cycle de développement.à chaque étape, les environnements de test doivent eux aussi être transcodés.

le partitionnement matériel / logiciel est e�ectué, le plus souvent en C /C++ (ou dans un langage spécialisé)un modèle matériel transactionnel (TF) est alors produit, qui sert de modèlede référence. C'est un exécutable modélisant le comportement du systèmematériel. Il est écrit le plus souvent en C / C++ ou dans un langagepropriétaire.ce modèle est alors manuellement transcrit dans un langage de descriptionmatériel, puis ra�né jusqu'à la synthèse.

une fois le module matériel arrivé au stade CABA, un autre modèle C / C++de référence est produit (manuellement) incorporant les éventuellesmodi�cations qui ont eu lieu tout au long du cycle de développement.à chaque étape, les environnements de test doivent eux aussi être transcodés.

le partitionnement matériel / logiciel est e�ectué, le plus souvent en C /C++ (ou dans un langage spécialisé)un modèle matériel transactionnel (TF) est alors produit, qui sert de modèlede référence. C'est un exécutable modélisant le comportement du systèmematériel. Il est écrit le plus souvent en C / C++ ou dans un langagepropriétaire.ce modèle est alors manuellement transcrit dans un langage de descriptionmatériel, puis ra�né jusqu'à la synthèse.une fois le module matériel arrivé au stade CABA, un autre modèle C / C++de référence est produit (manuellement) incorporant les éventuellesmodi�cations qui ont eu lieu tout au long du cycle de développement.

à chaque étape, les environnements de test doivent eux aussi être transcodés.

Limite de la simulation

Flot de conception SystemC

ObjectifPermet la co-conception logiciel/Matériel

AvantagesPas de transcriptions manuelles.

Plus proche du matériel par rapport à C/C++, et plus abstrait queVerilog/Vhdl

Open-source

Plusieurs niveaux d'abstraction de la conception système jusqu'à la synthèseRTL

Types de données enrichis par des types de données adaptées à lamodélisation de matériel (logique multivaluée, décimaux virgule �xe, ...).

Moteur de simulation adapté : PowerSim, SystemCass du LIP6

Open-source

HistoriqueVersion 0.9 par Synopsys en 1989

Version 1.0 par Frontier Design

Version 1.1 par CoWare en 2001

Création de L'OSCI (Open SystemC Initiative) en 2001

Version 2.0 par L'OSCI

Version 2.2 approuvée par IEEE appelée IEEE1666-2005 en 2005.

En juin 2011 une alliance entre Accellera et l'OSCI est annoncée

III- Organisation Structurelle

Organisation de SystemC

Structure d'un modèle SystèmeDesign Entity : SC_MODULE

Interfaces

Canaux

Processus

Interfaces

Canaux

Processus

Interfaces

Canaux

Processus

Interfaces

Canaux

Processus

Interfaces

Canaux

Processus

Exemple d'organisation structurelle

Design Entity : SC_MODULEClasse dans C++

Bloc élémentaire de la conception

Approche diviser pour régner

Équivalent à Entity dans Vhdl

SyntaxeSC_MODULE(module_name){// Ports declaration// Signals declaration// Module constructor : SC_CTOR// Process constructors and sensitivity list// SC_METHOD// Sub-Modules creation and port mappings// Signals initialization// Process de�nition} ;

PortsUn module possède un ou plusieurs ports. Les ports sont juste des points d'entréeou de sortie, qui ne font rien de particulier.

SyntaxeSC_MODULE(module_name){sc_in<data_type> in1, in2 ;sc_out<data_type> out1, out2 ;sc_inout<data_type> inout1, inout2 ;//. . .} ;

InterfacesUne interface est une déclaration des fonctions (ou "méthodes", pour prendre laterminologie C++) qui pourront être utilisées à travers les ports d'un module. Uneinterface ne contient pas de code, c'est seulement une déclaration de fonctions.Les interfaces permettent au compilateur de détecter très tôt le branchement d'unport à un canal qui ne lui est pas adapté.

CanauxLes canaux sont les moyens de communication entre les modules. Ils peuvent êtrebasique et concrets (signaux), ou plus évolués / plus abstraits (�fo, réseauethernet, ...). Ils peuvent aussi contenir d'autres canaux, voire même des modulessi ce sont des canaux de très haut niveau.

ProcessusLes processus en SystemC sont similaire à ceux de Verilog et VHDL. Il décriventune fonctionnalité, un comportement. Un processus ne doit pas être appelédirectement ; c'est le moteur de simulation SystemC qui se charge de l'appeler (ledéclencher) sur certains événement particuliers : ceux qui sont dans sa liste dessensibilité.

Les types de données

III- Les types de données

Les éléments de base de SystemC (signaux, ports, ...) sont des classes génériques,des templates au sens C++. Selon les objets qu'ils représentent, on doit lesspécialiser pour un type particulier, préciser leur nombre de bits, leur nature(entier ou �ottant), ...

Principaux types :les types bits

les vecteurs de bits

les types entiers

les nombres en virgule �xe

les types temporels

les types entiers

les types temporels

les types entiers

les types temporels

les types entiers

les types temporels

les types entiers

les types temporels

Les types bits

SystemC propose deux types de bit : sc_bit et sc_logic :

sc_bit

Ce type est obsolète (depuis La version 2.2). On utilisera plutôt le type bool.Ce type est destiné à représenter un bit ne pouvant prendre que deux valeurs, '0'(false) et '1' (true).

sc_logicCe type est une extension de sc_bit à la logique 4-valuée. Il représente un bitpouvant prendre les valeurs '0', '1', 'Z' et 'X'. Par défaut, un object sc_logic noninitialisé vaut 'X'.

Les types entiers

SystemC propose une extension du type int (généralement sur 32 bits), signés etnon-signés, allant de 1 bit à autant qu'on veut : sc_int, sc_uint, sc_bigint,sc_biguint.

Exemplesc_int<12> val1, val2 ; // entiers signés sur 12 bitssc_int<64> res ; // entier signé sur 64 bitssc_uint<10> val3 ; // entier non signé sur 10 bitssc_int<3> val4 ; // entier signé sur 3 bits

Les vecteurs de bits

Les types vecteurs de bits ne doivent pas être confondus avec les types entiers.Ce sont des tableaux de bits, pas des nombres. Ils sont optimisés pour lesmanipulations de bits, et ne disposent pas d'opérations arithmétiques.sc_bv<n> : Vecteur de bits 2-valués.sc_lv<n> : Vecteur de bits 4-valués.

Exemplesc_bv<8> x ;sc_bit y ;x = "01000111" ;y = x[6] ; // y vaut '1'

Les nombres en virgule �xe

Les système numériques travaillant sur des nombres décimaux qui peuvent êtrereprésentés en virgule �xe.SystemC propose quatre types pour représenter ces nombres en virgule �xe, avecdi�érents modèles de quanti�cation et de dépassement.

signés non-signésparamètres déterminés à la compilation sc_�xed sc_u�xed

paramètres dynamiques sc_�x sc_u�x

Le temps

En SystemC 2.x, comme en Verilog et VHDL, le modèle sous-jacent pour le tempsest de type entier non signé sur 64 bits. La résolution par défaut est 1ps.Une valeur temporelle est de type sc_time, et demande deux arguments lors de sacréation :

un argument de type double spéci�ant la valeur,

un argument de type énuméré sc_time_unit en spéci�ant l'unité.

Exemplesc_time t1( 20, SC_NS ) ;

Le temps

En SystemC 2.x, comme en Verilog et VHDL, le modèle sous-jacent pour le tempsest de type entier non signé sur 64 bits. La résolution par défaut est 1ps.Une valeur temporelle est de type sc_time, et demande deux arguments lors de sacréation :

un argument de type double spéci�ant la valeur,

un argument de type énuméré sc_time_unit en spéci�ant l'unité.

Exemplesc_time t1( 20, SC_NS ) ;

Processus & Événements

IV- Processus & Événements

Une fois les éléments structurels de SystemC dé�nis, nous allons maintenantprésenter les di�érents éléments fonctionnels de SystemC, autrement dit commentreprésenter la fonctionnalité d'un module autrement que par un assemblage desous-boîtes.

Événements : SC_EVENT

Processus : SC_METHOD, SC_THREAD, SC_CTHREAD

Une fois les éléments structurels de SystemC dé�nis, nous allons maintenantprésenter les di�érents éléments fonctionnels de SystemC, autrement dit commentreprésenter la fonctionnalité d'un module autrement que par un assemblage desous-boîtes.

Événements : SC_EVENT

Processus : SC_METHOD, SC_THREAD, SC_CTHREAD

Événements

Dé�nitionLes événements sont les objets sur lesquels se base toute la synchronisation desprocessus. Ils déterminent quand est-ce qu'un processus doit être déclenché ouréveillé.Il peuvent représenter des événements concrets (changement d'état d'un signal),ou abstraits.

Classe et méthodesLes événements sont des instances de la classe sc_event. On les créé rarementsoi-même, sauf quand on crée un nouveau type de canal, ou qu'on veut rendre unprocessus sensible à autre chose qu'un signal.On récupère l'événement associé à un canal par une des méthodes suivante :

pour un signal : value_changed_event(), posedge_event(), negedge_event()

pour les �fo : data_written_event(), data_read_event()

Événements

Dé�nitionLes événements sont les objets sur lesquels se base toute la synchronisation desprocessus. Ils déterminent quand est-ce qu'un processus doit être déclenché ouréveillé.Il peuvent représenter des événements concrets (changement d'état d'un signal),ou abstraits.

Classe et méthodesLes événements sont des instances de la classe sc_event. On les créé rarementsoi-même, sauf quand on crée un nouveau type de canal, ou qu'on veut rendre unprocessus sensible à autre chose qu'un signal.On récupère l'événement associé à un canal par une des méthodes suivante :

pour un signal : value_changed_event(), posedge_event(), negedge_event()

pour les �fo : data_written_event(), data_read_event()

Processus

Dé�nitionLes processus de SystemC se comportent comme les processus de VHDL. Ilsdécrivent la fonctionnalité d'un module.Les processus utilisent les événements et les canaux pour communiquer entre eux.(Il est possible de faire communiquer des processus par des variables, mais c'estfortement déconseillé.)

Types de processusIl existe deux types de processus en SystemC : SC_METHOD et SC_THREAD.(SC_CTHREAD, est une spécialisation des SC_THREAD.)

Étapes d'instanciation :déclaration du processus

enregistrement

déclaration de la liste de sensibilité par défaut

implémentation

Processus

enregistrement

implémentation

Processus

enregistrement

implémentation

Processus

enregistrement

implémentation

SC_METHOD - SC_THREAD - SC_CTHREAD

Dé�nitionLes SC_METHOD sont, du point de vue du scheduler, des fonctions normales. Ilssont appelés par le scheduler à chaque noti�cation d'événement de leur liste desensibilité. Ils s'exécutent en entier, dans le contexte du scheduler, puis exécutentun return(), qui redonne la main au scheduler.

Quand utiliser un SC_METHODPour modéliser des processus qui s'exécutent d'un trait, avec un comportementglobalement constant à chaque appel. Par exemple une bascule D, un compteur, ...Par opposition, une machine à état passe successivement par des états di�érents,et son comportement change à chaque état. Elle ne se prête donc pas bien auxSC_METHOD, à moins de la décrire de façon académique (registre d'état, et unprocessus combinatoire à part).

SC_CTHREAD - SC_THREAD - SC_CTHREAD

Dé�nitionLes SC_THREAD sont des threads indépendant du scheduler. Ils sont lancés uneseule fois, au début de la simulation, et plus jamais après. Ce sont des bouclesin�nies, qui peuvent et doivent être mises en veille à intervalle réguliers. Le tempspeut alors s'écouler. Les SC_THREAD sont réveillés par leur liste de sensibilité.

Di�érence avec les SC_METHODun SC_METHOD est lancé à chaque fois que sa liste de sensibilité ledemande, et ne se suspend pas (sinon le scheduler bloque).

un SC_THREAD est lancé une seule fois, c'est un thread (au sens Unix duterme) indépendant. Sa liste de sensibilité sert à le sortir de veille. Il peutbloquer (veille, boucle in�nie, ...), ça ne gêne pas le simulateur.

SC_CTHREAD - SC_THREAD - SC_CTHREAD

Dé�nitionLes SC_CTHREAD sont des cas particuliers des SC_THREAD. Leur nom signi�eClocked THREAD : threads synchrones. Ils sont utilisés pour modéliser des threadsensibles uniquement à un front d'horloge.

FonctionnementComme les SC_THREAD, les SC_CTHREAD sont des threads Unixindépendants du simulateur. Une fois qu'ils ont exécuté un return(), ils sont mortset ne sont plus jamais exécutés.

Processus & Événements

V- Exemples Introductifs

Hello World Program

Exécution

Pour compiler et simuler (sous Linux) :

Sortie du programme

Port AND à trois entrées, Bascule D Flip-Flop

Registre à décalage 8 bits

Conclusion GénéraleLa bibliothèque SystemC permet d'accélérer la réalisation des systèmes,

Il permet d'uni�er le langage des di�érents étapes du �ot de conception,

L'automatisation de la traduction permet de minimiser la probabilité d'erreur,

Bien que SystemC ne remplace pas les langages de description matériel, sonutilisation s'impose de plus en plus.

Merci pour votre attention !

Référenceshttp ://comelec.enst.fr/hdl/sc_intro.html

www.vlsi.itu.edu.tr

http ://www.asic-world.com/systemc/�rst1.html

http ://www.docstoc.com/docs/74345699/System-on-Chip-Modeling-with-SystemC�Past-and-Future

systemc

Education