Changes between Version 28 and Version 29 of SoclibCourseTp3
- Timestamp:
- Sep 28, 2009, 11:04:53 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SoclibCourseTp3
v28 v29 23 23 [[Image(soclib_tp3_archi.png)]] 24 24 25 * '''xcache''' est un processeur M IPS32 avec ses caches L1. On utilise le composant ''!VciXcacheWrapper'', qui est un contrôleur de cache à interface VCI. Ce composant générique encapsule un autre composant ''!Mips32Iss'', qui modélise un coeur de processeur MIPS32.26 * '''rom''' est une mémoire non inscriptible à interface VCI contenant le code de boot. On utilise le composant ''!VciSimpleRam''.27 * '''ram''' est une mémoire inscriptible à interface VCI contenant le code et les données. On utilise également un composant ''!VciSimpleRam''.28 * '''tty''' est un périphérique adressable de type écran/clavier à interface VCI. On utilise le composant ''!VciMultiTty''.29 * '''gcd''' est le coprocesseur cible réalisant le calcul du PGCD. On utilise évidemment le composant ''!VciGcdCoprocessor''.30 * '''vgsb''' est le bus système déjà utilisé dans le TP2. On utilise le composant ''!VciVgsb''.25 * '''xcache''' est un processeur Mips32 avec ses caches L1. On utilise le composant `VciXcacheWrapper`, qui est un contrôleur de cache à interface VCI. Ce composant générique encapsule un autre composant `Mips32Iss`, qui modélise un coeur de processeur Mips32. 26 * '''rom''' est une mémoire non inscriptible à interface VCI contenant le code de boot. On utilise le composant `VciSimpleRam`. 27 * '''ram''' est une mémoire inscriptible à interface VCI contenant le code et les données. On utilise également un composant `VciSimpleRam`. 28 * '''tty''' est un périphérique adressable de type écran/clavier à interface VCI. On utilise le composant `VciMultiTty`. 29 * '''gcd''' est le coprocesseur cible réalisant le calcul du PGCD. On utilise évidemment le composant `VciGcdCoprocessor`. 30 * '''vgsb''' est le bus système déjà utilisé dans le TP2. On utilise le composant `VciVgsb`. 31 31 32 32 Les modèles de simulation des composants matériels instanciés dans cette architecture sont disponibles dans la bibliothèque SoCLib. 33 33 Ils vous sont fournis, et vous n'aurez pas à les re-écrire vous-même. 34 34 35 Le composant ''!VciXcacheWrapper''peut être utilisé pour encapsuler différents processeur 32 bits. Le coeur du processeur est modélisé par un ISS (Instruction Set Simulateur).36 Le type du proceseur instancié (MIP32, ARM, SPARCV8, PPC405, NIOS, !MicroBlaze, etc.) est défini par un paramètre template du composant ''!VciXcacheWrapper''.35 Le composant `VciXcacheWrapper` peut être utilisé pour encapsuler différents processeur 32 bits. Le coeur du processeur est modélisé par un ISS (Instruction Set Simulateur). 36 Le type du proceseur instancié (MIP32, ARM, SPARCV8, PPC405, NIOS, !MicroBlaze, etc.) est défini par un paramètre template du composant `VciXcacheWrapper`. 37 37 Consultez la documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici]. 38 38 39 Le composant ''!VciSimpleRam''est utilisé pour modéliser des mémoires inscriptibles embarquées (SRAM), ou39 Le composant `VciSimpleRam` est utilisé pour modéliser des mémoires inscriptibles embarquées (SRAM), ou 40 40 pour modéliser des mémoires non inscriptibles (ROM). 41 41 Ce composants peut contenir un ou plusieurs segments (correspondant à des tranches disjointes 42 42 de l'espace addressable). Le composant analyse les bits de poids fort de l'adresse VCI 43 43 pour déterminer le segment désigné. Les bancs de mémoire physique correspondant aux différents segments 44 sont modélisés par des tableaux C++ dont la longueur est définie par les valeurs stockées dans la !MappingTable.44 sont modélisés par des tableaux C++ dont la longueur est définie par les valeurs stockées dans la `MappingTable`. 45 45 Consultez la documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciSimpleRam ici]. 46 46 47 Enfin le composant ''!VciMultiTty''est un contrôleur de terminaux alpha-numériques. Ce composant peut contrôler de 1 à 256 terminaux (un terminal est une paire écran / clavier). Pratiquement, chaque terminal est modélisé par l'ouverture d'une fenêtre XTERM indépendante sur l'écran de la station de travail qui exécute la simulation.47 Enfin le composant `VciMultiTty` est un contrôleur de terminaux alpha-numériques. Ce composant peut contrôler de 1 à 256 terminaux (un terminal est une paire écran / clavier). Pratiquement, chaque terminal est modélisé par l'ouverture d'une fenêtre XTERM indépendante sur l'écran de la station de travail qui exécute la simulation. 48 48 Chaque terminal possède 4 registres adressables pour la lecture ou l'écriture, et fonctionne en mode ''caractère'': 49 49 on ne peut lire ou écrire qu'un seul caractère par transaction. … … 60 60 61 61 Les composants de la bibliothèque SoCLib permettent de modéliser des architectures matérielles complexes, capables d'exécuter des 62 systèmes d'exploitation généralistes (tels que LINUX ou Unix NetBSD), ou des systèmes d'exploitation spécialisés pour MPSoC (tels que MUTEKHou DNA). Mais dans ce TP et les suivants, on se contentera d'un62 systèmes d'exploitation généralistes (tels que LINUX ou NetBSD), ou des systèmes d'exploitation spécialisés pour MPSoC (tels que [https://www.mutek.fr/ MutekH] ou DNA). Mais dans ce TP et les suivants, on se contentera d'un 63 63 système d'exploitation minimal, constitué par un Gestionnaire d'Interruptions, Exceptions et Trappes (GIET), quelques appels systèmes 64 64 permettant aux programmes utilisateurs d'accéder aux périphériques, plus le code boot pour initialiser la machine. 65 Tout ce code système est écrit en C et en assembleur M IPS32, et il vous est fourni. Les programmes utilisateurs seront écrits en langage C, et seront écritspar vous.65 Tout ce code système est écrit en C et en assembleur Mips32, et il vous est fourni. Les programmes utilisateur seront écrits en langage C, par vous. 66 66 67 67 Les processeurs disponibles dans SoCLib, sont en majorités des processeurs RISC, capables … … 69 69 Le processeur doit, à chaque instruction lire l'instruction dans le cache, la décoder et l'exécuter. C'est évidemment le contrôleur du cache qui se charge d'aller lire le code binaire chargé dans les mémoires embarquées en cas de MISS. 70 70 71 Le code binaire doit donc être généré par un cross-compilateur spécifique pour le processeur M IPS32. On utilise la chaîne de compilation GCC, pour compiler l'ensemble du logiciel embarqué (code applicatif et code système) et pour réaliser l'édition de liens entre le code applicatif écrit par vous, et le code système. Le résultat de cette compilation est un fichier au format ELF, contenant le code binaire exécutable par le processeur MIP32.71 Le code binaire doit donc être généré par un cross-compilateur spécifique pour le processeur Mips32. On utilise la chaîne de compilation GCC, pour compiler l'ensemble du logiciel embarqué (code applicatif et code système) et pour réaliser l'édition de liens entre le code applicatif écrit par vous, et le code système. Le résultat de cette compilation est un fichier au format ELF, contenant le code binaire exécutable par le processeur MIP32. 72 72 73 73 == 3.2 Chargement du code == 74 74 75 Il existe deux méthode méthodes permettant de charger le code binaire dans les mémoires embarquées sur la puce:75 Il existe deux méthodes permettant de charger le code binaire dans les mémoires embarquées sur la puce: 76 76 1. Le code peut être stocké dans des mémoires mortes (ROM). Le contenu de ces mémoires est défini lors de la fabrication de la puce, et n'est plus modifiable. Cette approche est évidemment très peu flexible, et elle n'est généralement utilisée que pour le code de boot. 77 77 1. Le code peut être stocké dans des mémoires inscriptibles (SRAM), qui sont chargées lors de la mise sous tension du système à partir d'un périphérique de stockage externe (cela peut être une ROM externe, une mémoire flash, ou un autre dispositif de stockage. On peut même imaginer qu'on utilise une liaison sans fil pour télécharger du code applicatif disponible sur un serveur distant. Cette approche est utilisée pour le code applicatif, mais également pour le système d'exploitation embarqué. Le code qui exécute ce chargement de code s'appelle un ''bootloader''. … … 85 85 dans le fichier ELF. Cette initialisation n'est plus réalisée lors de l'exécution de la simulation (dans la phase de boot), elle 86 86 est réalisée avant le démarrage de la simulation par le constructeur des composants modélisant des mémoires embarquées 87 (ROM ou RAM). Le constructeur du composant ''!VciSimpleRam'' possède un argument ''loader''qui lui permet d'accéder au87 (ROM ou RAM). Le constructeur du composant `VciSimpleRam` possède un argument `loader` qui lui permet d'accéder au 88 88 contenu du fichier ELF contenant le code binaire. Le constructeur possédant un autre argument lui permettant d'accéder 89 à la MappingTable, il peut déterminer quels segments de la RAM (ou de la ROM) doivent être initialisés.89 à la `MappingTable`, il peut déterminer quels segments de la RAM (ou de la ROM) doivent être initialisés. 90 90 91 91 On économise ainsi plusieurs millions de cycles de simulation, et le code de boot peut être beaucoup plus court. … … 103 103 De même, l'utilisation d'un contrôleur de terminal suppose l'ouverture d'une ou plusieurs fenêtres XTERM sur la station de travail qui exécute la simulation. 104 104 105 Vous pouvez consulter le fichier ''Makefile''pour avoir la liste de tous les105 Vous pouvez consulter le fichier `Makefile` pour avoir la liste de tous les 106 106 fichiers objets qui doivent être compilés pour générer le simulateur de cette architecture très simple. 107 107 108 Elle contient également un sous-répertoire ''soft''qui est utilisé pour la génération du logiciel embarqué.108 Elle contient également un sous-répertoire `soft` qui est utilisé pour la génération du logiciel embarqué. 109 109 110 110 == 4.1 Segmentation de l'espace adressable == … … 114 114 * '''seg_tty''' est le segment associé au contrôleur de terminaux TTY. On prendra pour adresse de base la valeur 0xC0000000, et pour longueur 64 octets, ce qui permet d'adresser jusqu'à 4 terminaux indépendants. 115 115 * '''seg_gcd''' est le segment associé au coprocesseur GCD. On prendra pour adresse de base la valeur 0x90000000. La longueur de 16 octets correspond aux quatre registres adressables de ce composant. 116 * '''seg_reset''' est le segment contenant contient le code de ''boot'' exécuté à la mise sous tension. Il est évidemment assigné à la ROM. L'adresse de base 0xBFC00000 est imposée par la spécification du processeur MIPS32. On choisira une capacité de stockage de 4Koctets.117 * '''seg_kernel''' est le segment contenant le code du système qui s'exécute en mode ''kernel''. Il s'agit principalement du Gestionnaire d'Interruptions, Exceptions, et Trappes (GIET) et du code des appels système s. Ce segment est assigné à la RAM. L'adresse de base 0x80000000 est imposée par la spécification du processeur MIPS32 qui impose que le point d'entrée est à l'adresse 0x80000180. On choisira une capacité de stockage de 4 Koctets.116 * '''seg_reset''' est le segment contenant le code de ''boot'' exécuté à la mise sous tension. Il est évidemment assigné à la ROM. L'adresse de base 0xBFC00000 est imposée par la spécification du processeur Mips32. On choisira une capacité de stockage de 4 Koctets. 117 * '''seg_kernel''' est le segment contenant le code du système qui s'exécute en mode ''kernel''. Il s'agit principalement du Gestionnaire d'Interruptions, Exceptions, et Trappes (GIET) et du code des appels système. Ce segment est assigné à la RAM. L'adresse de base 0x80000000 est imposée par la spécification du processeur Mips32 qui impose que le point d'entrée est à l'adresse 0x80000180. On choisira une capacité de stockage de 4 Koctets. 118 118 * '''seg_text''' est le segment contenant le code de l'application logicielle embarquée, qui s'exécute en mode ''user''. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x00400000, et une capacité de stockage de 16 Koctets. 119 119 * '''seg_data''' est le segment contenant les données globales et la pile d'exécution de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x00000000, et une capacité de stockage de 64 Koctets. 120 120 * '''seg_stack''' est le segment contenant la pile d'exécution de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x00800000, et une capacité de stockage de 64 Koctets. 121 121 122 Remarquez que les 2 segments correspondant aux périphériques (seg_tty et seg_ lcd), ainsi que les deux segments correspondant au code système sont dans la zone protégée de l'espace adressable, qui n'est accessible qu'en mode ''kernel'' (adresses supérieures à 0x80000000).122 Remarquez que les 2 segments correspondant aux périphériques (seg_tty et seg_gcd), ainsi que les deux segments correspondant au code système sont dans la zone protégée de l'espace adressable, qui n'est accessible qu'en mode ''kernel'' (adresses supérieures à 0x80000000). 123 123 124 124 '''Remarque importante''' : Certaines informations sont utilisées à la fois par le matériel et par le logiciel embarqué, et doivent donc être définies à deux endroits : 125 1. Les addresses de base et les longueurs des segments sont utilisées par le matériel : Elles doivent être définies dans le fichier ''tp3_top.cpp'' pour ëtre stockées dans la !MappingTable, qui est est utilisée dans la phase de configuration du matériel par les constructeurs des composants. Ces mêmes adresses de base des segments sont utilisées par le logiciel et doivent être définies dans le fichier ''soft/ldscript''qui contient les directives pour l'éditeur de liens lors de la compilation du logiciel embarqué.126 1. Le composant matériel générique ''!VciMultiTty'' peut contrôler un nombre variable de terminaux. Ce nombre de terminaux doit être défini dans le fichier ''tp3_top.cpp'' (pour le matériel), mais doit aussi être défini dans le fichier ''soft/ldscript'', pour informer le système d'exploitation du nombre de terminaux adressables.127 128 Complêtez les fichiers ''tp3_top.cpp'' et ''soft/ldsript''pour définir les adresses de base et les longueurs des segments,125 1. Les addresses de base et les longueurs des segments sont utilisées par le matériel : Elles doivent être définies dans le fichier `tp3_top.cpp` pour ëtre stockées dans la `MappingTable`, qui est est utilisée dans la phase de configuration du matériel par les constructeurs des composants. Ces mêmes adresses de base des segments sont utilisées par le logiciel et doivent être définies dans le fichier `soft/ldscript` qui contient les directives pour l'éditeur de liens lors de la compilation du logiciel embarqué. 126 1. Le composant matériel générique `VciMultiTty` peut contrôler un nombre variable de terminaux. Ce nombre de terminaux doit être défini dans le fichier `tp3_top.cpp` (pour le matériel), mais doit aussi être défini dans le fichier `soft/ldscript`, pour informer le système d'exploitation du nombre de terminaux adressables. 127 128 Complêtez les fichiers `tp3_top.cpp` et `soft/ldsript` pour définir les adresses de base et les longueurs des segments, 129 129 ainsi que le nombre de terminaux utilisés. 130 130 131 131 == 4.2 Compilation du logiciel embarqué == 132 132 133 Le logiciel embarqué est défini dans plusieurs fichiers source, que vous trouverez dans le répertoire ''soft''. 134 Certains de ces fichiers sont écrits en assembleur MIPS32, certains sont écrits en C : 135 * le fichier '''reset.s''' est écrit en assembleur et contient le code de boot qui est exécuté à la mise sous tension, ou lors de l'activation du signal NRESET. Ce code s'exécute en mode ''kernel'' et initialise quelques registres, avant de se brancher à la pemière instruction du programme ''main''. 136 * le fichier '''giet.s''' est écrit en assembleur et contient le code du Gestionnaire d'Interruption, Exceptions et Trappes. Le GIET est l'unique point d'entrée dans le système d'exploitation. Ce code s'exécute en mode ''kernel'', et se termine toujours par une instruction ''eret''. 137 * le fichier '''stdio.c''' est écrit en C, et contient le code des fonctions C permettant à un programme applicatif s'exécutant en mode ''user'' d'accéder aux périphériques ''mappés'' dans le segment ''kernel'', en effectuant des appels système. 138 * le fichier '''syscalls.s''' est écrit en C et contient le code des appels systèmes proprement ditS. Ce code s'exécute en mode kernel, et permet l'accès aux périphériques ou aux registres protégés du processeur. 139 * le fichier '''main.c''' est écrit en C et contient le code de l'application logicielle, qui peut évidemment utiliser 140 les fonctions définies dans le fichier ''stdio.c''. 141 * le fichier '''ldscript''' contient les directives pour l'éditeur de liens. 142 * le fichier '''Makefile''' permet de lancer la génération du logiciel embarqué. 133 Le logiciel embarqué est défini dans plusieurs fichiers source, que vous trouverez dans le répertoire `soft`. 134 Certains de ces fichiers sont écrits en assembleur Mips32, certains sont écrits en C : 135 * le fichier `reset.s` est écrit en assembleur et contient le code de boot qui est exécuté à la mise sous tension, ou lors de l'activation du signal NRESET. Ce code s'exécute en mode ''kernel'' et initialise quelques registres, avant de se brancher à la pemière instruction du programme ''main''. 136 * le fichier `giet.s` est écrit en assembleur et contient le code du Gestionnaire d'Interruption, Exceptions et Trappes. Le GIET est l'unique point d'entrée dans le système d'exploitation. Ce code s'exécute en mode ''kernel'', et se termine toujours par une instruction `eret`. 137 * le fichier `stdio.c` est écrit en C, et contient le code des fonctions C permettant à un programme applicatif s'exécutant en mode ''user'' d'accéder aux périphériques ''mappés'' dans le segment ''kernel'', en effectuant des appels système. 138 * le fichier `syscalls.s` est écrit en C et contient le code des appels systèmes proprement dits. Ce code s'exécute en mode kernel, et permet l'accès aux périphériques ou aux registres protégés du processeur. 139 * le fichier `main.c` est écrit en C et contient le code de l'application logicielle, qui peut évidemment utiliser les fonctions définies dans le fichier `stdio.c`. 140 * le fichier `ldscript` contient les directives pour l'éditeur de liens. 141 * le fichier `Makefile` permet de lancer la génération du logiciel embarqué. 143 142 144 143 '''Question''' : Quels sont les appels système qui permettent d'accéder à un terminal TTY ? Lorsqu'il y a plusieurs terminaux dans l'architecture, comment est sélectionné le terminal cible ? 145 144 146 145 147 On rappelle que l'instruction ''eret''de sortie du GIET ou du code de boot effectue principalemnt deux actions :146 On rappelle que l'instruction `eret` de sortie du GIET ou du code de boot effectue principalemnt deux actions : 148 147 1. Elle modifie le registre protégé SR (registre 12 du coprocesseur ''système'') pour que le processeur retourne dans le mode où il était lorsqu'il a été dérouté par une interruption, une exception ou un appel système. 149 148 1. Elle effectue un branchement à l'adresse contenue dans le registre protégé EPC (registre 14 du coprocesseur ''système''). … … 151 150 '''Question''' : Quels sont les initialisations réalisées par le code de boot ? pouquoi ces initialisations ? 152 151 153 Le premier programme que vous allez exécuter se contente d'afficher le célèbre ''hello world''sur le terminal.154 Ouvrez le fichier ''soft/main.c''.155 156 '''Question''' : Que fait ce programme ? (on rappelle que la fonction ''tty_getc()''est bloquante, et ne rend pas la main tant qu'un caractère n'a pas été saisi au clavier).157 158 Lancez l'exécution du Makefile. Deux fichiers ''soft.bin'' et ''soft.bin.txt'' doivent être créé dans le répertoire ''soft'':159 Le fichier ''soft.bin'' contient le code binaire au format ELF, et le fichier ''soft.bin.txt''contient un version desassemblée (donc lisible) de ce code binaire.152 Le premier programme que vous allez exécuter se contente d'afficher le célèbre `hello world` sur le terminal. 153 Ouvrez le fichier `soft/main.c`. 154 155 '''Question''' : Que fait ce programme ? (on rappelle que la fonction `tty_getc()` est bloquante, et ne rend pas la main tant qu'un caractère n'a pas été saisi au clavier). 156 157 Lancez l'exécution du Makefile. Deux fichiers `soft.bin` et `soft.bin.txt` doivent être créés dans le répertoire `soft` : 158 Le fichier `soft.bin` contient le code binaire au format ELF, et le fichier `soft.bin.txt` contient un version desassemblée (donc lisible) de ce code binaire. 160 159 161 160 == 4.3 Définition de l'architecture matérielle == 162 161 163 Complétez le fichier ''tp3_top.cpp'': Il faut enregister les 7 segments dans la MappingTable.162 Complétez le fichier `tp3_top.cpp`: Il faut enregister les 7 segments dans la `MappingTable`. 164 163 Il faut définir les arguments de tous les constructeurs des composants instanciés, ainsi que les valeurs de 165 leurs paramètres template. Il faut définir le cheminom permettant au ''loader''des composants ROM et RAM166 d'accéder au fichier ''soft/bin.soft''contenant le code binaire.164 leurs paramètres template. Il faut définir le nom du fichier permettant au `loader` des composants ROM et RAM 165 d'accéder au fichier `soft/bin.soft` contenant le code binaire. 167 166 168 167 '''Question''' : Parmi les 7 segments utilisés dans cette l'architecture, lesquels doivent être déclarés cachables ? 169 168 170 169 '''Question''' : Quel est le nombre de bits de poids fort de l'adresse qui doivent être décodés par le contrôleur du bus 171 pour déterminer la cible VCI désignée ? Cette information est un des arguments du constructeur de la !MappingTable.170 pour déterminer la cible VCI désignée ? Cette information est un des arguments du constructeur de la `MappingTable`. 172 171 173 172 '''Question''' quels sont les bits d'adresse qui doivent être décodés par le contrôleur du cache, pour déterminer 174 173 qu'une adresse appartient à un segment non-cachable, et doit être directement transmise à la mémoire ? 175 Cette information est un autre argument du constructeur de la !MappingTable.174 Cette information est un autre argument du constructeur de la `MappingTable`. 176 175 177 176 Enfin, comme dans le TP2, il faut modifier tous les fichiers des composants SoCLib qui possèdent des paramètres templates pour définir les valeurs de ces paramètres avant de générer le fichier objet correspondant. 178 Dans le cas du coprocesseur GCD, il faut modifier le fichier ''vci_gcd_coprocessor.cpp''en ajoutant :179 180 {{{ 181 template class Vci LcdCoprocessor<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;177 Dans le cas du coprocesseur GCD, il faut modifier le fichier `vci_gcd_coprocessor.cpp` en ajoutant : 178 179 {{{ 180 template class VciGcdCoprocessor<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >; 182 181 }}} 183 182 184 183 Il faut faire de même pour les autres composants matériels instanciés. 185 184 186 Quand tout ceci est fait, lancez le Makefile qui vous est fourni dans le répertoire TP3, pour générer le simulateur ''simulator.x''.185 Quand tout ceci est fait, lancez le Makefile qui vous est fourni dans le répertoire TP3, pour générer le simulateur `simulator.x`. 187 186 188 187 == 4.5 Lancement de la simulation == … … 200 199 201 200 Ce flag permet d'activer les directives de compilation conditionnelle qui se trouvent 202 à la fois dans le fichier ''tp3_top.cpp'', et dans les modèles des composants matériels.201 à la fois dans le fichier `tp3_top.cpp`, et dans les modèles des composants matériels. 203 202 204 203 Pour attirer votre attention sur des erreurs fréquentes, faites les essais suivants : 205 1. Modifiez l'adresse de base du segment ''seg_lcd''pour lui donner la valeur 0xB0000000 au lieu de 0x9000000. Relancez la compilation et la simulation. Expliquez les résultats obtenus.206 1. Déclarez les segments correspondant aux périphériques (seg_tty et seg_ lcd) comme cachables. Relancez la compilation et la simulation. Expliquez les résultats obtenus.204 1. Modifiez l'adresse de base du segment `seg_gcd` pour lui donner la valeur 0xB0000000 au lieu de 0x9000000. Relancez la compilation et la simulation. Expliquez les résultats obtenus. 205 1. Déclarez les segments correspondant aux périphériques (seg_tty et seg_gcd) comme cachables. Relancez la compilation et la simulation. Expliquez les résultats obtenus. 207 206 208 207 == 4.5 Modification du logiciel embarqué == 209 208 210 209 Puisque le logiciel embarqué est chargé dynamiquement dans la RAM et dans la ROM lors du lancement du simulateur, 211 il est possible de modifier le logiciel embarqué (fichier ''bin.soft''), sans modifier l'architecture matérielle et donc212 sans recompiler le simulateur et sans avoir à regénérer le fichier ''simulator.x''.210 il est possible de modifier le logiciel embarqué (fichier `bin.soft`), sans modifier l'architecture matérielle et donc 211 sans recompiler le simulateur et sans avoir à regénérer le fichier `simulator.x`. 213 212 214 213 On va donc maintenant écrire une application logicielle un peu plus complexe, qui utilise le coprocesseur GCD, 215 simplement en modifiant le fichier ''main.c'' dans le répertoire ''soft'', et en relançant la compilation et la génération216 du fichier ''bin.soft''.217 218 Modifiez le fichier ''main.c'', pour que les programme C exécute une boucle infinie dans laquelle on effectue successivement214 simplement en modifiant le fichier `main.c` dans le répertoire `soft`, et en relançant la compilation et la génération 215 du fichier `bin.soft`. 216 217 Modifiez le fichier `main.c`, pour que les programme C exécute une boucle infinie dans laquelle on effectue successivement 219 218 les opérations suivantes : 220 219 221 220 1. affichage du numéro de cycle et du numéro d'itération. 222 1. génération aléatoire de deux variables OPA et OPB de type ''int''.223 1. écriture de OPA dans le registre 'GCD_OPA''du coprocesseur GCD.224 1. écriture de OPB dans le registre ''GCD_OPB''du coprocesseur GCD.225 1. écriture dans le pseudo-registre ''GCD_START'' du coprocesseur LCD, pour démarrer la simulation.226 1. lecture du registre ''GCD_STATUS'' du coprocesseur LCD pour tester la fin du calcul.221 1. génération aléatoire de deux variables OPA et OPB de type `int`. 222 1. écriture de OPA dans le registre `GCD_OPA` du coprocesseur GCD. 223 1. écriture de OPB dans le registre `GCD_OPB` du coprocesseur GCD. 224 1. écriture dans le pseudo-registre `GCD_START` du coprocesseur GCD, pour démarrer la simulation. 225 1. lecture du registre `GCD_STATUS` du coprocesseur GCD pour tester la fin du calcul. 227 226 1. affichage du numéro d'itération, du numéro de cycle, des valeurs des opérandes et du résultat sur le TTY. 228 227 229 Pour afficher sur le terminal, on utilisera évidemment la fonction ''tty_printf()''.230 Pour obtenir le numéro de cycle, on utilisera la fonction ''proctime().231 Pour la génération aléatoire, on utilisera la fonction ''rand()''.232 Pour les accès au coprocesseur GCD on utilisera les fonctions ' spécifiques au coprocesseur LCD.228 Pour afficher sur le terminal, on utilisera évidemment la fonction `tty_printf()`. 229 Pour obtenir le numéro de cycle, on utilisera la fonction `proctime()`. 230 Pour la génération aléatoire, on utilisera la fonction `rand()`. 231 Pour les accès au coprocesseur GCD on utilisera les fonctions ''spécifiques'' au coprocesseur GCD. 233 232 234 233 Pour introduire un peu d'interactivité dans cet exercice, vous pouvez introduire dans la boucle 235 un appel à la fonction ''tty_getc()''qui lit un caractère au clavier, et bloque l'exécution du programme234 un appel à la fonction `tty_getc()` qui lit un caractère au clavier, et bloque l'exécution du programme 236 235 tant que le caractère n'est pas saisi. 237 236 238 Le code de ces fonctions est défini dans le fichier ''stdio.c'', et les prototypes239 sont définis dans le fichier ''stdio.h''.237 Le code de ces fonctions est défini dans le fichier `stdio.c`, et les prototypes 238 sont définis dans le fichier `stdio.h`. 240 239 241 240 = 5 Compte-rendu =