Changes between Version 14 and Version 15 of SoclibCourseTp1
- Timestamp:
- Aug 31, 2009, 4:59:17 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SoclibCourseTp1
v14 v15 9 9 L'objectif de ce premier TP est d'illustrer - sur un exemple très simple ne comportant que deux composants matériels - 10 10 les principes de la modélisation SystemC au niveau d'abstraction CABA 11 (Cycle Accurate, Bit Accurate).La modélisation CABA est l'un des deux niveaux d'abstraction utilisés pour modéliser les composants de la bibliothèque SoCLib. 11 (Cycle Accurate, Bit Accurate). 12 La modélisation CABA est l'un des deux niveaux d'abstraction utilisés pour modéliser les composants de la bibliothèque SoCLib. 12 13 Ce type de modélisation s'appuie sur la théorie des automates d'états synchrones communicants (CFSM), 13 14 et permet d'utiliser des technique d'ordonnancement statique pour accélérer la simulation. … … 23 24 [[Image(soclib_tp1_fig1_archi.png)]] 24 25 25 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 NRESET, actif à l'état bas.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. 26 27 27 28 == 2.1 Canal de communication FIFO == … … 39 40 40 41 Un des avantages de ce protocole est que les deux composants communicants se comportent tous les deux comme des automates de Moore : les 3 signaux R_WOK, W_ROK et DATA ne dépendent que de l'état interne de l'émetteur. 41 Dans ce protocole, une donnée est effectivement échangée à tous les cycles où le producteur42 42 43 43 == 2.2 Composant ''fifo_lcd_coprocessor'' == … … 58 58 les valeurs opa et opb qui évoluent au cours du calcul, ainsi qu'un comparateur et un soustracteur sur 32 bits. 59 59 60 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 d 'entrée.61 62 Finalement, l'automate qui contrôle le composant "fifo_lcd_coprocesseurexécute un boucle infinie, dans laquelle il effectue successivement les 4 opérations suivantes:60 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. 61 62 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 63 64 64 1. lecture de l'opérande A sur son port FIFO d'entrée … … 66 66 1. calcul effectif du PGCD 67 67 1. écriture du résultat sur son port FIFO de sortie 68 68 69 Ces quatres opérations ont des durées d'exécution variables, puisque le nombre de cycles pour effectuer le calcul 69 70 (é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 73 [[Image(soclib_tp1_fig3_coprocessor.png)]] 73 74 74 Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle donc deux autres registres ''r_opa "et ''r_opb''75 Outre le registre d'état de l'automate ''r_fsm'', cet automate contrôle donc deux autres registres ''r_opa'' et ''r_opb'' 75 76 utilisés pour le calcul : 76 77 * 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). … … 88 89 1. lecture du du résultat sur son port FIFO d'entrée. 89 90 1. affichage des valers sur le terminal. 90 Pour modéliser la génération aléatoire, on utilise la fonction ''rand()'' fournie par la LibCde la station de travail91 Pour modéliser la génération aléatoire, on utilise la fonction ''rand()'' fournie par la `libc` de la station de travail 91 92 qui exécute la simulation. On génère évidemment des valeurs aléatoires différentes à chaque itération de la boucle, 92 93 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. 93 94 94 Le composant ''fifo_lcd_master'' est donc un composant matériel paramètrable (un paramètre permettant de contrôler95 Le composant ''fifo_lcd_master'' est donc un composant matériel paramètrable (un paramètre permettant de contrôler 95 96 la séquence de valeurs aléatoires), modélisé comme un automate à 5 états : 96 97 … … 100 101 ''r_cyclecount'' est incrémenté à chaque cycle, et contient donc la date (en nombre de cycles) depuis l'initialisation 101 102 du système. Le registre ''r_iterationcount'' est incrémenté à chaque itération, et contient donc le numéro de l'itération courante. 102 * 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 q 'un cycle dans cet état.103 * 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. 103 104 * 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). 104 105 * 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). … … 111 112 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: 112 113 {{{ 113 $ tar xjvf soclib_tp1.tgz 114 }}} 114 $ tar xzvf soclib_tp1.tgz 115 }}} 116 115 117 Cette archive contient les fichiers suivants : 116 118 * ''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é. 117 * ''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é. Ce fichier est complet et ne doit pas être modifié.119 * ''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é. 118 120 * ''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é. 119 121 * ''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é. … … 130 132 ''fifo_lcd_coprocessor.cpp''. 131 133 132 Comme pour tout modèle CABA SoCLib, les variables membres de la classe '''FifoLcdCoprocessor sont de trois types :134 Comme pour tout modèle CABA SoCLib, les variables membres de la classe '''FifoLcdCoprocessor''' sont de trois types : 133 135 * '''ports''' : les variables membres représentant les ports d'entrée sortie sont de type ''sc_core::sc_in'' ou ''sc_core::sc_out'', 134 136 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. … … 143 145 registres en fonction de la valeur courante des registres et des valeurs présentes sur les autres ports d'entrée. 144 146 * 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. 145 * 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.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. 146 148 Les noms de fonction ne sont pas imposés, mais il est recommandé de respecter les noms proposés ci-dessus. 147 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()''.
