Changes between Version 42 and Version 43 of SoclibCourseTp3


Ignore:
Timestamp:
Nov 28, 2010, 4:04:42 PM (13 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • SoclibCourseTp3

    v42 v43  
    77= 1 Objectif =
    88
    9 L'objectif de ce troisième TP est d'introduire des processeurs programmables dans les architectures modélisées,
    10 puisque, pour des raisons de flexibilité et de re-utilisation des plate-formes matérielles, les concepteurs
    11 de systèmes intégrés essaient de réaliser le plus grand nombre possible de fonctions en logiciel, sur des processeurs
    12 généralistes, ou sur des processeurs de traitement du signal.
    13 
    14 On utilisera des processeurs RISC 32 bits, car ce type de processeur possède un très bon rapport (puissance de calcul) / (consommation énergétique).
    15 
    16 On introduira également dans l'architecture les mémoires embarquées contenant le code binaire
     9L'objectif de ce troisième TP est d'introduire des processeurs programmables dans les architectures modélisées.
     10Pour des raisons de flexibilité et de re-utilisation des plate-formes matérielles, les concepteurs
     11de systèmes intégrés essaient de réaliser le plus grand nombre possible de fonctions en logiciel, en utilisant
     12soit des processeurs GPP (General Purpose Processor), soit des processeurs DSP (Digital Signal Processor).
     13
     14On utilise des processeurs RISC 32 bits, car ce type de processeur possède un très bon rapport (puissance de calcul) / (consommation énergétique).
     15
     16On introduit également dans l'architecture les mémoires embarquées contenant le code binaire
    1717et les données de l'application logicielle.
    1818
    1919= 2 Architecture matérielle cible =
    2020
    21 L'architecture matérielle modélisée dans ce TP comporte un seul initiateur VCI et 4 cibles VCI :
     21L'architecture matérielle modélisée dans ce TP comporte un seul processeur initiateur VCI et 4 cibles VCI :
    2222
    2323[[Image(soclib_tp3_archi.png)]]
    2424
    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.
     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 le composant `Mips32Iss`, qui modélise un coeur de processeur Mips32.
    2626 * '''rom''' est une mémoire non inscriptible à interface VCI contenant le code de boot. On utilise le composant `VciSimpleRam`.
    2727 * '''ram''' est une mémoire inscriptible à interface VCI contenant le code et les données. On utilise également un composant `VciSimpleRam`.
    2828 * '''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`.
     29 * '''gcd''' est le coprocesseur cible réalisant le calcul du PGCD déjà utilisé dans le TP2.
     30 * '''vgsb''' est le bus système déjà utilisé dans le TP2.
    3131
    3232Les modèles de simulation des composants matériels instanciés dans cette architecture sont disponibles dans la bibliothèque SoCLib.
    3333Ils vous sont fournis, et vous n'aurez pas à les re-écrire vous-même.
    3434
    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).
     35Le composant `VciXcacheWrapper` peut être utilisé pour encapsuler différents processeur 32 bits. Le coeur du processeur est modélisé par un ISS (Instruction Set Simulator).
    3636Le type du proceseur instancié (MIP32, ARM, SPARCV8, PPC405, NIOS, !MicroBlaze, etc.) est défini par un paramètre template du composant `VciXcacheWrapper`.
    3737Consultez la documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici].
    3838
    39 Le composant `VciSimpleRam` est utilisé pour modéliser des mémoires inscriptibles embarquées (SRAM), ou
     39Le composant `VciSimpleRam` est utilisé pour modéliser des mémoires inscriptibles embarquées (SRAM). On utilise le même composant
    4040pour modéliser des mémoires non inscriptibles (ROM).
    4141Ce composants peut contenir un ou plusieurs segments (correspondant à des tranches disjointes
    … …  
    6161Les composants de la bibliothèque SoCLib permettent de modéliser des architectures matérielles complexes, capables d'exécuter des
    6262systè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 système d'exploitation minimal, constitué par un Gestionnaire d'Interruptions, Exceptions et Trappes (GIET), quelques appels systèmes
    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 Mips32, et il vous est fourni. Les programmes utilisateur seront écrits en langage C, par vous.
    66 
    67 Les processeurs disponibles dans SoCLib, sont en majorités des processeurs RISC, capables
     63système d'exploitation minimal, constitué par un Gestionnaire d'Interruptions, Exceptions et Trappes (GIET). Cet OS minimal fournit quelques appels systèmes
     64permettant aux programmes utilisateurs d'accéder aux périphériques, il traite les requêtes d'interruption vectorisées, et facilite le debug du logiciel embarqué en récupérant les exceptions.
     65Tout ce code système est  écrit en C et en assembleur MIPS32. Les programmes utilisateur seront écrits par vous en langage C.
     66
     67Les processeurs disponibles dans SoCLib sont principalement des processeurs RISC, capables
    6868de démarrer une instruction à chaque cycle, grâce à leur structure pipe-line.
    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.
     69Le processeur doit, à chaque instruction (donc à  chaque cycle) lire l'instruction dans le cache, la décoder et l'exécuter. En cas de MISS, c'est le contrôleur
     70du cache qui se charge de délencher une transaction VCI pour aller lire le code binaire chargé dans les mémoires embarquées.
    7071
    7172Le 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.
    … …  
    7576Il existe deux méthodes permettant de charger le code binaire dans les mémoires embarquées sur la puce:
    7677 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  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''.
     78 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 EPROM 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 en deux temps est utilisée pour le code applicatif, mais également pour le système d'exploitation embarqué. C'est pourquoi on appelle souvent ''bootloader'' le code de boot qui effectue ce chargement.
    7879
    7980La phase de chargement du système d'exploitation et du code applicatif  est en pratique exécutée à chaque mise sous tension,
    8081ou 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é,
    81 cette phase d'initialisation n'apporte plus beaucoup
    82 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.
     82cette phase d'initialisation 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.
    8383
    8484La plate-forme SoCLib fournit donc un service permettant d'initialiser directement les mémoires embarquées à partir du code contenu
    8585dans 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 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 au
    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.
     86est 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
     87à 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.
    9088
    9189On économise ainsi plusieurs millions de cycles de simulation, et le code de boot peut être beaucoup plus court (le code de boot