SystemC structurel

Préambule

Objectifs

Ce chapitre a pour objectif de vous présenter les différents éléments structurels de SystemC :

interfaces
canaux
ports
modules

A la fin de ce chapitre,

vous connaitrez le rôle de chaque objet,
vous serez en mesure d'instancier des modules et des canaux, et de les relier entre eux.

Plan du chapitre

On commencera par l'objet le plus "petit" (interne) : les interfaces, point commun entre les canaux et ports.
On continuera par les canaux, qui implémentent les interfaces.
Puis on étudiera les ports, notamment les ports spécialisés (pré-définis)
De là découlera la structure des modules...

Back to top

Interfaces

Définition

Un port d'un module est connecté à un canal (sauf dans le cas particulier où il est directement connecté au port d'un module parent). Les processus du module communiquent vers l'extérieur au travers de ces ports, en appelant les méthodes du canal auquel il est relié (ce canal est généralement un signal).

Une interface est un objet C++ ne contenant que les déclarations des méthodes du canal relié à un port, et donc accessibles par l'intérieur du module.

une interface ne contient pas de code, juste des déclarations de méthodes (purement virtuelles)
ça tombe bien, tout ce qu'un port a besoin de connaitre c'est le nom des méthodes à appeler, pas leur implémentation
c'est le canal qui est en charge de fournir l'implémentation des méthodes d'une interface

Le port est donc un trou dans un module, et l"interface un moyen de se mettre d'accord avec le canal qui y sera branché sur la manière de discuter.

Dit autrement, quand on accède à un canal depuis l'intérieur d'un module (à travers un port), on ne peut appeler que les méthodes de ce canal déclarées dans l'interface du port.

Quand on accède à un port, on accède en fait de manière cachée aux méthodes du canal qui lui est relié par l'intermédiaire de l'interface.

Pour en savoir plus...

Pour en savoir plus

Interfaces, ports canaux

Comme expliqué précédemment, un processus communique avec un canal au travers d'un port. Prenons le code suivant :

SC_MODULE(module) {
 
 sc_in<bool> data;


 ... 
 data = 0;
 ...

}

Un processus du module affecte la valeur 0 au port data. En fait, c'est fait la méthode "=" du canal lié au port data qui est appelée, avec comme argument 0.
C'est un peu plus clair quand on écrit l'affectation de façon explicite : data.write(0); : le "." du port data est redéfini dans la classe sc_in pour appeler en fait la méthode write du signal.

Un port n'a pas besoin de connaître l'implémentation du write, tout ce qu'il doit savoir c'est comment l'appeler (quel est son prototype). Plus généralement, un port a seulement besoin de connaitre la déclaration des méthodes du canal qui lui sera connecté. Peu importe l'implémentation de ces méthodes, seule leur déclaration (prototype) est importante. C'est le même scénario qu'en C, quand on appelle la fonction d'une bibliothèque. La seule chose importante est la déclaration de la fonction (ex : extern int f(char *, int) ), pas la façon dont elle est codée.

Une interface est un objet C++ contenant seulement la déclaration des méthodes des signaux qui seront connectés à un port :

l'interface ne contient ni code ni de données, juste des signatures de fonctions.
c'est au canal de fournir l'implémentation des fonctions déclarées dans l'interface. On dit alors qu'il implémente cette interface.
un canal ne peut être relié à un port que s'il implémente toutes les méthodes de l'interface du port.
de façon réciproque, un port ne pourra accéder qu'aux fonctions du canal qui sont déclarées dans l'interface.

Bref, une interface est un moyen pour un port et un canal de se mettre d'accord sur la façon de discuter.

Remarque : un processus qui instancie un canal peut accéder directement à son interface. Par contre, il doit passer par un port pour accéder aux canaux qui lui sont extérieurs.

Intérêt des interface

Un canal peut implémenter plusieurs interfaces. Prenons un canal bien évolué, comme un réseau ethernet en TCP/IP. Selon le raffinement du modèle, il pourrait avoir les interfaces suivantes :

interface haut niveau (TCP) : socket. Les méthodes implémentées seraient du style read_buffer, write_buffer, ...
interface niveau ethernet : write_packet, read_packet, read_status, ...
interface niveau bus : write_data, read_data
interface CABA : read et write (des signaux addr, data, ce, ...)

On pourrait avoir un module de test, branché au contrôleur ethernet par son interface de plus haut niveau, et un SoC, qui au fur et à mesure de son raffinement, serait successivement branché à toutes les interfaces, d'abord celle de plus haut niveau (pour valider les algorithmes), puis à celle CABA (quand on arrive au RTL). Tout ceci sans changer le code du contrôleur, ni celui du système de test.

Interfaces et C++

Pour obliger à ce qu'un canal implémente toutes les méthodes d'une interface,

les méthodes de l'interface sont déclarées comme étant purement virtuelles (virtual void f() = 0;),
le port et le canal héritent (au sens C++) tous les deux de l'interface (en plus de leur classe de base sc_port et sc_channel)
la classe de base sc_port redéfinit la méthode -> en un appel de la méthode du canal correspondant
enfin le canal doit fournir une implémentation non purement virtuelle de la méthode.

Interfaces standards

Voici les interfaces standards définies par SystemC, pour les canaux atomiques (signal, fifo, mutex, sémaphore) :

sc_signal

Il existe deux interfaces pour les signaux : sc_signal_in_if pour la lecture seule des signaux (connectés à un port sc_in), et sc_signal_inout_if qui rajoute la notion d'écriture (signaux connectés à un port sc_out ou sc_inout).

sc_signal_in_if<T> (pour les ports en lecture seule)

bool event() : renvoie true si le signal associé a été modifié dans le delta_cycle précédent

bool negedge(), bool posedge() : renvoie true si une transition vers l'état false (resp. true) a eu lieu au delta_cycle précédent

T& read() : renvoie une référence à la valeur courante du signal associé

print(ostream&) : affiche l'état courant du signal associé sur le flux ostream

const sc_event& value_changed_event () : renvoie une référence à un événement qui sera notifié lors d'un changement d'état du signal associé. Cet événement sera typiquement utilisé dans les fonction wait().

const sc_event& posedge_event() : renvoie une référence à un événement qui sera notifié lors d'un changement d'état vers true du signal associé (s'il est de type bool ou sc_logic seulement). Cet événement sera typiquement utilisé dans les fonction wait().

const sc_event& negedge_event() : renvoie une référence à un événement qui sera notifié lors d'un changement d'état vers false du signal associé (s'il est de type bool ou sc_logic seulement). Cet événement sera typiquement utilisé dans les fonction wait().

sc_signal_inout_if<T> (pour les ports aussi en écriture)

toutes les méthodes de sc_signal_in_if

void write (const T&) : permet de changer la valeur du signal associé. Le changement sera effectif au prochain delta_cycle. Un événement ne sera notifié que si la nouvelle valeur diffère de la valeur actuelle.

sc_buffer

Un buffer se comporte exactement comme un signal, à la différence près qu'un événement de changement d'état est notifié à chaque affectation, même si on lui affecte la même valeur que celle courante. Pour un sc_signal, le changement d'état n'est notifié que si la valeur change.

Il implémente les même interfaces que sc_signal.

sc_fifo

Comme pour les signaux, les fifo disposent de deux interfaces selon si on y accède en lecture ou en écriture.

sc_fifo_in_if<T> :

T read(), read(T&) : effectue une lecture bloquante de la fifo.

bool nb_read(T&) : effectue une lecture non bloquante de la fifo. Renvoie true si une lecture a eu lieu, false sinon.

int num_available() : renvoie le nombre d'élément en attente de lecture dans la fifo.

sc_event& data_written_event() : renvoie une référence à un événement qui sera notifié lors d'une écriture dans la fifo. Cet événement pourra être utilisé dans une fonction wait().

sc_fifo_out_if<T> :

write( T&) : effectue une écriture bloquante dans la fifo

bool nb_write(T&) : effectue une écriture non bloquante dans la fifo. Renvoie true si elle été effectuée, false sinon

int num_free() : renvoie le nombre d'emplacement libres dans la fifo

sc_event& data_read_event() : renvoie renvoie référence à un événement qui sera notifié lors d'une lecture de la fifo. Cet événement pourra être utilisé dans une fonction wait().

sc_mutex

sc_mutex_if :

int sc_lock() : si le mutex n'est pas locké, la fonction le locke, sinon elle bloque jusqu'à ce qu'il puisse être locké.

int try_lock() : si le mutex n'est pas locké, le locke. Renvoie 0 en cas de succès, -1 sinon.

int unlock() : délocke un mutex. Les processus en attente de lock sur ce mutex seront alors réveillés.

sc_semaphore

sc_semaphore_if :

int wait() : acquiert le sémaphore, et décrémente sa valeur de 1. Bloque s'il valait 0.

int try_wait() : idem, en non-bloquant.

int post() : relâche le sémaphore, et incrémente sa valeur de 1

int get_value() : renvoie la valeur actuelle du sémaphore

En résumé :

Une interface est une classe C++ ne comportant que les déclarations des méthodes d'un canal auxquelles un port pourra accéder.

Les ports et les canaux sont des classes C++ qui héritent de leur classe de base et de celle de l'interface.
Le canal doit implémenter les méthodes en question.
Le port redirige les appels aux méthodes de son interface vers l'implémentation du canal.

Passons maintenant à l'étude des canaux.

Back to top

Canaux

Vous connaissez les signaux de VHDL ou Verilog. Les canaux sont une généralisation des signaux : un canal est fait pour transmettre de l'information entre un processus et un autre processus ou un port de module. En SystemC, cette information peut être extrêmement abstraite. Ca peut être un bit, un flottant, un packet ethernet, ou une information d'accès exclusif (exemple : "j'ai pris un sémaphore"). Les canaux ne sont pas forcément point à point : ils peuvent modéliser des bus, ...

Les signaux sont donc des types particuliers de canaux, correspondant à des bus ou des fils. SystemC en prédéfinit d'autres dont les principaux sont les buffers, les fifo, les sémaphores, les mutex.

Les canaux sont utilisés :

à l'intérieur d'un module pour la communication entre deux processus. Les processus peuvent alors accéder directement aux interfaces des canaux.
pour la communication entre modules. Les processus accèdent alors au canal par l'intermédiaire d'un port du module. Le port doit alors présenter une des interfaces du canal.

Les canaux implémentent les interfaces. Quand un processus accède à un port, c'est en fait la méthode du canal correspondant qui est exécutée. Cette méthode s'exécute dans le contexte du processus. Cela une importance particulière pour les fifo : un processus qui fait une lecture bloquante sur un port connecté à une fifo peut se retrouver bloqué (suspendu). Bien que la méthode exécutée soit implémentée par la fifo, c'est le processus dans le contexte duquel elle s'exécute (le processus appelant) qui est suspendu.

Il existe deux types de canaux :

les canaux atomiques (primitive) : ils n'ont pas de structure visible, ne contiennent rien, et ne peuvent pas accéder directement à d'autres canaux.
les canaux hiérarchiques : ce sont en fait des modules, qui peuvent contenir des canaux, des modules, etc. Ils peuvent accéder directement à d'autres canaux.

Utilisation

variables

Pour transmettre une information qui n'a pas besoin d'affectation différée et pour accélérer à tout prix les simulations.
L'utilisation des variables pour communiquer de l'information entre processus est souvent une mauvaise habitude.

canaux atomiques

Pour transmettre de l'information qui a besoin d'affectation différée, et que le moyen de communication ne peut pas être découpé en éléments plus petits (c'est le cas des signaux...).
Les canaux atomiques simulent moins vite que les variables, mais plus vite que les canaux hiérarchiques.

canaux hiérarchiques

Dans tous les autres cas : quand le moyen de communication a plusieurs ports, quand il comporte des processus multiples, quand aucun des canaux atomiques ne convient...

Nous ne occuperons ici que des canaux atomiques, les canaux hiérarchiques étant des modules, ils seront étudiés plus tard.

sc_signal<T>

Les signaux sont les principaux canaux atomiques. Ce sont des classes "templatisées" qui doivent donc être personnalisées par le type de la valeur sous-jacente transmise par le signal. On peut les voir comme des tuyaux, le T étant le type de liquide qui s'écoule dedans.

Exemples :

si le signal est sur 1 bit, la valeur est un booléen, on utilisera donc un sc_signal<bool>.
pour un bus sur 33 bits pouvant être en trois états, on utilisera un sc_signal<sc_lv<33> >.
On aurait pu utiliser 33 signaux, chacun de type sc_signal<sc_logic>, mais c'est moins efficace.
pour transmettre un décimal en précision fixe, on utiliserait un sc_signal<sc_fixed<...> >
plus généralement, on peut personnaliser les signaux avec n'importe quel objet, pourvu que celui-ci dispose d'un opérateur d'affectation et d'un opérateur de comparaison.
Ainsi, pourquoi pas : sc_signal<char** >, sc_signal<mpeg2_frame> ...

Les affectations des signaux sont toujours différées. Pour cela, ils possèdent trois membres : current_value, new_value et old_value. Une affectation modifie new_value, et à la fin du delta_cycle, si new_value est différente de current_value (au sens de "== renvoie false"), new_value est affectée à current_value et un événement est déclenché (on dit "notifié").

Les signaux ne peuvent être affectés que par un seul processus à la fois. Lors du démarrage de la simulation, une analyse est faite pour vérifier que chaque signal n'est connecté qu'à un seul port en écriture maximum. Le nombre de ports en lecture, par contre, n'est pas limité.

Les signaux implémentent l'interface sc_signal_inout_if. Ils implémentent donc automatiquement sc_signal_in_if (la première dérivant de la deuxième).

Les principales méthodes des signaux sont :

value_changed_event(), default_event()

renvoie une référence (pointeur de C++) à un événement qui peut alors être utilisé dans une instruction wait(). Cet événement est notifié (déclenché) au delta cycle suivant la modification de la valeur signal.

posedge_event(), negedge_event()

valide seulement pour les signaux de type bool ou sc_logic. Semblable à ci-dessus, mais seulement si le signal passe à true (resp false).

read() (ou "=" s'il apparait à droite du signe égal)

renvoie une référence à current_value

write(const T& val) (ou "=" s'il apparait à gauche du signe égal)

si val est différent de current_value, alors stocke val dans new_value, et schedule une mise à jour du signal.

posedge(), negedge()

renvoie un booléen, true si le signal a subi une transition vers true (resp. false) au delta_cycle précédent, false sinon.

event()

renvoie un booléen, true si le signal a été modifié au delta-cycle précédent, false sinon.

Exemples d'utilisation :

sc_signal<bool> enable, control;
sc_signal<sc_lv<32> > data;
long valeur;
	
enable = 0;
valeur = data; // peut donner un résultat indéfini si data contient un 'X' ou 'Z'... 
if(enable==control) {...}

sc_buffer<T>

Similaire à sc_signal, à une différence près : sc_signal ne déclenche un événement que si sa nouvelle valeur est différente de la valeur courante, alors que sc_buffer déclenche un événement d'affectation quelque soit la nouvelle valeur.

sc_signal_rv<int n>, sc_signal_resolved

Ce sont en fait des sc_signal<sc_lv<n> > et sc_signal<sc_logic>, autrement dit des signaux trois-états sur un ou plusieurs bits, avec une différence : ils peuvent être connecté à plusieurs ports en écriture à la fois. Ils sont utilisés pour modéliser des bus 3-états.

Ils possèdent une fonction de résolution, dont le comportement est intuitif :

'X' contre n'importe quoi d'autre donne 'X'
'Z' contre n'importe quoi d'autre donne le n'importe quoi d'autre
'0' contre '1' donne 'X'

Leurs méthodes sont les mêmes que pour un sc_signal<sc_lv<n> > et sc_signal<sc_logic>.

sc_fifo<T>

Comme son nom l'indique, ce canal implémente une fifo (abstraite), de longueur définie lors de son instanciation (paramètre de construction). C'est un moyen de communication point à point, autrement dit il ne peut avoir qu'un seul processus lecteur, et un seul écrivain.

Comme pour sc_signal, T peut être de n'importe quel type, pourvu qu'il dispose d'un opérateur de copie et de comparaison.

Cette fifo se comporte comme un signal : une écriture dedans n'est prise en compte qu'à la fin du delta-cycle courant. La valeur écrite ne pourra donc être lue au plus tôt qu'au delta-cycle suivant.

Elle implémente les interfaces sc_fifo_in_if et sc_fifo_out_if, déjà vues à la partie sur les interfaces.

Exemples d'utilisation :

// sc_fifo de longueur par défaut égale à 16
sc_fifo<int> fifo;
int a,b;

a = fifo.read();
b = fifo;

fifo.write(a);
fifo = b;

if(fifo.num_available() > 3) 
a = fifo;

sc_mutex

Ce canal implémente un mutex (un verrou d'accès concurrent). Il permet à plusieurs processus d'accéder à une ressource partagée de façon sûre : avant chaque accès, un processus est sensé essayer d'acquérir le mutex. S'il y arrive, le mutex est verrouillé, et seul ce processus-là peut le déverrouiller. Il peut alors accéder tranquillement à la ressource partagée : SystemC garantit qu'aucun autre processus ne pourra acquérir le verrou alors qu'il est verrouillé.

Si un processus essaye d'acquérir le verrou de façon bloquante (méthode lock() ) alors que le verrou est déjà pris, le processus est suspendu. Il ne sera réveillé qu'à la libération du verrou.

Attention le fait qu'un processus doit acquérir le verrou avant d'accéder à la ressource partagée est une convention. SystemC ne peut pas le vérifier.

Les mutex implémentent l'interface sc_mutex_if, vue à la partie sur les interfaces.

Exemples d'utilisation :

sc_mutex mutex; 


...

while( true ) {
 wait(clock.posedge_event());
 mutex.lock(); 
 ... // do something
 mutex.unlock(); 
}

sc_semaphore

Les sémaphores sont une généralisation des mutex à n accès concurrents. Le sémaphore est initialisé à sa construction avec une valeur n. Lorsqu'un processus veut accéder à une ressource partagée, il doit d'abord accéder au sémaphore. Si le sémaphore a une valeur >0, il est décrémenté et le processus peut accéder à la ressource partagée. Sinon, le processus est mis en veille jusqu'à ce que le sémaphore redevienne > 0. Lorsqu'un processus a fini d'accéder à la ressource partagée, il relâche le sémaphore, ce qui a pour effet de l'incrémenter (et éventuellement de réveiller des processus suspendus en attente du sémaphore).

Si plusieurs processus tentent d'acquérir le sémaphore pendant le même delta_cycle, un seul y arrivera. Mais celui qui y arrivera n'est pas déterminé (car l'ordre d'exécution des processus dans un delta_cycle n'est pas déterminé).

Les sémaphores implémentent l'interface sc_semaphore_if.

Exemples d'utilisation :

// instancie un semaphore à 5 accès concurrents

sc_semaphore sem(5);


// instancie un sémaphore à 1 accès concurrent = mutex
sc_semaphore mut(1);



while( true ) {
 wait(clock.posedge_event());
 sem.wait(); 
 ... // do something
 sem.post(); 
}

Exercices

dans le code suivant, que valent a, b et c à la sortie de f ? (on partira du fait qu'il valent 0 à l'entrée de f)

int a;
sc_signal<int> b;
sc_signal<int> c;

void f() {
 a = 2;
 b = a;
 c = b;
}

donnez le code d'un registre à décalage 1bit à 4 étages en utilisant un processus par étage. Peut-on accélérer la simulation en utilisant des variables (par opposition à des signaux) ?

N'oubliez pas de mettre les réponses dans votre dépôt. (était-ce vraiment la peine de le mentionner ?)...

En résumé :

Les canaux sont les moyens de communications de SystemC, une sorte de généralisation des signaux de Verilog et VHDL.

Le type le plus utilisé, pour modéliser des fils et des bus, est le type sc_signal ou sc_rv (3-états)

Les canaux fournissent des méthodes d'accès (read, write, =) et déclenchent éventuellement des événements (accessibles par event). Les méthodes s'éxécutent dans le contexte (au sens UNIX) du processus appelant, autrement dit, si elles bloquent, c'est le thread du processus appelant qui est bloqué, pas le reste du canal.

Les méthodes implémentées par un canal sont déclarées dans une interface.

Passons maintenant à l'étude des ports .

Back to top

Les ports

Les ports sont les parties d'un module par lesquelles passent toutes les données qui y entrent ou en sortent. Plus précisément, c'est ce qui permet à un module d'accéder à l'interface d'un canal externe.

Un port hérite d'une interface particulière : il ne peut donc être relié qu'à un canal qui implémente la même interface. En pratique, tout ceci est caché, car on utilise souvent des ports spécialisés pour chaque type de signal.

La plupart des ports sont destinés à être connectés à des signaux. Ils possèdent donc les méthodes des interfaces propres aux signaux (read, write, event, ...). Lors de l'appel du la méthode read d'un port, tout ce que fait ce port c'est de forwarder cet appel à la méthode read du signal auquel il est relié.

Règles de connexion

Les ports sont soumis à des règles de connexion :

à l'extérieur du module, ils sont obligatoirement reliés à un canal ou à un port du module parent. On peut éventuellement les relier à plusieurs canaux, ce qui est bien pratique quand on fait un module qui modélise un bus.
De ce côté-là du module, on ne peut pas y accéder directement, on doit passer par le canal qui y est connecté.
à l'intérieur du module, on a le choix : soit on les relie à un canal et on y accède par l'intermédiaire de ce canal, soit on accède directement à leurs méthodes. De toutes façons, un port héritant d'une interface de canal, il est vu à l'intérieur du module comme le canal auquel il est relié (plus précisément, il donne aux méthodes de ce canal qui sont définies dans l'interface).
un port ne peut pas être connecté à rien : cela produit une erreur à la simulation.

Les deux première règles sont des conventions SystemC. Les classes ont été écrites avec cette convention en tête, et fournissent des mécanismes pour essayer de vérifier (soit à la compilation, soit lors de l'exécution) que le programmeur les a bien respectées. Mais il n'est pas possible d'en faire une vérification totale. Il est donc possible de les transgresser, mais ce n'est vraiment pas une bonne idée !

Spécialisés ou pas ?

Quand on déclare un port on a le choix :

soit on déclare son port à la main, en le faisant hériter d'une interface spécifique,
soit on utilise un type de port spécialisé pour le signal auquel il est destiné à être relié. Cette deuxième solution est souvent la moins verbeuse, et les ports spécialisés fournissent aussi des méthodes additionnelles facilitant la vie. SystemC fournit des ports spécialisés pour les signaux et les fifo. Pour les autres canaux, il faudra prendre la solution manuelle.

Port normal

C'est la solution la plus compliquée... Tant mieux, la prochaine façon de faire n'en sera que meilleure ! :)

Avant de faire une déclaration manuelle, il faut connaitre le nom de l'interface du canal qui lui sera connecté. Pour les canaux prédéfinis, les interfaces sont disponibles à la section interfaces.

Syntaxe : sc_port<interface_type, N> port_name, port_name,... ;

interface_type est le nom de l'interface

N est le nombre maximal de canaux qui pourront être connectés à ce port. 0 signifie "illimité". S'il n'est pas précisé, il vaut 1.

port_name est le nom du port

Pour accéder au canal qui lui est relié, on utilise l'opérateur -> .
Si un port est relié à plusieurs canaux, on utilise l'opérateur [] pour spécifier auquel on s'adresse.

Exemple de déclaration :

Exemple d'utilisation de ces ports :

Utilisation de ports spécialisés

Quand un port est relié à un signal ou une fifo, il existe des types de ports spécialisés, plus simples à instancier :

Type du canal Entrée Sortie Bidir

sc_signal, sc_buffer
sc_in

sc_out

sc_inout

sc_signal_rv

sc_in_rv

sc_out_rv

sc_inout_rv

sc_signal_resolved

sc_in_resolved

sc_out_resolved

sc_inout_resolved

sc_fifo

sc_fifo_in

sc_fifo_out
(pas de sens)

Exemple : le type sc_in<T> est équivalent à sc_port<sc_signal_in_if<T>, 1> .

On accède à ces types de port non pas par l'opérateur -> mais directement par l'opérateur "." .

Exemple :

Remarque : les anciennes versions de SystemC définissaient trois types spéciaux pour des horloges. Ces types sont maintenant obsolètes :

typedef sc_in<bool> sc_in_clk
typedef sc_out<bool> sc_out_clk
typedef sc_inout<bool> sc_inout_clk

En résumé :

Les ports sont les moyens pour faire communiquer l'intérieur d'un module avec l'extérieur.

A l'extérieur du module, ils sont soit reliés à un canal, soit directement à un port du module parent.

On peut les instancier à la main, avec la classe sc_port<>, mais le moyen le plus simple est d'utiliser des classes dédiées : des ports spécialisés pour un type de canal.

Les principaux ports spécialisés sont :

pour un sc_signal : sc_in, sc_out et sc_inout

pour un sc_signal_resolved : sc_in_resolved, sc_out_resolved et sc_inout_resolved

pour un sc_signal_rv : sc_in_rv, sc_out_rv et sc_inout_rv

On accède aux fonctions d'un port normal par "->" s'il est instancié à la main.
On accède aux fonctions d'un port spécialisé par "."

Maintenant qu'on connait les canaux et les ports, on peut rassembler le tout dans des modules. C'est l'objectif de la prochaine section.

Back to top

Les modules

Les modules en SystemC sont similaires aux modules de Verilog et VHDL. Ce sont les blocs structurels de base à l'intérieur desquels sont instanciés d'autres modules, des signaux, des canaux et des processus.

Les modules peuvent contenir les éléments suivants :

des ports, pour la communication avec l'extérieur
des canaux, pour la communications entre processus
des processus,
des instances d'autres modules ,
des variables,
des méthodes,
un ou plusieurs constructeurs

La déclaration d'un module se fait, de façon équivalente,

soit à la main, en faisant dérivant de la classe sc_module : class mon_module : public sc_module { ... }
soit un utilisant la macro SC_MODULE qui rend le code plus lisible : SC_MODULE(mon_module) { ... }

Constructeur

Comme toute classe C++, un module possède un constructeur. Le rôle du constructeur est de faire toutes les initialisations dont l'objet a besoin :

donner une valeur par défaut aux variables
appeler quelques fonctions (méthodes) pour pré-calculer des choses, ou s'enregistrer auprès d'autres objets, ...

Le passage de paramètres au constructeur d'un module est typiquement la méthode qu'on utilise pour paramétrer un objet lors de son instanciation.

Le constructeur d'une classe C++ est une méthode (fonction) particulière qui porte le même nom que sa classe et n'a aucun type. On peut le déclarer de deux façons :

Déclaration manuelle (explicite)

Comme d'habitude on regarde la solution la plus compliquée en premier...

Le constructeur d'un module se déclare comme un constructeur normal, en gardant à l'esprit qu'un de ses paramètres doit être de type sc_module_name : c'est le nom du module, qui sera utilisé par SystemC pour construire une hiérarchie des modules instanciés et produire éventuellement des messages de débug compréhensibles par les humains. Ce paramètre doit être transmis au constructeur de la classe de base (sc_module).

De plus, si le module contient des processus, il faut ajouter à la déclaration du module la macro SC_HAS_PROCESS, qui définit des symboles spéciaux utilisés par le scheduler SystemC.

Exemples :

On définit un module qu'on appelle mon_module, et on écrit son constructeur à la main. On utilise ici la syntaxe C++ qui appelle le constructeur de la classe de base en lui passant le paramètre name. Remarque : ici on aurait pu utiliser la deuxième méthode (voir plus loin) !

On définit maintenant un autre module, qu'on appelle memoire, en écrivant toujours son constructeur à la main. Mais ici on n'a pas le choix, car on va passer un argument supplémentaire au constructeur : le nom d'un fichier pour initialiser la mémoire.

Déclaration par macro SC_CTOR

Si on ne passe pas d'argument supplémentaire au constructeur, on peut utiliser une macro bien pratique : SC_CTOR, qui prend en argument le nom du module.
La macro SC_CTOR se charge d'appeller SC_HAS_PROCESS.

Le premier exemple (cf ci-dessus) s'écrit alors :

Ce qui est quand même un peu moins verbeux.

Instanciation des éléments

Maintenant que le module a son constructeur, il faut instancier les variables, méthodes, sous-modules, canaux, processus, ... Le cas des processus sera vu au prochain chapitre. Occupons-nous pour l'instant des éléments structurels (canaux, sous-modules).

Comme d'habitude en C/C++, les variables (au sens large) peuvent être instanciées de façon statique ou dynamique. C'est aussi le cas en SystemC.

La déclaration statique des objets se fait comme vu aux sections précédentes. Les objets instanciés sont alors des membres (des variables) du module.
Prenons l'exemple du compteur, et rajoutons-lui un registre en sortie (qu'on a déclaré sous le nom reg8) :

On peut aussi déclarer les objets internes dynamiquement : ce seront en fait des pointeurs vers les objets correspondant. C'est alors le constructeur qui se chargera d'allouer les objets. Bien sûr il ne faudra pas oublier de libérer la mémoire à la fin de vie du module : un bon endroit pour le faire serait dans le destructeur.

Le même exemple, en dynamique (le destructeur n'apparait pas) :

Connexion des ports des sous-modules

Dernière étape à la création des modules, la connexion des ports des sous-modules.

Cela se fait en appelant la méthode "port_du_sous_module", en lui passant en argument le signal auquel il est relié. Un bon endroit pour le faire est encore le constructeur !

Exemple :

pour relier le port clk d'un sous-module reg8 à un signal clock, on appelle : reg8.clk(clock);
en reprenant le dernier exemple, le module reg8 est connecté comme indiqué ci-dessous :

En résumé :

Les modules sont les blocs structurels de base de SystemC. Ils peuvent contenir des canaux, des sous-modules, des variables, des méthodes, des processus...

On les déclare grâce à la macro SC_MODULE, qui prend en argument le nom (la classe) du module à déclarer.

On instancie les éléments internes du module comme des membres (variables) de la classe. A part les ports, ils peuvent être créés soit statiquement, soit dynamiquement (new).

Le constructeur, généralement écrit par la macro SC_CTOR, se charge d'allouer les objets dynamiques, et de relier les signaux internes aux sous-modules.

Ceci clôt le chapitre sur les modules. Passons à un bref résumé du chapitre avant d'attaquer la suite.

Back to top

En résumé

Vous savez donc maintenant déclarer un module, déclarer son constructeur, déclarer et instancier les éléments qui le composent (à part les processus), et les relier entre eux.

Vous connaissez aussi ses éléments structurels (canaux, ports, interface), leur rôle et leurs intercations.

Il ne reste plus qu'à voir comment écrire les processus, et vous pourrez écrire vos propres modèles SystemC. C'est l'objectif du prochain chapitre !

Back to top

Type du canal	Entrée	Sortie	Bidir
sc_signal, sc_buffer	sc_in	sc_out	sc_inout
sc_signal_rv	sc_in_rv	sc_out_rv	sc_inout_rv
sc_signal_resolved	sc_in_resolved	sc_out_resolved	sc_inout_resolved
sc_fifo	sc_fifo_in	sc_fifo_out	(pas de sens)

Cours en ligne SystemC