Changes between Version 48 and Version 49 of SoclibCourseTp3


Ignore:
Timestamp:
Nov 28, 2010, 11:52:02 PM (14 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • SoclibCourseTp3

    v48 v49  
    9898}}}
    9999
    100 Cette archive contient un très grand nombre de fichiers, car les composants matériels instanciés sont des objets complexes,
    101 qui font appel à beaucoup de code caché : Par exemple, le chargement initial  des mémoires embarquées ROM et RAM nécessite l'analyse du format de fichier binaire ELF.
    102 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.
    103 
    104 Vous pouvez consulter le fichier ''Makefile'' pour avoir la liste de tous les
    105 fichiers objets qui doivent être compilés pour générer le simulateur de cette architecture très simple.
    106 
    107 Elle contient également un sous-répertoire ''soft'' qui est utilisé pour la génération du logiciel embarqué.
    108 
    109 == 4.1 Segmentation de l'espace adressable ==
    110 
    111 Cette architecture nécessite la définition de 9 segments dans l'espace adressable, dont 7 correspondent à de la mémoire, et 2 correspondent à 2 périphériques adressables :
     100Outre les fichiers qui permettent de générer le simulateur de l'architecture matérielle, cette archive contient  également un sous-répertoire ''soft'' qui est utilisé pour la génération du logiciel embarqué.
     101
     102Pour cette architecture, il faut définir 9 segments dans l'espace adressable, dont 7 correspondent à de la mémoire, et 2 correspondent à 2 périphériques adressables :
    112103
    113104 * '''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.
    … …  
    129120Par ailleurs 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 composants matériels disponibles: nombre de processeurs, nombre de terminaux TTY. Ces paramètres devront donc être définis dans le fichier ''soft/ldscript''.
    130121
    131 == 4.2 Compilation du logiciel embarqué ==
     122== 4.1 Compilation du logiciel embarqué ==
    132123
    133124Le logiciel embarqué est défini dans deux types de fichiers.
    … …  
    176167Le fichier ''bin.soft'' contient le code binaire au format ELF, et le fichier ''bin.soft.txt'' contient un version desassemblée (donc lisible) de ce code binaire.
    177168
    178 == 4.3 Définition de l'architecture matérielle ==
    179 
    180 Vous devez Compléter le fichier ''tp3_top.cpp'':
    181  *  Il faut enregister les 7 segments dans la ''!MappingTable''. Consultez la documentation de la !MappingTable pour bien comprendre la signification des 4 arguments du constructeur de la !MappingTable, ainsi que la signification des 5 arguments du constructeur d'un segment.
    182  * Il faut définir les arguments de tous les constructeurs des composants matériels instanciés, ainsi que les valeurs de leurs paramètres template.
    183  * Il faut définir le cheminom  permettant au ''loader'' des composants ROM et RAM d'accéder au fichier ''bin.soft'' contenant le code binaire.
     169== 4.2 Description de l'architecture matérielle ==
     170
     171Pour ce qui concerne le matériel, faut commencer par  compléter le fichier ''tp3_top.cpp'' qui vous est fourni:
     172
     173 *  Il faut enregister les 9 segments dans la ''!MappingTable''. Consultez la documentation de la !MappingTable pour bien comprendre la signification des 4 arguments du constructeur de la !MappingTable, ainsi que la signification des 5 arguments du constructeur d'un segment.
     174 * Il faut définir 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.
     175 * Il faut définir l'argument du composant ''loader'' qui réalise le chargement du code binaire dans les mémoires ROM et RAM. Cet argument est une chaîne de caractères définissant le cheminom d'accès au fichier ''bin.soft''.
    184176 * Il faut enfin compléter la net-list en connectant les signaux du bus.
    185 
    186 Pour ce qui concerne le composant vci_xcache_wrapper, 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.
    187177 
    188178'''Question''' : Parmi les 9 segments utilisés dans cette l'architecture, lesquels doivent être non-cachables ?
    189179
    190 '''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
    191 pour déterminer la cible VCI désignée ? Cette information est un des arguments du constructeur de la !MappingTable.
     180'''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 pour déterminer la cible VCI désignée ? Cette information est un des arguments du constructeur de la !MappingTable.
    192181
    193182'''Question''' quels sont les bits d'adresse qui doivent être décodés par le contrôleur du cache, pour déterminer
    … …  
    195184Cette information est un autre argument du constructeur de la ''MappingTable''.
    196185
    197 Remarquez que, pour vous épargner un travail fastidieux, on a déjà modifié les fichiers ''.cpp'' de tous les
    198 composants qui dépendent de VCI (c'est à dire presque tous) pour préciser les valeurs des paramètres template :
    199 
    200 {{{
    201 template class VciGcdCoprocessor<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;
    202 }}}
    203 
    204 Lancez le Makefile qui vous est fourni dans le répertoire TP3, pour générer le simulateur `simulator.x`.
    205 
    206 == 4.5 Simulation ==
     186== 4.3 Génération du simulateur ==
     187
     188Les composants matériels modélisées dans les TP1 et TP2 étaient très simples.  Vous avez pu décrire vous-même, le comportement de ces composants, et vous avez pu écrire ''à la main'' le Makefile permettant d'enchaîner la compilation des modules avant de compiler la top-cell.
     189
     190Mais les composants instanciés ici (!VciXcacheWrapper, VciSimpleRam, et !VciMultiTty) sont des objets
     191nettement plus complexes, qui utilisent eux-même un gransd nombre d'autres composants.
     192Tous les fichiers sont accessibles sur le serveur SVN de SoCLib, qui fournit un service de
     193gestion de versions et supporte le développement coopératif de la plate-forme.
     194
     195Cependant l'exploitation de cette bibliothèque de modèles de simulation pose (au moins) deux problèmes :
     196
     197 1. Il faut identifier et localiser tous les fichiers nécessaires pour générer le simulateur d'une architecture particulière. L' architecture très simple proposée ici nécessite la compilation d'une centaine de fichiers.
     198D'une façon générale,  l'identification des fichiers nécessaires à la compilation est un travail non négligeable,
     199et la construction du Makefile peut devenir assez pénible.
     200
     201 2. Par ailleurs, la plupart des modèles ont des paramètres templates (puisque la plupart des composants ont des interfaces VCI, et que les largeurs des champs VCI sont définis par un paramètre template.
     202Pour chaque composant possédant un paramètre) template, il faut modifier le fichier ''.cpp''  pour préciser la valeur des paramètres template avant de lancer la compilation de ce composant (on dit qu'on instancie les ''template''). Vous avez fait ce travail dans le TP2, et c'est un travail fastidieux dès que les architectures deviennent complexes.
     203
     204La chaîne de compilation '''soclib-cc''' a pour but de résoudre ces deux problèmes dans le cas général,
     205en automatisant la recherche des dépendances, l'instanciation des templates, et l'appel du compilateur.
     206Pour permettre cette automatisation, tout composant logiciel de SoCLib est accompagné d'un fichier
     207de ''metadata'' (fichier possédant le suffixe {{{.sd}}}) qui contient les informations suivantes:
     208 * le nom de la classe C++
     209 * les paramètres templates associés, avec leurs types et les valeurs par défaut (si applicable)
     210 * les chemins d'accès aux fichiers d'en-tête (.h) et d'implémentation (.cpp)
     211 * la liste des ports d'interface du composant
     212 * la liste des dépendances vers d'autres composants
     213 * les paramètres du constructeur, avec leurs types
     214Ce fichier est écrit en un langage ad-hoc (mais que Python peut parser nativement), et on trouvera ci-dessous, à titre d'exemple, le fichier ''vci_simple_ram.sd'':
     215{{{
     216       
     217Module('caba:vci_simple_ram',
     218        classname = 'soclib::caba::VciSimpleRam',
     219        tmpl_parameters = [parameter.Module('vci_param',  default = 'caba:vci_param')],
     220        header_files = ['../source/include/vci_simple_ram.h',],
     221        implementation_files = ['../source/src/vci_simple_ram.cpp'],
     222        ports = [
     223                  Port('caba:vci_target', 'p_vci'),
     224                  Port('caba:bit_in', 'p_resetn', auto = 'resetn')     
     225                  Port('caba:clock_in', 'p_clk', auto = 'clock')
     226                  ],
     227        uses = [
     228                  Uses('caba:base_module'),
     229                  Uses('common:linked_access_buffer',
     230                             addr_t = parameter.StringExt('sc_dt::sc_uint<%d>', parameter.Reference('addr_size')),
     231                             id_t = parameter.StringExt('sc_dt::sc_uint<%d>', parameter.Reference('srcid_size'))),
     232                  Uses('common:loader'),
     233                  Uses('common:mapping_table',
     234                  ],
     235        instance_parameters = [
     236                  parameter.IntTab('ident'),
     237                  parameter.Module('mt', 'common:mapping_table', auto='env:mapping_table'),
     238                  parameter.Module('loader', 'common:loader', auto='env:loader'),
     239                  parameter.Int('latency')
     240                  ],
     241        extensions = [
     242                  'dsx:addressable=ident',
     243                  'dsx:get_ident=ident:p_vci',
     244                  'dsx:mapping_type=memory'],
     245)
     246}}}
     247
     248Il faut par ailleurs définir les caractéristiques de la top-cell dans un fichier de directives pour soclib-cc.
     249Ce fichier est habituellement suffixé par '''.desc''', mais le nom n'est pas imposé.
     250Ce fichier est également en langage parsable par Python, et contient : le nom de fichier de la top-cell SystemC, la liste des modèles des composants instanciés et les valeurs des paramètres template VCI.
     251Vous trouverez ci-dessous, à titre d'exemple, le fichier '''tp3_top.desc''' décrivant l'architecture du TP3:
     252
     253{{{
     254todo = Platform('caba', 'tp3_top.cpp',
     255            uses = [
     256                    Uses('caba:vci_xcache_wrapper', iss_t = 'common:mips32el'),
     257                    Uses('caba:vci_simple_ram'),
     258                    Uses('caba:vci_multi_tty'),
     259                    Uses('caba:vci_vgsb'),
     260                    Uses('caba:vci_gcd_coprocessor'),
     261                    Uses('common:mapping_table'),
     262                    Uses('common:elf_file_loader')],
     263            cell_size = 4,
     264            plen_size = 8,
     265            addr_size = 32,
     266            rerror_size = 1,
     267            clen_size = 1,
     268            rflag_size = 1,
     269            srcid_size = 12,
     270            pktid_size = 1,
     271            trdid_size = 1,
     272            wrplen_size = 1
     273)
     274}}}
     275
     276Complétez le fichier ''tp3_top.cpp'' qui vous est fourni, puis lancez la compilation avec la commande:
     277
     278{{{
     279$ soclib-cc -p tp3_top.desc -o simulator.x
     280}}}
     281
     282L'exécutable ''simulator.x'' devrait être créé dans le répertoire de travail ''TP3''.
     283
     284== 4.4 Simulation ==
    207285
    208286Lancez la simulation avec la commande :
    … …  
    211289}}}
    212290
    213 En cas de problème lors de l'éxécution, vous pouvez relancer la compilation du simulateur en activant le mode DEBUG.
    214 Il faut modifier le fichier Makefile en ajoutant un flag supplémentaire dans la list des flags de gcc :
    215 {{{
    216 CFLAGS = -Wno-deprecated -DSOCLIB_MODULE_DEBUG
    217 }}}
    218 
    219 Ce flag permet d'activer les directives de compilation conditionnelle qui se trouvent
    220 à la fois dans le fichier `tp3_top.cpp`, et dans les modèles des composants matériels.
     291En cas de problème lors de l'éxécution, vous pouvez relancer le simulateur en activant le mode DEBUG.
     292Il faut ajouter les deux arguments suivants sur la ligne de commande
     293{{{
     294$ ./simulator.x -DEBUG 0 -NCYCLES 10000
     295}}}
     296
     297Vous obtiendrez ainsi une trace d'exécution entre les cycles 0 et 10000, que vous pouvez rediriger vers un fichier.
    221298
    222299Pour attirer votre attention sur des erreurs fréquentes, faites les essais suivants :