Synthèse d un élément de routage en SystemC

Synthèse d un élément de routage en SystemC RETICOM/CETIC pierre-olivier.danhaive@cetic.be olivier.gillin@cetic.be lotfi.guedria@cetic.be damien.hubaux@cetic.be 8 octobre 2003 1 Objectif du TP L objectif de ce TP est de se familiariser à la conception en langage SystemC à travers le développement d une application. Il s agit d implémenter un module (traitement et communication) au sein d un système prédéfini. Le travail consistera à développer le module, le compiler, le simuler, et finalement le synthétiser en hardware. 1.1 Ce qui est fourni Une description générale du système Une spécification du module à réaliser : interfaces et fonctionnalités Les fichiers de base et les indications nécessaires au développement (template de Makefile, commandes de synthèses, configuration de l environnement...) 1.2 Ce qui est demandé Fournir un code source documenté et fonctionnel Un compte-rendu du TP détaillant votre travail : FSM, interfaces, simulations, synthèse, particularités...ce rapport devra expliquer les limitations du système, les étapes fonctionnelles et non fonctionnelles implémentées, mais ne devra pas dépasser 5 pages. 2 Spécification du système 2.1 Description du système Le système est constitué d un émetteur de trames et de deux récepteurs entre lesquels vous allez insérer votre module de filtrage (fig. 1). Tous ces modules font partie du module testbench. Comprenez bien que la spécification qui vous est fournie ne porte que sur le module filter, tous les autres modules fournis ne sont qu un environnement de test, et ne doivent donc pas être synthétisés. Il faut voir l environnement testbench comme une plaquette de test, comprenant 1

sop eop avbl data enbl sop_in eop_in avbl_in data_in enbl_out eop2_out avbl2_out data2_out sop2_out enbl2_in sop1_out eop1_out avbl1_out data1_out enbl1_in sop eop avbl data enbl sop eop avbl data enbl avbl_ef eop_ef sop_ef data_ef enbl_fr1 data_fr1 avbl_fr1 eop_fr1 sop_fr1 enbl_fr2 data_fr2 avbl_fr2 eop_fr2 sop_fr2 Testbench enbl_ef clk reset reset clk reset clk clk reset Emitter Filter Receiver1 Receiver2 Clock Reset Fig. 1 Schéma-bloc général 2

Fig. 2 Protocole utilisé déja une horloge, un générateur de signal reset, un circuit émetteur, deux circuits de réception et un emplacement entre eux pour y insérer le FPGA que vous aurez programmé pour qu il implémente votre filtre. La communication entre modules s effectue selon le protocole présenté à la figure 2 : La taille des trames transmises est variable. Le début de trame est signalé par un signal SOP (Start Of Packet), la fin par un signal EOP (End Of Packet). Le signal AVBL indique que la donnée est valide. Le signal ENBL précise que la donnée a bien été acceptée. Le bus de données DATA est de largeur 8 bit. Les trames sont codées comme suit(fig. 4) : 2 bytes d index Les paquets émis par l émetteur sont numérotés de manière croissante sur 16 bits. Le byte de poids faible est émis en premier lieu, ensuite l émetteur transmet le byte de poids fort. 1 byte de routage Le troisième byte de la trame est généré aléatoirement et est destiné au routage. Si son MSB est égal à 0, il est destiné au premier récepteur, sinon il doit aller au second récepteur (voir sous-section 3.1). x bytes de payload Un nombre aléatoire de bytes de données est émis ensuite. La longueur totale de chaque trame est comprise entre 10 et 40. 1 byte de checksum Le dernier byte du paquet est une somme de contrôle qui est le complément à deux de la somme sur 8 bits de tous les bytes du paquet. Ceci est valable pour le cas complet. Cependant, la première version demandée implémentera un routage sur le premier byte. Le byte de routage se trouvera donc en tête de paquet et sera suivi des deux bytes d index de paquet (fig. 3). 2.2 Le module à réaliser Selon le temps disponible et l avancement du TP, l implémentation du module filtre se fera en plusieurs étapes de complexité croissante. En fonction du type de module testé, il ne faut pas oublier de passer correctement les paramètres aux constructeurs des récepteurs pour les désactiver ou les activer dans le mode adapté. Le résultat minimum à atteindre est le module routeur sur le premier byte dans une transmission parfaite (2.2.2). Cette étape est relativement 3

Route Index1 Index2 Payload1 Payload2 PayloadX Checksum Fig. 3 Trames utillisées (cas simple) Index1 Index2 Route Payload1 Payload2 PayloadX Checksum Fig. 4 Trames utillisées (cas complexe) simple à atteindre et représente approximativement la moitié du travail complet. Le résultat souhaité est un module routeur sur premier byte avec prise en charge des imperfections des émetteurs et récepteurs, et vérification/correction du checksum (2.2.3). L implémentation idéale, mais de difficulté plus élevée est un routage sur le troisième byte avec vérifcation du checksum (2.2.4) 2.2.1 Module transparent Le module n effectuera aucun traitement, et n implémentera pas le protocole. Il s agira donc simplement d une fonction combinatoire recopiant les entrées sur les sorties. Il est important que ce module soit en logique combinatoire pour ne pas introduire de délais sur les lignes, ce qui provoquerait des incohérences dans le protocole. Les deux récepteurs seront connectés, mais l un des deux doit être configuré pour recevoir toutes les trames alors que l autre ne doit pas en recevoir. L objectif de ce module est que vous puissiez tester vos fichiers d en-tête, manipuler les options du testbench et apprendre la syntaxe de base de SystemC. Une heure devrait suffire pour arriver à ce point. 2.2.2 Module routeur, routage sur le premier byte, émetteur et récepteurs idéaux Ce module implémentera simplement les protocoles de communication avec l émetteur et les récepteurs afin de véhiculer les trames. L émetteur et les récepteurs sont idéaux, ce qui signifie qu ils seront disponibles à tout moment (ENBL et AVBL à 1). Dans ce mode, le module à réaliser analysera le contenu du premier octet de la trame et suivant la valeur de celui-ci (MSB=0 destine le paquet au récepteur 1, MSB=1 le destine au récepteur 2) transmettra la trame vers l un ou l autre des modules de réception. Pour simplifier ce cas, nous avons laissé une option sur le byte de routage : la configuration des paquets peut être changée en mettant le byte de routage en première ou en troisième position dans le paquet. Il est bien sûr nécessaire pour cela de changer l option adéquate dans testbench.cpp. 2.2.3 Module routeur avec test d une somme de vérification, routage sur le premier byte Ce module, en plus des fonctionnalités du précédent, calculera à la volée la somme de vérification sur la trame reçue de l émetteur et la comparera avec le 4

byte de checksum reçu. Si le checksum est mauvais, il doit être corrigé avant d être transmis aux récepteurs. La somme de vérification est codée sur 8 bits et égale au complément à 2 de la somme de tous les octets de la trame. L émetteur dispose d une option de constructeur lui indiquant s il doit générer des paquets corrects ou s il peut introduire des erreurs aléatoires de checksum. Ce module se fera toujours avec routage sur le premier byte. De plus, les modules d émission et de réception ne sont plus optimaux, le récepteur peut demander un délai (ENBL=0), et l émetteur peut être indisponible (AVBL=0). Le filtre doit réagir correctement pour ne pas perturber le protocole ni perdre de paquets. Ceci est le résultat normal à atteindre (avec prise en compte plus ou moins bonne des imperfections de transmission et de la correction du checksum). On peut estimer que vous aurez une connaissance de base en conception de machine à états en SystemC si vous arrivez à ce point. 2.2.4 Module routeur avec test d une somme de vérification, routage sur le troisième byte Le module complet. La grande difficulté réside dans le fait que le byte de routage se situe en troisième position, le reste étant identique à l étape précédente. Il est donc nécessaire d implémenter un buffer dans le filtre et de le gérer correctement, ce qui augmente la difficulté du problème. Ceci constitue le résultat idéal à atteindre et n est donc demandé que dans un souci de perfection... 3 Déroulement du TP Les différentes étapes à réaliser lors de ce TP sont : Décrire en systemc le module à réaliser et faire les adaptations nécessaires dans les fichiers testbench.cpp et main.cpp Compiler le projet Débugger, simuler et visualiser les waveforms (avec GTKwave) Expérimenter la synthèse hardware du module en suivant les directives fournies ci-dessous. 3.1 Fichiers de support fournis Fichiers objets : les modules d émission et de réception emitter.o et receiver.o Fichiers d en-tête : les interfaces sont fournies à titre indicatif dans les fichiers emitter.h et receiver.h Fichiers template du testbench : ces deux fichiers (testbench.h et testbench.cpp) sont fournis pour agencer les éléments de la simulation Fichier principal : ce fichier (main.cpp )est fourni pour permettre de personnaliser le contrôle de la simulation, générer les fichiers de waveforms... Fichier de compilation : les directives et options de compilations sont fournies dans le fichier Makefile 5

3.1.1 Fichier principal Le fichier principal de compilation main.cpp contient la fonction sc main, initialise les paramètres fonctions des options données en ligne de commande, instancie le tesbench, puis lance la simulation en activant le traçage dans le fichier de simulation. Les options que peut prendre le fichier exécutable sont (l ordre a une importance) : SimuTime (int) indique le nombre de cycles d horloge que durera la simulation. Par défaut, elle contient la valeur 10000 (en µs). TraceWaveForm (int) trace un fichier de simulation template.vcd si égale à 1. Valeur par défaut : 1. TraceOnScreen (int) affiche tous les messages d erreurs ou de commentaires générés par les modules (émission de paquets, réceptions erronées...). Par défaut : 1. RandomSeed (int) permet d initialiser le générateur de nombres aléatoires. Ainsi pour lancer plusieurs simulations dont les nombres aléatoires (longueur de paquets, bytes de routage...) sont identiques, il suffit de garder ce paramètre fixe. Sa valeur par défaut est l heure courante. 3.1.2 Le testbench Ce fichier instancie les différents modules de la simulation, et en relie les ports. L instanciation des modules se fait avec passage de paramètres, c est donc dans ce fichier que vous devrez indiquer les types d émetteurs et de récepteurs que vous désirez. Il génère également le signal d horloge et de reset. Lors de sa contruction, il exécute le thread reset process, qui envoie à tous les modules un signal de reset pendant quelques cycles. 3.1.3 Les récepteurs Les récepteurs ont comme paramètre de constructeur (réglable dans testbench.cpp) les variable RecType1, RecType2 et Route1 qui indiquent leurs comportements : RecTypeX = 0 indique que le récepteur est sensé ne rien recevoir, il affichera un message d erreur s il reçoit des trames. Ce mode sera utilisé dans le mode de transmission transparente à un seul récepteur. RecTypeX = 1 indique que le récepteur est sensé recevoir toutes les trames. Utilisé en mode transparent à un seul récepteur RecTypeX = 2 indique que le récepteur n est sensé recevoir que les trames dont le byte de routage (le premier ou le troisième en fonction de Route1) est inférieur à 128. RecTypeX = 3 indique que le récepteur n est sensé recevoir que les trames dont le byte de routage (le premier ou le troisième en fonction de Route1) est supérieur ou égal à 128. Route1 = 0 indique que le routage se fera sur le troisième byte Route1 = 1 indique que le routage se fera sur le premier byte Il est à noter que les récepteurs sont programmés pour simuler aléatoirement des buffer overloads, ce qui signifie qu ils mettront aléatoirement leurs sortie ENBL à 0. 6

3.1.4 L émetteur L émetteur prend comme paramètre à la construcion la variable Checksum. Lorsque cette valeur est à 1, l émetteur envoie aléatoirement des trames dont le checksum est corrompu. De plus, et dans tous les cas, l émetteur simule aléatoirement des retards de transmission, en passant sa sortie AVBL à 0 et en plaçant sur le bus une valeur aléatoire. L émetteur est lui aussi sensible au paramètre Route1 (voir 3.1.3). 3.2 Directives de synthèse hardware Cette étape est optionnelle, mais permet de vérifier si le module implémenté est synthétisable, c est-à-dire prêt à être mis tel quel dans un FPGA. L objectif est d obtenir un fichier edif qui est un format standard de description de circuit. Pour y arriver, il sera nécessaire de vérifier certaines contraintes sur le code et éventuellement modifier certains détails. Voici la succession d étapes à réaliser pour synthétiser un système en SystemC RTL dans le dc shell de Synopsis : Définir les librairies de synthèse : target library = { tc6a cbacore.db } synthetic library = { dw01.sldb, dw02.sldb } link library = { * } + target library + synthetic library Convertir de SystemC vers Verilog (VHDL pas encore supporté). (Pour information, ce fichier Verilog pourrait aussi être utilisé par d autres outils de synthèse) : compile systemc -rtl exercice filter/filter.cpp -rtl format verilog Ajouter le répertoire de travail au chemin de recherche : Analyser et elaborer : search path = search path +./rtl work hdlin enable presto = true hdlin unsigned integers = false analyze -f verilog filter.v elaborate filter Compiler : create clock clock -p 10 link compile -map effort low 7

Convertir au format «edif» pour exporter le design vers un autre outil (par exemple Quartus ou Xilinx ISE pour faire le placement-routage dans un FPGA) : edifout netlist only = true ; write -format edif -hierarchy -output rtl work/ + filter.edif Pour information : affichage surface et chemin critique : 4 Tuyaux pour le TP report area report timing Afin de faciliter l exercice, voici quelques aides et commentaires pour votre développement. Les spécifications du système doivent être respectées, mais cela ne signifie pas que le code doit être super-optimisé! Si il apparaît plus simple de perdre un ou deux coups d horloge entre deux paquets, nous n y voyons aucun inconvénient. Préférez la simplicité à une optimisation qui vous prendra trop de temps. Dans votre rapport, présentez bien ce qui a été fait, et son fonctionnement complet ( pertes éventuelle de cycles, implémentation des machines à états...) Quand vous déclarez un port ou un signal véhiculant un type de donnée paramétrable (unsigned integer de largeur x bits par exemple), ne collez pas les fermetures de template, sinon le compilateur l interprète comme un opératuer de flux : sc signal<sc uint<8> > et non sc signal<sc uint<8. Cette erreur est courante et extrèmement difficile à détecter, puisque le message d erreur paraît totalement incohérent. Ecrivez d abord complètement vos machines à états avant de les implémenter! Envisagez tous les cas possibles : que se passe-t-il si ENBL et AVBL sont à 0 en même temps? Ou avec un cycle de décalage? Qu arrive-t-il si le récepteur n est pas prêt à l arrivée d un EOP? La progression conseillée dans la complexité des modules peut se faire en une fois. Nous conseillons de tenter tout de suite le module dans le cas non-idéal, quitte à indiquer dans le rapport que seul le cas idéal fonctionne. C est plus simple que de faire d abord un module idéal et d en changer presque tout pour l adapter aux imperfections du réseau. Utilisez correctement les paramètres de constructeurs des modules, ils permettent un grande flexibilité dans les tests de configuration! Nous en avons nous-mêmes abusé pour le développement de l exercice. Classique : commentez abondamment et intelligemment vos sources. Le développement du module transparent est simplissime! Il contient un process combinatoire, c est-à-dire qu il doit être sensible à toutes ses entrées! (Il devrait ressembler au listing 1). Une erreur qui survient souvent : faire une opération sur un signal ou un port peut être ambigue pour le compilateur. Pensez à utiliser les fonctions mon signal.read() et mon signal.write(ma donnée) en passant par une variable intermédiaire. 8

2 #include f i l t e r. h 4 void mon module : : mon process ( ) { 6 sop1 out=s o p i n ; eop1 out=e o p i n ; 8 a v b l 1 o u t=a v b l i n ; data1 out=d a t a i n ; 10 e n b l o u t=e n b l 1 i n ; } 12 SC CTOR{ mon module} 14 { SC METHOD( mon process ) ; 16 s e n s i t i v e <<clock <<s o p i n <<eop in <<a v b l i n <<d ata in <<e n b l 1 i n ; } Listing 1 Module transparent Comme en VHDL, les signaux ne changent de valeur qu au coup d horloge suivant, pas les variables! Ceci peut causer une confusion lors d un affichage par exemple. Le listing 2 illustre cela. 9

2 s c s i g n a l <s c i n t <8> > m y signal ; // s i g n a l s c i n t <8> my var ; // v a r i a b l e 4 void mon module : : mon process ( ) 6 { my var =4; 8 m y s i g nal. w r i t e ( 4 ) ; cout << my var << my signal << endl ; 10 // a f f i c h e r a 4 4 12 my var=5 m y s i g nal. w r i t e ( 5 ) ; 14 cout << my var << my signal << endl ; // a f f i c h e r a 5 4, l e s i g n a l changera au prochain p o s e d g e 16 } 18 SC CTOR{ mon module} { 20 SC METHOD( mon process ) ; s e n s i t i v e p o s << c l o c k ; 22 } Listing 2 Signaux vs variables 10