Cours en ligne SystemC

Préambule

Objectifs

Vous savez comment écrire un module, que ce soit en terme d'assemblage d'objets plus petits (sous-modules, canaux) ou de fonctionnalité (processus).

Il faut néanmoins être capable de tester un modèle : de le simuler, le débugger. C'est l'objectif de ce chapitre, qui clôt cette formation à SystemC.

Une série d'exercices est donnée à la dernière section. Ces exercices sont obligatoires et seront notés.

Plan du chapitre

1. Contrôle des simulations : comment lancer une simulation, l'arrêter
    
2. Débug : ce n'est pas si simple qu'il y parait...
    
3. Gros projets, petits soucis : les modèles SystemC sont longs à compiler. Et un projet de taille raisonnable se met vite à comporter un nombre déraisonnable de fichiers. Il vaut alors mieux utiliser des Makefile pour se faciliter la vie. Cette section s'adresse uniquement à ceux qui ne maîtrisent pas les Makefile.
    
4. Si la théorie est belle, la pratique l'est encore plus. Des exercices sont prévus, pour préparer entre autres la série de TP sur les SoC qui vont suivre.

La simulation

Nous ne parlerons pas ici de la façon dont on écrit un testbench, vous l'avez déjà vu dans les cours de Verilog et VHDL. Nous allons plutôt nous pencher sur la façon dont on contrôle le scheduler SystemC.

Les bibliothèques SystemC intègrent en standard un simulateur événementiel rapide, qui permet de se passer de simulateur tierce-partie. On peut toujours utiliser Modelsim ou autre, notamment pour cosimuler du SystemC et un autre langage, mais cela implique certains styles d'écriture (se reporter à la documentation de Modelsim pour cela).

Dans la première partie des TP sur les SoC, les simulations ne porteront que sur du SystemC seul. On pourra alors utiliser le simulateur intégré.

Résolution temporelle

Le simulateur natif SystemC est événementiel, et suit le comportement décrit dans le cours sur les HDL. Il procède par delta_cycles, en n'avançant le temps physique que lorsqu'il n'y a plus d'événements notifiés. Comme tous les simulateurs, il possède une résolution minimale : c'est la plus petite unité de temps comprise par le simulateur. Tous les temps spécifiés sont arrondis à des multiples de cette résolution. De même, le temps physique avance par multiple de cette résolution.

Par défaut, la résolution est de 1ps. Il est possible d'en changer, grâce à la fonction sc_set_time_resolution(), qui est un peu l'équivalent des `timescale de Verilog.

Cette fonction prend en argument un nombre (type double) et une unité (SC_PS, SC_NS, ...). Elle a des restrictions :

• la résolution doit être une puissance de 10
• elle ne peut être appelée qu'avant le début de la simulation, et avant toute instaciation d'objets sc_time (non nuls)
• elle ne peut être appelée qu'une seule fois.

Exemple :

 // spécifie une résolution de 10ps
 sc_set_time_resolution(10, SC_PS);
 

 ...
 
 wait(3.456, SC_NS); // sera arrondi à 3,46ns...

Déclaration des horloges

SystemC donne la possibilité de déclarer des horloges. C'est le scheduler qui se charge de les faire marcher. On utilise pour cela le type sc_clock, qui prend en argument :

• une chaîne de caractère spécifiant un nom pour cette horloge
• au moins une période (soit sous la forme d'un sc_time, soit sous la forme d'un couple valeur, unité)
• éventuellement un rapport cyclique, un temps de départ, et sa première valeur.

Exemple :

// instancie une horloge de période 10ns
sc_clock clock1("clk100", 10, SC_NS);

sc_time t10(10, SC_NS);
sc_clock clock2("clk100", t10);

// instancie une horloge 
// de 15 ns de période 15.3ns, 
// de rapport cyclique 40%, 
// démarrant au temps 45ms, 
// et dont le premier état est haut
sc_time tt(45, SC_MS);
sc_clock clock2("clk2", 15.3, SC_NS, 0.4, tt, true);

Les horloges sont généralement instanciées au plus haut niveau, ou dans le générateur de vecteurs de test, et propagées tout le long de la hiérarchie des modules.

On peut déclarer une horloge dans un module, à la condition que : 

• elle soit déclarée et initialisée avant toute utilisation (il faut l'instancier dans le constructeur du module)
• et que, si elle doit sortir du module, ce soit par l'intermédiaire d'un processus sensible à elle et qui pilote le port de sortie. Il est cependant possible de passer par une construction plus simple (sc_export), mais ceci sort du cadre de ce cours.

Hiérarchie, sc_main

Le plus haut niveau d'un système complet (module à tester + génération des vecteurs de test) n'est pas un module, c'est la procédure sc_main, qui est l'équivalent du main des programmes C.

Le véritable main est déjà implémenté dans les bibliothèques SystemC, et on ne doit pas le ré-implémenter. On utilise à la place sc_main, qui a le même prototype : int sc_main(int argc, char *argv[]);

On instancie directement au niveau du sc_main les modules de plus haut niveau, et les canaux qui vont les relier (pas de processus, ils n'existent qu'à l'intérieur des modules).

La génération des vecteurs de test peut se faire :

• soit directement dans le sc_main si elle est simple,
• soit dans un module spécialisé pour cela, si elle est complexe.

C'est principalement une affaire de goût et de bon sens...

Lancement et contrôle de la simulation

Quand tous les modules ont été instanciés et reliés entre eux, on peut lancer la simulation. Pour cela, on utilise la fonction sc_start() depuis le sc_main.

Cette fonction prend en argument un temps, qui est le temps pendant la simulation sera effectuée. Le scheduler SystemC est automatiquement initialisé (si besoin est) et lancé, et s'occupe de générer les horloges et lancer les processus.

Si on souhaite une simulation sans fin, il suffit d'appeler sc_start() sans arguments ou avec un argument négatif.
Si on passe SC_ZERO_TIME comme durée de simulation, alors la simulation dure un delta-cycle.

La simulation peut être arrêtée à n'importe quel moment depuis un processus, en appelant sc_stop().

On peut récupérer aussi à tout moment (depuis un processus) :

• le temps actuel par la fonction sc_time_stamp(), qui renvoie le temps courant sous forme d'un sc_time
• le nombre total de delta-cycles ayant eu lieu depuis le début de la simulation par sc_delta_count(), qui renvoie un entier sur 64 bits
• si la simulation est en train de tourner ou non, par sc_is_running().

Pour des exemples, se reporter au chapitre sur les exemples.

Dans les premiers temps, vos modèles risquent d'être buggés. Il faut alors les débugger. C'est l'objectif de la prochaine section.

Le debug

Un système numérique écrit en SystemC n'étant après tout qu'un programme C++ standard, il est tout à fait possible d'utiliser les moyens habituels de debug des programmes C++ :

• printf() : cette méthode semble archaïque, pourtant elle fonctionne... Mais SystemC propose un mécanisme plus simple, et plus adapté.
   
• utiliser un débogueur : si cette solution est utilisable parfois, elle a un inconvénient majeur. Le scheduler SystemC est multi-thread, au sens Unix du terme. En d'autres termes, il est très difficile de suivre le déroulement du programe, comme on a l'habitude de le faire dans un programme mono-thread. Cela impose de poser des points d'arrêt à des endroits stratégiques, car le pas-à-pas en dehors des processus est impossible. Cette méthode est réservée aux spécialistes des programmes multi-threadés.
   
• utiliser les traces : SystemC permet de suivre l'évolution des signaux et variables standards C++ en générant des chronogrammes. Les chronogrammes peuvent alors être visionnés par gtkWave par exemple. C'est sans doute la meilleure solution, au moins pour les débuts en SystemC.

La génération de trace se fait en ouvrant un fichier de chronogramme en écriture. On peut en ouvrir autant qu'on veut, et chaque signal peut être tracé en même temps dans autant de fichiers qu'on le souhaite. Cela est fait par la commande sc_create_vcd_trace_file(), qui prend en argument un nom de fichier, et renvoie un file descriptor spécial, de type sc_trace_file*.

On spécifie les signaux à tracer par la fonction sc_trace(), qui prend en argument :

• un pointeur vers le fichier de trace (celui renvoyé par sc_create_vcd_trace_file)
• une référence à (ou un pointeur vers) la variable ou le signal à tracer
• un nom explicite, qui sera utilisé par le visionneur de chronogrammes.

Exemple:

  sc_signal<int> data;
  float b;
  
  sc_trace_file * trace_file;

  trace_file = sc_create_vcd_trace_file("out.vcd");
 
  sc_trace(trace_file, a, "mes_data"); 
  sc_trace(trace_file, b, "B");
  

Les appels à sc_trace et sc_create_vcd_trace_file doivent être faits avant le début de la simulation. Par exemple dans sc_main, ou dans le constructeur d'un module...

A la fin de la simulation, il faut appeler sc_close_vcd_trace_file pour fermer le fichier de trace (et forcer le vidage des tampons).

Gros projets, petits soucis : les Makefile

Cette section n'est pas détaillée, les Makefile ayant été étudiés en cours d'informatique.

Si, par hasard, cette partie des cours d'informatique n'avait pas été totalement comprise, je vous conseille de vous reporter à l'excellent cours de Fabrice Derepas, qui couvre C++, les Makefile ainsi que SystemC.

En attendant, je vous propose un Makefile type, que vous pourrez adapter à vos projets, qui devrait convenir aux machines du département COMELEC. Pour l'utiliser chez vous, pensez à modifier le chemin d'installation de SystemC et, éventuellement, à remplacer "linux64" par "linux".

Exercices

Ces exercices sont à rendre, avant la fin de la semaine. Ils sont notés.

Les fichiers déposés sur Git doivent être indentés et commentés, en français ou anglais au choix.

PGCD

Le but de cet exercice est de construire un module calculant le PGCD de deux entiers non signés sur 8 bits.

Ce module sera appelé PGCD, et possède les ports suivants :

port	direction	largeur (bit)	type	description
clk	in	1	sc_in<bool>	horloge du module
x	in	8	sc_in<unsigned char>	premier entier
y	in	8	sc_in<unsigned char>	deuxième entier
pgcd	out	8	sc_out<unsigned char>	pgcd(x,y). valide au moins pendant que done==1
start	in	1	sc_in<bool>	enable est mis à 1 pendant un cycle. Le module doit échantilonner x et y quand enable==1, et commencer à calculer leur PGCD
done	out	1	sc_out<bool>	done vaut zéro en général, et 1 pendant un cycle quand le PGCD a été calculé. Pendant que done est haut, le PGCD est présenté sur la sortie pgcd.

 

1) Écrire un modèle de haut niveau de ce module (proche de l'algorithme). Ce modèle doit doit en plus permettre de voir que le temps de calcul dépend des valeurs des données en entrée.

2) Écrire un modèle "synthétisable" de ce module. On l'implémentera sous forme d'une machine à état et d'un chemin de donnée.

3) Écrire un module de test de ce module, appelé test_PGCD. Le test doit être suffisamment précis, voire exhaustif si possible.

ps. Vous pouvez utiliser le modèle haut niveau comme réference pour tester le modèle synthétisable.

Généricité en SystemC

Vous connaissez les principes de la généricité, et comment elle est implémentée en Verilog et/ou VHDL.

Proposez deux moyens de l'implémenter en SystemC, et détaillez pour chaque moyen les avantages et inconvénients.