| 143 | | |
| 144 | | |
| 145 | | |
| 146 | | L'algorithme de calcul du PGCD implanté par cet automate cablé peut être décrit par le code C suivant : |
| 147 | | {{{ |
| 148 | | uint32_t lcd( uint32_t opa, uint32_t opb) |
| 149 | | { |
| 150 | | while (opa != opb ) |
| 151 | | { |
| 152 | | if ( opa > opb ) opa = opa - opb; |
| 153 | | if ( opa < opb ) opb = opb - opa |
| 154 | | } |
| 155 | | return( opa ); |
| 156 | | } |
| 157 | | }}} |
| 158 | | Le chemin de donnée permettant de réaliser ce calcul doit donc comporter deux registres r_opa et r_opb pour stocker |
| 159 | | les valeurs opa et opb qui évoluent au cours du calcul, ainsi qu'un comparateur et un soustracteur sur 32 bits. |
| 160 | | |
| 161 | | 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. |
| 162 | | |
| 163 | | 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: |
| 164 | | |
| 165 | | 1. lecture de l'opérande A sur son port FIFO d'entrée |
| 166 | | 1. lecture de l'opérande B sur son port FIFO d'entrée |
| 167 | | 1. calcul effectif du PGCD |
| 168 | | 1. écriture du résultat sur son port FIFO de sortie |
| 169 | | |
| 170 | | Ces quatres opérations ont des durées d'exécution variables, puisque le nombre de cycles pour effectuer le calcul |
| 171 | | (é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 |
| 172 | | qui dépendent de la disponibilité du composant fifo_lcd_master. |
| 173 | | |
| 174 | | [[Image(soclib_tp1_fig3_coprocessor.png)]] |
| 175 | | |
| 176 | | Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle donc deux autres registres ''r_opa'' et ''r_opb'' |
| 177 | | utilisés pour le calcul : |
| 178 | | * Dans l'état '''READ_OPA''' (resp. '''READ_OPB'''), on écrit dans le registre ''r_opa'' (resp ''r_opb'') la valeur de l'opérande OPA (resp. OPB) lue sur le port FIFO d'entrée (champs ''p_in.data''). On ne sort de cet état que si la donnée est valide (condition ''p_in.rok'' = true). |
| 179 | | * Dans l'état '''WRITE_RES''', on écrit le contenu du registre ''r_opa'' sur le port FIFO de sortie ''p_out.data''. On ne sort de cet état que si la donnée est acceptée (condition ''p_out.wok'' = true). |
| 180 | | * Dans l'état '''COMPARE''', on effectue la comparaison entre les contenus des registres ''r_opa'' et ''r_opb''. On n'écrit pas dans les registres ''r_opa'' et ''r_opb'', mais les conditions de sortie dépendent du résultat de la comparaison. |
| 181 | | * 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. |
| 182 | | |
| 183 | | == 2.3 Composant ''fifo_lcd_master'' == |
| 184 | | |
| 185 | | 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. |
| 186 | | Ce problème sera traité dans la suite de ce cours, mais dans ce premier TP, on se contente d'utiliser un ''processeur cablé'', qui exécute en boucle le programme suivant: |
| 187 | | 1. génération (pseudo-aléatoire) de deux valeurs OPA et OPB. |
| 188 | | 1. écriture de l'opérande OPA sur son port FIFO de sortie. |
| 189 | | 1. écriture de l'opérande OPB sur son port FIFO de sortie |
| 190 | | 1. lecture du du résultat sur son port FIFO d'entrée. |
| 191 | | 1. affichage des valers sur le terminal. |
| 192 | | Pour modéliser la génération aléatoire, on utilise la fonction ''rand()'' fournie par la `libc` de la station de travail |
| 193 | | qui exécute la simulation. On génère évidemment des valeurs aléatoires différentes à chaque itération de la boucle, |
| 194 | | 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. |
| 195 | | |
| 196 | | Le composant ''fifo_lcd_master'' est donc un composant matériel paramètrable (un paramètre permettant de contrôler |
| 197 | | la séquence de valeurs aléatoires), modélisé comme un automate à 5 états : |
| 198 | | |
| 199 | | [[Image(soclib_tp1_fig4_master.png)]] |
| 200 | | |
| 201 | | 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 |
| 202 | | ''r_cyclecount'' est incrémenté à chaque cycle, et contient donc la date (en nombre de cycles) depuis l'initialisation |
| 203 | | du système. Le registre ''r_iterationcount'' est incrémenté à chaque itération, et contient donc le numéro de l'itération courante. |
| 204 | | * dans l'état '''RANDOM''' on écrit les valeurs pseudo-aléatoires OPA et OPB dans les registres ''r_opa'' et ''r_opb''. On ne reste qu'un cycle dans cet état. |
| 205 | | * dans l'état '''WRITE_OPA''' (resp. '''WRITE_OPB''') on écrit le contenu du registre ''r_opa'' (resp ''r_opb'') sur le port FIFO de sortie (champs ''p_out.data''). On ne sort de ces états que si la donnée est acceptée (condition ''p_out.wok'' = true). |
| 206 | | * dans l'état '''READ_RES''', on écrit dans le registre ''r_res'' la valeur lue sur le port FIFO d'entrée (champs ''p_in.data''). On ne sort de cet état que si la donnée lue est valide (condition ''p_in.rok'' = true). |
| 207 | | * Dans l'état '''DISPLAY''', on ne modifie pas le contenu des registres ''r_opa'', ''r_opb'', et ''r_res'', mais on affiche la date |
| 208 | | courante ainsi que les valeurs des opérandes et du résultat sur le terminal standard de la station de travail qui exécute la simulation. On ne reste qu'un cycle dans cet état. |
| 209 | | |
| 210 | | = 3. Travail à réaliser = |
| 211 | | |
| 212 | | L'archive attachement:soclib_tp1.tgz contient différents fichiers dont vous aurez besoin pour ce premier TP. |
| 213 | | Créez un répertoire de travail spécifique TP1 pour ce TP, recopier l'archive dans ce répertoire TP1, et décompressez-la: |
| 214 | | {{{ |
| 215 | | $ tar xzvf soclib_tp1.tgz |
| 216 | | }}} |
| 217 | | |
| 218 | | Cette archive contient les fichiers suivants : |
| 219 | | * ''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é. |
| 220 | | * ''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é. |
| 221 | | * ''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é. |
| 222 | | * ''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é. |
| 223 | | * ''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é. |
| 224 | | * ''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é. |
| 225 | | * ''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é. |
| 226 | | |
| 227 | | == 3.1 Ecriture du modèle CABA du coprocesseur == |
| 228 | | |
| 229 | | Pour une présentation détaillée des règles d'écriture des modèles de simulation au niveau CABA, vous pouvez consulter la documention disponible en ligne sur le site sur le site WEB du projet SoCLib : [https://www.soclib.fr/trac/dev/wiki/WritingRules/Caba]. |
| 230 | | |
| 231 | | 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é. |
| 232 | | En vous inspirant du code fourni pour le composant '''master''', complêter les deux fichiers ''fifo_lcd_coprocessor.h'' et |
| 233 | | ''fifo_lcd_coprocessor.cpp''. |
| 234 | | |
| 235 | | Comme pour tout modèle CABA SoCLib, les variables membres de la classe `FifoLcdCoprocessor` sont de trois types : |
| 236 | | * '''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. |
| 237 | | * '''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. |
| 238 | | * '''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. |
| 239 | | |
| 240 | | 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. |
| 241 | | |
| 242 | | Enfin, comme tous les modèles CABA de SoCLib, le coprocesseur LCD possède des fonctions membres définissant |
| 243 | | le comportement du composant, qui sont de trois types : |
| 244 | | * la fonction ''transition()'' est sensible au front montant du port d'etrée CK, et permet de calculer la valeur future des |
| 245 | | registres en fonction de la valeur courante des registres et des valeurs présentes sur les autres ports d'entrée. |
| 246 | | * la fonction ''genMoore()'' est sensible au front descendant du port d'entrée CK, et permet de calculer la valeur des ports de sortie qui ne dépendent que des valeurs stockées dans les registres. |
| 247 | | * 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. |
| 248 | | Les noms de fonction ne sont pas imposés, mais il est recommandé de respecter les noms proposés ci-dessus. |
| 249 | | Le coprocesseur LCD se comportant globalement comme un automate de Moore, on n'a pas besoin de définir de fonctions de type ''genMealy()''. |
| 250 | | |
| 251 | | Les architectures matérielles modélisées avec SoCLib peuvent comporter plusieurs dizaines de modèles différents. |
| 252 | | 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. |
| 253 | | |
| 254 | | A titre d'exemple, compilez le modèle du composant `FifoLcdMaster`, en utilisant le compilateur g++. |
| 255 | | Il faut lancer la commande suivante dans votre répertoire de travail TP1 : |
| 256 | | {{{ |
| 257 | | $ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o fifo_lcd_master.o fifo_lcd_master.cpp |
| 258 | | }}} |
| 259 | | Cette commande doit créer fichier objet ''fifo_lcd_master.o dans le répertoire TP1. |
| 260 | | |
| 261 | | Vous pouvez utiliser la même commande (en changeant les noms des fichiers) pour compiler... et déboguer le modèle |
| 262 | | du composant `FifoLcdCoprocessor`. |
| 263 | | |
| 264 | | == 3.2 Ecriture du modèle CABA de la ''top-cell'' == |
| 265 | | |
| 266 | | On appelle généralement ''top-cell'' la description structurelle decrivant l'interconnexion des différents composants |
| 267 | | matériels constituant l'architecture matérielle qu'on souhaite simuler. |
| 268 | | Editez le fichier ''tp1_top.cpp'', qui décrit l'architecture, ainsi que les directives de simulation. Ce fichier est volontairement incomplet pour vous obliger à analyser en détail les différentes sections : |
| 269 | | |
| 270 | | * '''arguments''' : On définit dans cette section les arguments qui pourront être passés en lgne de commande lors du lancement de la simulation. On prévoit ici de passer en premier argument le nombre de cycles à simuler, et comme deuxième argument la valeur d'initialisation du générateur aléatoire utilisé dans le composant master. cette section n'a pas besoin d'être modifiée. |
| 271 | | |
| 272 | | * '''Signals''' : On définit dans cette section les différents signaux qui seront utilisés pour connecter entre eux les ports d'entrée sortie des différents composants. On a besoin de 4 signaux : les deux signaux ''signal_ck'' et ''signal_resetn'' |
| 273 | | devront être connectés aux ports correspondants des deux composants matériels. Les deux signaux ''signal_fifo_m2c'' et ''signal_fifo_c2m'' sont des signaux composites représentant les deux canaux de communication entre les deux composants. On utilise un type générique, en ce sens que le type de la donnée transférée à chaque cycle doit être défini par un paramètre template : dans le cas présent, on transfère un entier 32 bits ''uint32-t''. Le signal ''signal_clk'' est également un objet complexe de type ''sc_core::sc_clock'', dont on peut définir la période (sc_time(1,SC_NS) signifie 1 ns), |
| 274 | | ainsi que le rapport cyclique. Vous devez ajouter le signal manquant dans cette section. |
| 275 | | |
| 276 | | * '''Components''' : Dans cette section on appelle les constructeurs des différents composants instanciés, en définissant les paramètres. Le nom d'instance est un paramètre obligatoire. Le composant master possède un second paramètre qui est la valeur d'initialisation du générateur aléatoire. Vous devez aouter l'appel au constructeur du composant coprocesseur. |
| 277 | | |
| 278 | | * '''Net-List''' : On décrit dans cette section les connexions entre les composants. La syntaxe utilisée pour connecter un signal s au port p d'un composant c est : ''c.p(s)''. Vous devez ajouter les connexions concernant les ports du coprocesseur. |
| 279 | | |
| 280 | | * '''Simulation''' : Cette section décrit les directives de simulation. Le mécanisme de RESET étant synchrone, On commence par exécuter un cycle en forçant ''signal_resetn'' à l'état bas (actif), pour initialiser les registres internes de tous les composants, puis on exécute le nombre de cycles spécifié en forçant ''signal_resetn'' à l'état haut (inactif). |
| 281 | | |
| 282 | | Vous pouvez compiler ce fichier ''tp1_top.cpp'' pour générer le fichier objet correspondant en utilisant la commande: |
| 283 | | {{{ |
| 284 | | $ g++ -Wno-deprecated -I. -I/users/outils/dsx/cctools/include -c -o tp1_top.o tp1_top.cpp |
| 285 | | }}} |
| 286 | | Cette commande doit créer fichier objet ''tp1_top.o'' dans le répertoire TP1. |
| 287 | | |
| 288 | | == 2.3 génération et lancement du simulateur == |
| 289 | | |
| 290 | | 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 : |
| 291 | | {{{ |
| 292 | | $ 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++filt |
| 293 | | }}} |
| 294 | | Cette commande doit créer fichier objet ''simulator.x'' dans le répertoire TP1. |
| 295 | | |
| 296 | | On lance l'exécution du simulateur pour 10000 cycles avec la commande : |
| 297 | | {{{ |
| 298 | | $ ./simulator.x 10000 |
| 299 | | }}} |
| 300 | | Quelle est la duréee moyenne d'une itération? |
| 301 | | |
| 302 | | Regroupez toutes les commandes de compilation dans un fichier ''Makefile'', en explicitant les dépendances entre les fichiers. |
| 303 | | |
| 304 | | == 2.4 Simulation avec SystemCASS == |
| 305 | | |
| 306 | | Comme cela a été expliqué en cours, le style d'écriture des modèles de simulation CABA utilisé dans SoCLib permet une simulation rapide - même en utilisant le moteur de simulation SystemC2.0 fourni par le consortium OSCI - |
| 307 | | puisque dans le cas où tous les composants matériels se comportent comme des automates de Moore, les deux fonctions ''transition'' et ''genMoore'' de chaque composant ne sont exécutées qu'une seule fois par cycle. |
| 308 | | |
| 309 | | Le moteur de simulation SystemC2.0 utilise une technique d'ordonnancement dynamique (avec gestion d'un échéancier), |
| 310 | | qui a le mérite d'être très générale, et de s'adapter à à peuprès n'importe quel style d'écriture des modèles SystemC. |
| 311 | | Mais il est possible de gagner un facteur 10 sur la vitesse de simulation en utilisant le moteur de simulation SystemCASS (développé par le laboratoire LIP6), qui utilise une technique d'ordonnancement statique (sans échéancier) pour exploiter |
| 312 | | les caractéristiques particulières des modèles SoCLib. |
| 313 | | |
| 314 | | Pour utiliser SystemCASS, il n'est pas nécessaire de modifier le code SystemC des composants instanciés, ni le code SystemC décrivant la top_cell, mais il faut recompiler l'ensemble des fichiers sources, en modifiant les chemins d'accès aux fichiers |
| 315 | | d'include et aux bibliothèques de SystemC. |
| 316 | | |
| 317 | | La génération des fichiers objets utilise la commande suivante : |
| 318 | | {{{ |
| 319 | | $ g++ -Wno-deprecated -I. -I/users/outils/dsx/systemcass/include -c -o filename.o filename.cpp |
| 320 | | }}} |
| 321 | | La génération de l'exécutable utilise la commande suivante : |
| 322 | | {{{ |
| 323 | | $ 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++filt |
| 324 | | }}} |
| 325 | | 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. |
| 326 | | |
| 327 | | |
| 328 | | = 4. Compte-rendu = |
| 329 | | |
| 330 | | Il ne vous est pas demandé de compte-rendu pour ce TP, mais on vous demandera une démonstration de votre simulateur |
| 331 | | au début du TP de la semaine suivante... |
| | 183 | Il ne vous est pas demandé de compte-rendu pour ce TP, mais on vous demandera une démonstration de votre simulateur au début du TP de la semaine suivante... |
