Changes between Version 22 and Version 23 of SoclibCourseTp1
- Timestamp:
- Sep 22, 2009, 1:30:17 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SoclibCourseTp1
v22 v23 22 22 le résultat. Ces deux composants matériels fonctionnent en parallèle, et communiquent entre eux par des canaux de communication de type FIFO. 23 23 24 [[Image(soclib_tp1_ fig1_archi.png)]]24 [[Image(soclib_tp1_archi.png)]] 25 25 26 26 Conformément aux principes CFSM, ces deux composants sont donc modélisés par deux automates synchrones (c'est à dire cadencés par la même horloge CK). L'écriture dans les tous les registres du système se fait sur le front montant de CK. Ils sont initialisés par le même signal RESETN, actif à l'état bas. … … 30 30 Le canal de communication FIFO implante un protocole de communication très simple supportant le contrôle de flux. 31 31 32 [[Image(soclib_tp1_fi g2_fifo.png)]]32 [[Image(soclib_tp1_fifo.png)]] 33 33 34 34 Chacune des deux entités communicantes considère que son interlocuteur est une simple FIFO. Une FIFO est une mémoire double accès de type First-In-First-Out sans adressage explicite. Le producteur peut écrire dans la FIFO en activant le signal W. L'écriture est effective lorsque la FIFO n'est pas pleine (WOK peut être considéré comme un signal d'état signifiant FIFO non pleine). Le producteur peut lire une donnée dans la FIFO en activant le signal R. La lecture est effective lorsque la FIFO n'est pas vide … … 42 42 Il n'y a évidemment qu'un seul émetteur par signal, et la valeur des signaux échangés ne dépend que de l'état interne de l'émetteur. 43 43 44 == 2.2 Composant ''fifo_ lcd_coprocessor'' ==44 == 2.2 Composant ''fifo_gcd_coprocessor'' == 45 45 46 46 L'algorithme de calcul du PGCD implanté par cet automate cablé peut être décrit par le code C suivant : 47 47 {{{ 48 uint32_t lcd( uint32_t opa, uint32_t opb)48 uint32_t pgcd( uint32_t opa, uint32_t opb) 49 49 { 50 50 while (opa != opb ) … … 61 61 Par ailleurs l'automate cablé reçoit les deux valeurs des opérandes OPA et OPB sur son port FIFO d'entrée, et renvoie le résultat sur son port FIFO de sortie. 62 62 63 Finalement, l'automate qui contrôle le composant `fifo_ lcd_coprocesseur` exécute un boucle infinie, dans laquelle il effectue successivement les 4 opérations suivantes:63 Finalement, l'automate qui contrôle le composant `fifo_gcd_coprocesseur` exécute un boucle infinie, dans laquelle il effectue successivement les 4 opérations suivantes: 64 64 65 65 1. lecture de l'opérande A sur son port FIFO d'entrée … … 70 70 Ces quatres opérations ont des durées d'exécution variables, puisque le nombre de cycles pour effectuer le calcul 71 71 (étape 3) dépend de la valeur des opérandes, et que les opérations de communications (étapes 1, 2 ou 4) ont des durées 72 qui dépendent de la disponibilité du composant fifo_ lcd_master.73 74 [[Image(soclib_tp1_ fig3_coprocessor.png)]]72 qui dépendent de la disponibilité du composant fifo_gcd_master. 73 74 [[Image(soclib_tp1_coprocessor.png)]] 75 75 76 76 Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle donc deux autres registres ''r_opa'' et ''r_opb'' … … 81 81 * Dans l'état '''DECR_A''' (resp. '''DECR_B'''), on écrit le dans le registre ''r_opa'' (resp. ''r_opb''). On ne reste qu'un cycle dans ces états, puisque la décrémentation ne dépend d'aucune condition extérieure. 82 82 83 == 2.3 Composant ''fifo_ lcd_master'' ==83 == 2.3 Composant ''fifo_gcd_master'' == 84 84 85 85 Ce composant matériel effectue le travail normalement effectué par un processeur programmable, consistant à générer les valeurs des deux opérandes, à transmettre ces valeurs d'entrée au coprocesseur, à récupérer le résultat calculé par le coprocesseur, et à afficher ce résultat sur un terminal. L'utilisation de processeurs programmables suppose qu'on est capable de déployer le code binaire exécutable par le processeur programmable sur l'architecture matérielle simulée. … … 94 94 mais pour faciliter le deboguage, on garantit un fonctionnement reproductible, en contrôlant la valeur initiale du générateur aléatoire grace à la fonction ''srand()'' utilisée dans le constructeur du modèle. 95 95 96 Le composant ''fifo_ lcd_master'' est donc un composant matériel paramètrable (un paramètre permettant de contrôler96 Le composant ''fifo_gcd_master'' est donc un composant matériel paramètrable (un paramètre permettant de contrôler 97 97 la séquence de valeurs aléatoires), modélisé comme un automate à 5 états : 98 98 99 [[Image(soclib_tp1_ fig4_master.png)]]99 [[Image(soclib_tp1_master.png)]] 100 100 101 101 Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle 5 autres registres : les registres ''r_opa'', ''r_opb'', et ''r_res'' permettent de stocker respectivement les deux opérandes et le résultat du calcul. Le registre … … 119 119 * ''fifo_signals.h'' : fichier définissant l'objet C++ '''!FifoSignal''' représentant les signaux d'un canal FIFO. Ce fichier est complet et ne doit pas être modifié. 120 120 * ''fifo_ports.h'' : fichier définissant les objets C++ '''!FifoInput''' et '''!FifoOutput''' représentant les ports d'accès à un canal FIFO. Ce fichier est complet et ne doit pas être modifié. 121 * ''fifo_ lcd_master.h'' : fichier définissant l'objet C++ '''!FifoLcdMaster''' représentant le modèle du master. Ce fichier est complet et ne doit pas être modifié.122 * ''fifo_ lcd_master.cpp'' : fichier contenant l'implémentation C++ des méthodes utilisées par le composant master. Ce fichier est complet et ne doit pas être modifié.123 * ''fifo_ lcd_coprocessor.h'' : fichier définissant l'objet C++ '''!FifoLcdCoprocessor''' représentant le modèle du coprocesseur. Ce fichier ne contient qu'une carcasse vide et devra être complété.124 * ''fifo_ lcd_master.cpp'' : fichier contenant l'implémentation C++ des méthodes utilisées par le composant master. Ce fichier ne contient qu'une carcasse vide et devra être complété.121 * ''fifo_gcd_master.h'' : fichier définissant l'objet C++ '''!FifoGcdMaster''' représentant le modèle du master. Ce fichier est complet et ne doit pas être modifié. 122 * ''fifo_gcd_master.cpp'' : fichier contenant l'implémentation C++ des méthodes utilisées par le composant master. Ce fichier est complet et ne doit pas être modifié. 123 * ''fifo_gcd_coprocessor.h'' : fichier définissant l'objet C++ '''!FifoGcdCoprocessor''' représentant le modèle du coprocesseur. Ce fichier ne contient qu'une carcasse vide et devra être complété. 124 * ''fifo_gcd_master.cpp'' : fichier contenant l'implémentation C++ des méthodes utilisées par le composant master. Ce fichier ne contient qu'une carcasse vide et devra être complété. 125 125 * ''tp1_top.cpp'' : fichier C++ décrivant l'architecture matérielle du système, dont la compilation générera le simulateur proprement dit. Ce fichier est partiellement incomplet, et devra être complété. 126 126 … … 130 130 131 131 Le modèle de simulation d'un composant matériel (appelé ''module'' en SystemC) nécessite la définition d'une classe C++ dont le nom correspond au nom du module matériel modélisé. 132 En vous inspirant du code fourni pour le composant '''master''', complêter les deux fichiers ''fifo_ lcd_coprocessor.h'' et133 ''fifo_ lcd_coprocessor.cpp''.134 135 Comme pour tout modèle CABA SoCLib, les variables membres de la classe `Fifo LcdCoprocessor` sont de trois types :132 En vous inspirant du code fourni pour le composant '''master''', complêter les deux fichiers ''fifo_gcd_coprocessor.h'' et 133 ''fifo_gcd_coprocessor.cpp''. 134 135 Comme pour tout modèle CABA SoCLib, les variables membres de la classe `FifoGcdCoprocessor` sont de trois types : 136 136 * '''ports''' : les variables membres représentant les ports d'entrée sortie sont de type ''sc_core::sc_in'' ou ''sc_core::sc_out'', ou des objets plus complexe (possédant éventuellement un paramètre template) représentant des regroupements de plusieurs ports élémentaires : c'est la cas des types `soclib::caba::FifoOutput<typename>` et `soclib::caba::FifoInput<typename>` utilisés pour accéder à un cana FIFO. Pour des raisons de lisibilité, il est recommandé que les noms de registre soient préfixé par '''p_'''. On définira 2 ports simples (''p_ck'', ''p_resetn''), et deux ports FIFO (''p_in'' et ''p_out''). Ce sont évidemment des variables publiques. 137 137 * '''registres''' : les variables membres représentant les registres sont de type ''sc_core::sc_signal''. Pour des raisons de lisibilité, il est recommandé que les noms de registre soient préfixé par '''r_'''. On définira trois registres ''r_fsm'', ''r_opa'' et ''r_opb''. Ce sont des variables privées. 138 138 * '''constantes''' : ces variables membres sont en fait des constantes permettant de stocker les valeurs des paramètres définis comme arguments du constructeur pour les composants matériels génériques. Ces variables membres sont initialisées dans le constructeur, et leur valeur reste constante au cours de la simulation. Pour des raisons de lisibilité, il est recommandé que les noms de constantes soient préfixé par '''m_'''. Ces variables sont toujours privées. Le coprocesseur n'étant pas paramètrable, on ne définira aucune variable de ce type. 139 139 140 Le constructeur du coprocesseur LCD ne possède qu'un seul argument, qui est le nom d'instance (on a besoin d'un nom d'instance, car il est possible d'avoir plusieurs instances du même coprocesseur dans une architecture). Ce nom d'instance est de type ''sc_core::sc_module_name'', et il est stoké dans une variable membre de la classe ''sc_module'', qui est une classe générique dont héritent tous les modèles de composant SoCLib.141 142 Enfin, comme tous les modèles CABA de SoCLib, le coprocesseur LCD possède des fonctions membres définissant140 Le constructeur du coprocesseur GCD ne possède qu'un seul argument, qui est le nom d'instance (on a besoin d'un nom d'instance, car il est possible d'avoir plusieurs instances du même coprocesseur dans une architecture). Ce nom d'instance est de type ''sc_core::sc_module_name'', et il est stoké dans une variable membre de la classe ''sc_module'', qui est une classe générique dont héritent tous les modèles de composant SoCLib. 141 142 Enfin, comme tous les modèles CABA de SoCLib, le coprocesseur GCD possède des fonctions membres définissant 143 143 le comportement du composant, qui sont de trois types : 144 144 * la fonction ''transition()'' est sensible au front montant du port d'etrée CK, et permet de calculer la valeur future des … … 147 147 * les fonctions ''genMealy()'' (une ou plusieurs fonction). Chacune de ces fonction est sensible au front descendant du port CK, et à un ensemble particulier de port d'entrée. Elle permettent de calculer la valeur des ports de sorties qui dépendent de façon combinatoire des ports d'entrée. 148 148 Les noms de fonction ne sont pas imposés, mais il est recommandé de respecter les noms proposés ci-dessus. 149 Le coprocesseur LCD se comportant globalement comme un automate de Moore, on n'a pas besoin de définir de fonctions de type ''genMealy()''.149 Le coprocesseur GCD se comportant globalement comme un automate de Moore, on n'a pas besoin de définir de fonctions de type ''genMealy()''. 150 150 151 151 Les architectures matérielles modélisées avec SoCLib peuvent comporter plusieurs dizaines de modèles différents. 152 152 Pour réduire les temps de compilation la plate-forme de modélisation SoCLib exploite le principe de la compilation séparée: Chaque modèle de composant matériel est compilé séparément. 153 153 154 A titre d'exemple, compilez le modèle du composant `Fifo LcdMaster`, en utilisant le compilateur g++.154 A titre d'exemple, compilez le modèle du composant `FifoGcdMaster`, en utilisant le compilateur g++. 155 155 Il faut lancer la commande suivante dans votre répertoire de travail TP1 : 156 156 {{{ 157 $ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o fifo_ lcd_master.o fifo_lcd_master.cpp158 }}} 159 Cette commande doit créer fichier objet ''fifo_ lcd_master.o dans le répertoire TP1.157 $ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o fifo_gcd_master.o fifo_gcd_master.cpp 158 }}} 159 Cette commande doit créer fichier objet ''fifo_gcd_master.o dans le répertoire TP1. 160 160 161 161 Vous pouvez utiliser la même commande (en changeant les noms des fichiers) pour compiler... et déboguer le modèle 162 du composant `Fifo LcdCoprocessor`.162 du composant `FifoGcdCoprocessor`. 163 163 164 164 == 3.2 Ecriture du modèle CABA de la ''top-cell'' == … … 190 190 Vous pouvez maintenant créer le programme exécutable ''simulator.x'' en effectuant l'édition de liens entre les trois fichiers objet précédemment créés : 191 191 {{{ 192 $ g++ -Wno-deprecated -L. -L/users/outils/dsx/cctools/lib-linux -o simulator.x fifo_ lcd_master.o fifo_lcd_coprocessor.o tp1_top.o -lsystemc 2>&1 | c++filt192 $ g++ -Wno-deprecated -L. -L/users/outils/dsx/cctools/lib-linux -o simulator.x fifo_gcd_master.o fifo_gcd_coprocessor.o tp1_top.o -lsystemc 2>&1 | c++filt 193 193 }}} 194 194 Cette commande doit créer fichier objet ''simulator.x'' dans le répertoire TP1. … … 221 221 La génération de l'exécutable utilise la commande suivante : 222 222 {{{ 223 $ g++ -Wno-deprecated -L. -L/users/outils/dsx/systemcass/lib -o fast_simulator.x fifo_ lcd_master.o fifo_lcd_coprocessor.o tp1_top.o -lsystemc 2>&1 | c++filt223 $ g++ -Wno-deprecated -L. -L/users/outils/dsx/systemcass/lib -o fast_simulator.x fifo_gcd_master.o fifo_gcd_coprocessor.o tp1_top.o -lsystemc 2>&1 | c++filt 224 224 }}} 225 225 Modifiez le fichier Makefile de la question précédente pour générer un exécutable fast_simulator.x et comparez les vitesses des deux simulateurs.
