Changes between Version 83 and Version 84 of SoclibCourseTp3


Ignore:
Timestamp:
Oct 23, 2020, 3:16:15 AM (4 years ago)
Author:
franck
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SoclibCourseTp3

    v83 v84  
    3232
    3333Les modèles de simulation des composants matériels instanciés dans cette architecture sont disponibles dans la bibliothèque SoCLib.
    34 Ils vous sont fournis, et vous n'aurez pas à les re-écrire vous-même.
     34Ils vous sont fournis, et vous n'aurez pas à les reécrire vous-même.
    3535
    3636Le composant '''!VciXcacheWrapper''' peut encapsuler différents processeurs RISC 32 bits. Le coeur du processeur est modélisé par un ISS (Instruction Set Simulator).
    37 Le type du proceseur instancié (MIP32, ARM, SPARCV8, PPC405, NIOS, !MicroBlaze, etc.) est défini par un paramètre template du composant `VciXcacheWrapper`.
     37Le type du processeur instancié (MIP32, ARM, SPARCV8, PPC405, NIOS, !MicroBlaze, etc.) est défini par un paramètre template du composant `VciXcacheWrapper`.
    3838Consultez la documentation [http://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici].
    3939
    4040Le composant '''!VciSimpleRam''' est utilisé pour modéliser des mémoires inscriptibles embarquées (SRAM). On utilise le même composant pour modéliser des mémoires non inscriptibles (ROM).
    41 Ce composants peut contenir un ou plusieurs segments (correspondant à des tranches disjointes
    42 de l'espace addressable). Le composant analyse les bits de poids fort de l'adresse VCI
     41Ce composant peut contenir un ou plusieurs segments (correspondant à des tranches disjointes
     42de l'espace adressable). Le composant analyse les bits de poids fort de l'adresse VCI
    4343pour déterminer le segment désigné. Les bancs de mémoire physique correspondant aux différents segments
    4444sont modélisés par des tableaux C++ dont la longueur est définie par les valeurs stockées dans la `MappingTable`.
    4545Consultez la documentation [http://www.soclib.fr/trac/dev/wiki/Component/VciSimpleRam ici].
    4646
    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.
     47Enfin le composant '''!VciMultiTty''' est un contrôleur de terminaux alphanumé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.
    4848Chaque terminal possède 4 registres adressables pour la lecture ou l'écriture, et fonctionne en mode ''caractère'':
    4949on ne peut lire ou écrire qu'un seul caractère par transaction VCI.
     
    6060Le GIET fournit principalement trois services:
    6161
    62  * un ''gestionnaires d'appels systèmes'' fournissant en particulier des fonctions d'accès aux périphériques.
    63  * un ''gestionnaire d'interruptions'' supportant un mécanismes d'interruptions vectorisées.
     62 * un ''gestionnaire d'appels systèmes'' fournissant en particulier des fonctions d'accès aux périphériques.
     63 * un ''gestionnaire d'interruptions'' supportant un mécanisme d'interruptions vectorisées.
    6464 * un ''gestionnaire d'exceptions'' permettant de traiter les erreurs des programmes utilisateurs.
    65 Les deux principales limitations du GIET, qui le différencient d'un ''vrai'' système d'exploitation, sont l'absence de support pour la mémoire virtuelle, et l'absence de support pour la création dynamique de tâches.
    66 
    67 Le code est donc séparé en deux parties : Les fichiers contenant le code système qui s'exécute en mode ''superviseur'' est contenu dans le répertoire '''sys''', tandis que les fichiers contenant le code applicatif qui s'exécute en mode ''utilisateur'' est contenu dans le répertoire '''app'''.
    68 
    69  * Le fichier '''sys_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'appels systèmes, chargé d'appeler la fonction système correspondant au service demandé.
     65Les deux principales limitations du GIET, qui le différencie d'un ''vrai'' système d'exploitation, sont l'absence de support pour la mémoire virtuelle, et l'absence de support pour la création dynamique de tâches.
     66
     67Le code est donc séparé en deux parties : les fichiers contenant le code système qui s'exécute en mode ''superviseur'' sont contenus dans le répertoire '''sys''', tandis que les fichiers contenant le code applicatif qui s'exécute en mode ''utilisateur'' sont contenus dans le répertoire '''app'''.
     68
     69 * Le fichier '''sys_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'appels système, chargé d'appeler la fonction système correspondant au service demandé.
    7070 * Le fichier '''exc_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'exceptions, chargé de la signalisation et du traitement des erreurs détectées dans les programmes utilisateurs.
    7171 * Le fichier '''irq_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'interruptions, ainsi que les routines de traitement des interruptions (ISR).
    72  * Le fichier '''ctx_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire de changements de contexte, utilisé lorsque un processeur exécute plusieurs tâches en multiplexage temporel.
     72 * Le fichier '''ctx_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire de changements de contexte, utilisé lorsquun processeur exécute plusieurs tâches en multiplexage temporel.
    7373 * Le fichier '''drivers.c''' contient les fonctions d'accès aux périphériques. Il rassemble donc les ''pilotes'' de tous les périphériques de la machine.
    7474 * Le fichier '''common.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient les fonctions générales du système d'exploitation.
    7575 * Le fichier '''giet.s''' est écrit en assembleur MIPS32. Il est dans le répertoire '''sys''', et contient la fonction qui analyse la cause de l'appel au GIET, et la fonction de sauvegarde/restauration de contexte.
    76  * Le fichier '''stdio.c''' est écrit en C. Il est dans le répertoire '''app''' car il contient l'ensemble des appels systèmes qui peuvent être utilisés par un programme utilisateur écrit en C. Le nom de ce fichier provient du fait que la plupart des appels systèmes sont utilisés pour accéder aux périphériques.
     76 * Le fichier '''stdio.c''' est écrit en C. Il est dans le répertoire '''app''' car il contient l'ensemble des appels système qui peuvent être utilisés par un programme utilisateur écrit en C. Le nom de ce fichier provient du fait que la plupart des appels système sont utilisés pour accéder aux périphériques.
    7777
    7878Le code source du GIET est accessible et stocké dans le répertoire suivant:
     
    8282}}}
    8383
    84 Vous pouvez vous faire une copie privée de ces fichiers pourpouvoir les consulter plus facilement, mais il est fortement déconseillé d'utiliser cette copie locale pour générer le code binaire, le code du GIET peut évoluer, et il faut toujours utiliser la version de référence.
     84Vous pouvez vous faire une copie privée de ces fichiers pour pouvoir les consulter plus facilement, mais il est fortement déconseillé d'utiliser cette copie locale pour générer le code binaire, le code du GIET peut évoluer, et il faut toujours utiliser la version de référence.
    8585
    8686== 3.2 Génération du code ==
    8787
    88 Puisque le système et  les applications sont écrits écrits en langage C, il faut utiliser un cross-compilateur C spécifique au processeur MIPS32 pour générer d'une part le code applicatif, et d'autre part le code du système d'exploitation embarqué.
    89 
    90 Le résultat de la compilation consiste en deux fichiers binaire au format ELF, '''sys.bin''' et '''app.bin''', qui devront être chargés dans les mémoires embarquées du MPSoC.
     88Puisque le système et  les applications sont écrits en langage C, il faut utiliser un cross-compilateur C spécifique au processeur MIPS32 pour générer d'une part le code applicatif, et d'autre part le code du système d'exploitation embarqué.
     89
     90Le résultat de la compilation consiste en deux fichiers binaires au format ELF, '''sys.bin''' et '''app.bin''', qui devront être chargés dans les mémoires embarquées du MPSoC.
    9191
    9292== 3.3 Chargement du code ==
     
    9797
    9898La phase de chargement du système d'exploitation et du code applicatif  est en pratique exécutée à chaque mise sous tension,
    99 ou chaque fois qu'on active le signal NRESET. Elle peut être très longue (plusieurs millions de cycles). Un fois que le ''bootloader'' a été validé,
     99ou chaque fois qu'on active le signal NRESET. Elle peut être très longue (plusieurs millions de cycles). Une fois que le ''bootloader'' a été validé,
    100100cette phase de chargement du code n'apporte plus beaucoup d'information, quand on souhaite mettre au point ou mesurer les performances d'une application logicielle sur une architecture matérielle modélisée avec SoCLib.
    101101
    102102La plate-forme SoCLib fournit donc un service permettant d'initialiser directement les mémoires embarquées à partir du code contenu
    103103dans 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
    104 est réalisée avant le démarrage de la simulation. En pratique, ce chargement est réalisé par le constructeur du composant !VciSimpleRam, gràce à un argument `loader` qui lui permet d'accéder au contenu du fichier ELF contenant le code binaire. Ce constructeur posséde un autre argument lui permettant d'accéder
    105 à la `MappingTable`. Il peut donc déterminer quels segments ont été affectés à la RAM (ou à la la ROM) et lesquels doivent être initialisés.
     104est réalisée avant le démarrage de la simulation. En pratique, ce chargement est réalisé par le constructeur du composant !VciSimpleRam, grâce à un argument `loader` qui lui permet d'accéder au contenu du fichier ELF contenant le code binaire. Ce constructeur possède un autre argument lui permettant d'accéder
     105à la `MappingTable`. Il peut donc déterminer quels segments ont été affectés à la RAM (ou à la ROM) et lesquels doivent être initialisés.
    106106
    107107On économise ainsi plusieurs millions de cycles de simulation, et le code de boot peut être beaucoup plus court (le code de boot utilisé dans ce TP contient moins de 20 lignes d'assembleur).
     
    119119== 4.1 segmentation de l'espace adressable ==
    120120
    121 Pour cette architecture, il faut définir 9 segments dans l'espace adressable, dont 3 correspondent à l'application et 6 appartiennent au système d'exploitation (adrresses plus grandes que 0x80000000).
     121Pour cette architecture, il faut définir 9 segments dans l'espace adressable, dont 3 correspondent à l'application et 6 appartiennent au système d'exploitation (adresses plus grandes que 0x80000000).
    122122
    123123=== segments applicatifs ===
     
    135135 * '''seg_kcode''' est le segment contenant le code du système qui s'exécute en mode ''kernel''. Il s'agit principalement du code du Gestionnaire d'Interruptions, Exceptions, et Trappes (GIET), du code des fonctions système, ainsi que du code des routines d'interruption (ISR, pour interrupt Service Routine). Ce segment  est assigné à la RAM. L'adresse de base 0x80000000. On choisira une capacité de stockage de 64 Koctets.
    136136
    137  * '''seg_kdata''' est le segment contenant les données cachables du système d'exploitation. Il est assigné à la RAM. L'adresse de base est égale à 0x81000000. Sa capacité esr de 64Koctets. 
    138 
    139  * '''seg_kunc''' est le segment contenant les données non cachables du système d'exploitation. Il est assigné à la RAM. L'adresse de base est égale à 0x82000000. Sa capacité esr de 64Koctets. 
     137 * '''seg_kdata''' est le segment contenant les données cachables du système d'exploitation. Il est assigné à la RAM. L'adresse de base est égale à 0x81000000. Sa capacité est de 64Koctets. 
     138
     139 * '''seg_kunc''' est le segment contenant les données non cachables du système d'exploitation. Il est assigné à la RAM. L'adresse de base est égale à 0x82000000. Sa capacité est de 64Koctets. 
    140140
    141141 * '''seg_tty''' est le segment associé au contrôleur de terminaux TTY. On prendra pour adresse de base la valeur 0x90000000, et pour longueur 64 octets, ce qui permet d'adresser jusqu'à 4 terminaux indépendants.
     
    145145Les adresses de base des segments sont utilisées à la fois par le matériel et par le logiciel embarqué. Elles doivent donc être définies à deux endroits :
    146146
    147  1. Pour le matériel, les addresses de base et les longueurs des segments doivent être définies dans le fichier '''tp3_top.cpp''' pour ëtre stockées dans la !MappingTable. Elles sont utilisées dans la phase de configuration du matériel par les constructeurs des composants.
     147 1. Pour le matériel, les adresses de base et les longueurs des segments doivent être définies dans le fichier '''tp3_top.cpp''' pour être stockées dans la !MappingTable. Elles sont utilisées dans la phase de configuration du matériel par les constructeurs des composants.
    148148
    149149 1. Pour le logiciel, les adresses de base des segments doivent être définies dans le fichier '''soft/seg.ld''' qui contient les directives pour l'éditeur de liens lors de la compilation du logiciel embarqué.
     
    153153Le répertoire '''soft''' de l'archive qui vous est fournie contient les fichiers spécifiques à l'application embarquée :
    154154
    155  * Le GIET peut supporter des architectures comportant plusieurs processeur, mais les structures de données utilisées par le système doivent être dimensionnées en fonction du nombre de processeurs et du nombre de tâches parallèles. Ces paramètres sont définis dans le fichier '''soft/config.h'''.
     155 * Le GIET peut supporter des architectures comportant plusieurs processeurs, mais les structures de données utilisées par le système doivent être dimensionnées en fonction du nombre de processeurs et du nombre de tâches parallèles. Ces paramètres sont définis dans le fichier '''soft/config.h'''.
    156156
    157157 * 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'', mais il est spécifique à chaque plate-forme matérielle, car il est chargé d'initialiser les périphériques présents dans l'architecture. Il variera donc d'un TP à l'autre.
     
    174174}}}
    175175
    176 '''Question''' : Editez le fichier '''reset.s''', de façon à définir la taille du segment de pile. On choisira une taille de 64 Koctets.
     176'''Question''' : Éditez le fichier '''reset.s''', de façon à définir la taille du segment de pile. On choisira une taille de 64 Koctets.
    177177
    178178C'est le code de boot qui réalise le branchement vers la première instruction de l'application grâce à l'instruction ''eret''.
     
    191191Le fichier '''stdio.c''' contient l'ensemble des appels systèmes fournis par le GIET aux applications.
    192192
    193 '''Question''' : Editez le fichier '''stdio.c''' contenu dans le répertoire de référence du GIET. Quels sont les appels système qui permettent d'accéder à un terminal TTY ? Que trouve-t-on dans le code de chacun de ces appels système?
    194 
    195 Le fichier '''seg.ld''' est inclus dans les deux fichier '''sys.ld''' et '''app.ld''', et définit les adresses de base de tous les segments pour le logiciel.
     193'''Question''' : Éditez le fichier '''stdio.c''' contenu dans le répertoire de référence du GIET. Quels sont les appels système qui permettent d'accéder à un terminal TTY ? Que trouve-t-on dans le code de chacun de ces appels système?
     194
     195Le fichier '''seg.ld''' est inclus dans les deux fichiers '''sys.ld''' et '''app.ld''', et définit les adresses de base de tous les segments pour le logiciel.
    196196
    197197'''Question''' : Complétez le fichier '''seg_ld''' pour définir les adresses de base des différents segments.
    198198
    199 Lancez l'exécution du Makefile dans le répertoire ''soft''. Quatre fichiers doivent être créés:  '''app.bin''' et '''sys.bin'''  contiennent le code binaire au format ELF, et les fichier '''app.bin.txt'' et '''sys.bin.txt''' contiennent une version desassemblée (donc lisible) de ce code binaire.
    200 
    201 '''Question''' : Editez le fichier ''app.bin.txt''. Combien d'instructions assembleur ont été générées pour le programme main?  Vérifiez que l'adresse du point d'entrée dans le programme utilisateur est bien rangée au début du segment ''seg_data''.
     199Lancez l'exécution du Makefile dans le répertoire ''soft''. Quatre fichiers doivent être créés:  '''app.bin''' et '''sys.bin'''  contiennent le code binaire au format ELF, et les fichiers '''app.bin.txt'' et '''sys.bin.txt''' contiennent une version désassemblée (donc lisible) de ce code binaire.
     200
     201'''Question''' : Éditez le fichier ''app.bin.txt''. Combien d'instructions assembleur ont été générées pour le programme main?  Vérifiez que l'adresse du point d'entrée dans le programme utilisateur est bien rangée au début du segment ''seg_data''.
    202202
    203203== 4.3 Description de l'architecture matérielle ==
     
    213213'''Question''' : Définissez l'argument du composant ''loader'' qui réalise le chargement du code binaire dans les mémoires ROM et RAM. Cet argument est une liste de chaînes de caractères définissant les cheminoms des différents  fichiers ELF contenant du code binaire à charger en mémoire.
    214214
    215 '''Question''' : Définissez les arguments des constructeurs des composants matériels instanciés, ainsi que les valeurs de leurs paramètres template. Vous devez consulter la documentation des composants !VciXcacheWrapper et !VciSimpleRam pour comprendre la signification  des arguments. On choisira des caches à correspondance directe (c'est à dire un seul niveau d'associativité), ayant une capacité totale de 4 Koctets et des lignes de caches d'une longueur de 16 octets.
     215'''Question''' : Définissez les arguments des constructeurs des composants matériels instanciés, ainsi que les valeurs de leurs paramètres template. Vous devez consulter la documentation des composants !VciXcacheWrapper et !VciSimpleRam pour comprendre la signification  des arguments. On choisira des caches à correspondance directe (c'est-à-dire un seul niveau d'associativité), ayant une capacité totale de 4 Koctets et des lignes de caches d'une longueur de 16 octets.
    216216
    217217'''Question''' : Complétez la net-list en connectant les signaux du bus.
     
    219219== 4.4 Génération du simulateur ==
    220220
    221 Les composants matériels modélisées dans les TP1 et TP2 étaient très simples.  Vous avez pu décrire vous-même les modèles de simulation de ces composants, et vous avez pu écrire ''à la main'' le Makefile permettant de générer le simulateur.
     221Les composants matériels modélisés dans les TP1 et TP2 étaient très simples.  Vous avez pu décrire vous-même les modèles de simulation de ces composants, et vous avez pu écrire ''à la main'' le Makefile permettant de générer le simulateur.
    222222
    223223Mais les composants instanciés ici (!VciXcacheWrapper, !VciSimpleRam, et !VciMultiTty) sont des objets
    224 nettement plus complexes, qui utilisent eux-même un gransd nombre d'autres composants.
     224nettement plus complexes, qui utilisent eux-mêmes un grand nombre d'autres composants.
    225225Tous les fichiers sont accessibles sur le serveur SVN de SoCLib, qui fournit un service de
    226226gestion de versions et supporte le développement coopératif de la plate-forme. Mais l'exploitation de cette
     
    335335Pour attirer votre attention sur des erreurs fréquentes, faites les essais suivants :
    336336 1. Modifiez l'adresse de base du segment ''seg_gcd'' dans le fichier ''tp3_top.cpp'' pour lui donner la valeur 0xB0000000 au lieu de 0x9000000. Relancez la compilation et la simulation. Expliquez les résultats obtenus.
    337  1. Déclarez le segment correspondant au périphériques GCD (seg_gcd) comme cachables. Relancez la compilation et la simulation. Expliquez les résultats obtenus.
     337 1. Déclarez le segment correspondant au périphérique GCD (seg_gcd) comme cachable. Relancez la compilation et la simulation. Expliquez les résultats obtenus.
    338338 
    339339== 4.6 Modification du logiciel embarqué ==
    340340
    341341Puisque le logiciel embarqué est chargé dynamiquement dans la RAM et dans la ROM lors du lancement du simulateur,
    342 il est possible de modifier le logiciel embarqué (fichier '''app.bin'''), sans modifier l'architecture matérielle et donc sans regénérer le simulateur.
     342il est possible de modifier le logiciel embarqué (fichier '''app.bin'''), sans modifier l'architecture matérielle et donc sans régénérer le simulateur.
    343343
    344344On va donc maintenant écrire une application logicielle un peu plus complexe, qui utilise le coprocesseur GCD,
     
    346346du fichier '''bin.soft'''.
    347347
    348 '''Question:''' Modifiez le fichier '''main.c''', pour que les programme C exécute une boucle infinie dans laquelle on effectue successivement les opérations suivantes :
     348'''Question:''' Modifiez le fichier '''main.c''', pour que les programmes C exécute une boucle infinie dans laquelle on effectue successivement les opérations suivantes :
    349349
    350350 1. affichage du numéro de cycle et du numéro d'itération.
     
    367367= 5 Compte-rendu =
    368368
    369 Vous devez rédiger un compte-rendu pour ce TP, et une démonstration de votre simulateur au début du TP de la semaine suivante ou plus tard (vous devez organiser vos répertoire de TP proprement...).
     369Vous devez rédiger un compte-rendu pour ce TP, et une démonstration de votre simulateur au début du TP de la semaine suivante ou plus tard (vous devez organiser vos répertoires de TP proprement...).