Changes between Version 31 and Version 32 of MjpegCourse/Monopro


Ignore:
Timestamp:
Dec 2, 2010, 6:51:40 PM (14 years ago)
Author:
joel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MjpegCourse/Monopro

    v31 v32  
    11{{{
    22#!html
    3 <h1>TP2: Déploiement de l'application MJPEG sur une architecture SoC monoprocesseur </h1>
     3<h1>TP2 : Déploiement de l'application MJPEG sur une architecture SoC monoprocesseur </h1>
    44}}}
    55[[PageOutline]]
    66
    7 TP Précédent: MjpegCourse/Station
     7TP Précédent : MjpegCourse/Station
    88
    99= 0. Objectif =
    1010
    1111La première partie de ce TP vise à  montrer comment décrire - en utilisant le
    12 langage DSX/L -une architecture matérielle de système intégré sur puce exploitant les
    13 composants matériels de la bibliothèque SoCLib. On rappelle que la
    14 bibliothèque SoCLib contient un ensemble modèles de simulation de composants
    15 matériels (IP cores), décrits en langage SystemC. L'intérêt d'utiliser DSX
    16 (plutôt que de décrire directement l'architecture en langage SystemC),
    17 est qu'il permet de décrire facilement des architectures génériques
    18 (nombre variable de processeurs ou de bancs mémoire par exemple).
    19 
    20 La seconde partie du TP vous permettra d'utiliser DSX pour décrire et
    21 contrôler précisément le déploiement de l'application logicielle !SplitMsg,
    22 sur l'architecture matérielle décrite dans la première
    23 partie. On validera ce déploiement en simulant l'exécution du code binaire
    24 de l'application logicielle sur le modèle SystemC de
    25 l'architecture matérielle.
    26 
    27 La troisième partie du TP vous permettra d'atteindre notre véritable but, qui est
    28 de déployer l'application MJPEG du TP1 sur l'architecture de SoC monoprocesseur
    29 décrite dans la première partie, en contrôlant précisément le placement des tâches sur
    30 les processeurs ou coprocesseurs, et le placement des tampons de communication
    31 sur les bancs mémoire embarqués.
     12langage DSX/L - une architecture matérielle de système intégré sur puce, en
     13exploitant les composants matériels de la bibliothèque ''SoCLib''. On rappelle
     14que la bibliothèque SoCLib contient un ensemble modèles de simulation de
     15composants matériels (IP cores), décrits en langage SystemC. L'intérêt
     16d'utiliser DSX (plutôt que de décrire directement l'architecture en langage
     17SystemC), réside dans la facilité de décrire des architectures génériques (par
     18exemple, à nombre variable de processeurs ou bancs mémoire).
     19
     20La seconde partie du TP vous permettra d'utiliser DSX pour décrire et contrôler
     21précisément le déploiement de l'application logicielle !SplitMsg, sur
     22l'architecture matérielle décrite dans la première partie. On validera ce
     23déploiement en simulant l'exécution du code binaire de l'application logicielle
     24sur le modèle SystemC de l'architecture matérielle.
     25
     26La troisième partie du TP vous permettra d'atteindre notre véritable but, qui
     27est de déployer l'application MJPEG, vue au TP1, sur l'architecture de SoC
     28monoprocesseur décrite dans la première partie, en contrôlant précisément le
     29placement des tâches sur les processeurs ou coprocesseurs, et le placement des
     30tampons de communication dans les bancs mémoire embarqués.
    3231
    3332= 1. Description de l'architecture matérielle =
    3433
    3534On se limitera dans ce TP à une architecture ne contenant qu'un seul processeur
    36 programmable de type MIPS32. Cette architecture matérielle est 
    37 appelée '!VgmnNoirqMono'.
     35programmable de type MIPS32. Cette architecture matérielle est
     36appelée '!VgmnNoirqMono' (voir schéma de l'architecture ci-contre).
    3837
    3938[[Image(MjpegCourse/VgmnNoirqMono:vgmn_noirq_mono.png, align=right)]]
    4039
    41  * Elle est organisée autour d'un micro-réseau générique à interface VCI (composant VGMN).
    42    Ce composant est générique en ce sens qu'il accepte un nombre quelconque d'inititiateurs
    43    VCI, et un nombre quelconque de cibles VCI, ainsi qu'un paramètre définissant
    44    la latence du réseau: nombre minimal de cycles pour une traversée du réseau
    45    "one-way".
    46  * Elle comporte un processeur et son cache, deux contrôleurs mémoire RAM0 et RAM1, et un contrôleur de terminal TTY.
    47 
    48 '''Attention''': les deux coprocesseurs matériels d'entrée/sortie TG et RAMDAC, doivent
    49 être décrits dans l'architecture !VgmnNoirqMono.
    50 
    51 Ces deux coprocesseurs, ainsi que les deux contrôleurs MWMR leur permettant d'accéder aux canaux MWMR ne sont utilisés
    52 que par l'application MJPEG, et pas par l'application !SplitMsg. Ils  seront
    53 donc inutiles pour !SplitMsg.
    54 
    55 Commencez par créer un répertoire de travail TP2.
    56 Pour faciliter la réutilisation, l'architecture matérielle est généralement décrite
    57 dans un fichier séparé. Créez, dans le répertoire TP2, le fichier `vgmn_noirq_mono.py`.
    58 [MjpegCourse/VgmnNoirqMono VgmnNoirqMono] contient une descrition incomplète que vous
    59 devez compléter, en consultant la documentation SoclibComponents qui définit les
    60 paramètres des différents composants de la bibliothèque SoCLib.
    61 
    62 [[Image(MjpegCourse:q.gif)]] Q1: '''''Quelle est la syntaxe utilisée par DSX pour exprimer
    63 que le port P,,0,, du composant matériel C,,0,, est connecté au port P,,1,, du composant matériel C,,1,,?'''''
    64 
    65 Une fois la description de la plateforme complète, nous pouvons la tester en générant
    66 une netlist SystemC  décrivant la ''top-cell''.
    67 
    68  * Rendez le fichier de description exécutable, lancez-le.
    69 
    70 Si tout se passe bien, vous devriez avoir un nouveau répertoire `hard` dans le répertoire courant.
    71 La description SystemC de la  ''top-cell'' est dans `hard/topcell.cpp`.
     40 * Elle est organisée autour d'un micro-réseau générique à interface VCI
     41 (composant VGMN).  Le VGMN est générique dans le sens où il accepte un nombre
     42 quelconque d'initiateurs VCI, et un nombre quelconque de cibles VCI, ainsi
     43 qu'un paramètre définissant la latence du réseau : c'est-à-dire le nombre
     44 minimal de cycles pour ''une'' traversée du réseau ("one-way").
     45 * Elle comporte un processeur et son cache, deux contrôleurs mémoire RAM0 et
     46 RAM1, et un contrôleur de terminal TTY.
     47
     48'''Attention''': pour l'application MJPEG, les deux coprocesseurs matériels
     49d'entrée/sortie TG et RAMDAC, doivent être décrits dans l'architecture
     50!VgmnNoirqMono. Cependant, ces deux coprocesseurs, ainsi que les deux
     51contrôleurs MWMR leur permettant d'accéder aux canaux MWMR, ne sont utilisés
     52que par l'application MJPEG, et pas par l'application !SplitMsg. Vous pouvez
     53donc les laisser commenter pour le moment.
     54
     55Commencez par créer un répertoire de travail `'TP2'`.  Pour faciliter la
     56réutilisation, l'architecture matérielle est généralement décrite dans un
     57fichier séparé. Créez, dans le répertoire TP2, le fichier `vgmn_noirq_mono.py`
     58et saisissez-y le contenu de [MjpegCourse/VgmnNoirqMono VgmnNoirqMono]. La
     59description que vous venez de saisir est incomplète : il vous faut donc
     60compléter le code à trou fourni (sachant que les trous sont signalés par le
     61texte `'*** remplir ***'`) en vous aidant de la documentation SoclibComponents
     62qui définit les paramètres des différents composants de la bibliothèque SoCLib.
     63
     64[[Image(MjpegCourse:q.gif)]] Q1 : '''''Quelle est la syntaxe utilisée par DSX
     65pour exprimer que le port P,,0,, du composant matériel C,,0,, est connecté au
     66port P,,1,, du composant matériel C,,1,,?'''''
     67
     68Une fois la description de la plateforme complète, nous pouvons la tester en
     69générant une description SystemC  décrivant la ''top-cell''.
     70
     71 * Rendez le fichier de description exécutable et exécutez-le.
     72
     73Si tout se passe bien, vous devriez avoir un nouveau répertoire nommé `hard`
     74dans le répertoire courant. La description SystemC de la ''top-cell'' est
     75contenue dans le fichier `hard/topcell_hard/topcell_hard.cpp`.
    7276
    7377= 2. Déploiement de l'application SplitMsg =
    7478
    75 On va commencer par déployer l'application !SplitMsg, qui ne comporte que deux tâches et un canal
    76 sur notre architecture de SoC monoprocesseur.
    77  * Créez dans le répertoire TP2 un sous-répertoire 'splitmsg'
    78  * Recopiez dans ce répertoire la description DSX vgmn_noirq_mono.py
    79  * Recopiez dans ce répertoire la description DSX de l'application !SplitMsg du TP1.
    80  * Modifiez la description `SplitMsg` en ajoutant après la description du TGG  l'instanciation de l'architecture matérielle !VgmnNoirqMono.
     79Vous allez commencer par déployer l'application !SplitMsg, qui ne comporte que
     80deux tâches et un canal sur votre architecture de SoC monoprocesseur.
     81
     82 * Créez dans le répertoire TP2 un sous-répertoire `'splitmsg'`.
     83 * Recopiez dans ce répertoire la description DSX `vgmn_noirq_mono.py` que vous
     84 venez d'écrire.
     85 * Recopiez dans ce répertoire la description DSX de l'application !SplitMsg
     86 que vous aviez écrite dans le TP1, ainsi que les sources de l'application
     87 (répertoire `src`).
     88 * Modifiez la description `SplitMsg` en ajoutant, après la description du TGG,
     89 l'instanciation de l'architecture matérielle !VgmnNoirqMono.
    8190
    8291{{{
    … …  
    95104}}}
    96105
    97  * Définissez le mapping de l'application !SplitMsg sur l'architecture !VgmnNoirqMono.
    98    Vous devez consulter la page DsxMapping pour plus d'informations.
    99 
    100    Dans cette section, un objet `Mapper` doit être créé.
    101    Supposons qu'on crée une variable `mapper`,
    102    les objets logiciels doivent être identifiés par leur nom.
    103    Il va falloir placer tous les canaux de communication, toutes les tâches,
    104    tous les objets logiciels associés aux processeurs et enfin les objets globaux du système; dans cet ordre.
     106 * Définissez le mapping de l'application !SplitMsg sur l'architecture
     107 !VgmnNoirqMono. Vous devez consulter la page DsxMapping pour plus
     108 d'informations.
     109
     110Dans cette section, un objet `Mapper` doit être créé. Supposons qu'on crée une
     111variable `mapper`, les objets logiciels doivent être identifiés par leur nom.
     112Il va falloir placer tous les canaux de communication, toutes les tâches, tous
     113les objets logiciels associés aux processeurs et enfin les objets globaux du
     114système (''dans cet ordre'').
    105115
    106116{{{
    … …  
    119129  desc    = "cram1")
    120130
    121 # mapping the "prod0" and "cons0" tasks 
     131# mapping the "prod0" and "cons0" tasks
    122132
    123133mapper.map("prod0",
    … …  
    155165{{{
    156166######################################################
    157 # Section D : Code generation 
     167# Section D : Code generation
    158168######################################################
    159169
    … …  
    169179
    170180
    171 [[Image(MjpegCourse:q.gif)]] Q2: '''''Quels objets logiciels doit-on placer dans
    172 l'espace addressable pour une tâche ? pour un canal mwmr ? pour un processeur ?'''''
    173 
    174  * Relancez l'exécution de la description DSX de votre application
    175 {{{
    176 $ ./SplitMsg.py
    177 }}}
    178 
    179  * Executez l'application logicielle sur la station de travail
     181[[Image(MjpegCourse:q.gif)]] Q2 : '''''Quels objets logiciels doit-on placer
     182dans l'espace addressable pour une tâche ? pour un canal mwmr ? pour un
     183processeur ?'''''
     184
     185 * Relancez l'exécution de la description DSX de votre application :
     186{{{
     187$ ./splitmsg.py
     188}}}
     189
     190 * Executez l'application logicielle sur la station de travail :
    180191{{{
    181192$ ./exe.posix
    182193}}}
    183  * Simulez l'exécution de l'application logicielle sur le modèle SystemC du SoC
     194 * Simulez l'exécution de l'application logicielle sur le modèle SystemC du SoC :
    184195{{{
    185196$ ./exe.muteks_hard
    186197}}}
    187198
    188 [[Image(MjpegCourse:q.gif)]] Q3: '''''Qu'observez-vous ? En quoi est-ce différent de ce
     199[[Image(MjpegCourse:q.gif)]] Q3 : '''''Qu'observez-vous ? En quoi est-ce différent de ce
    189200qui se passe dans la version pour station de travail ?'''''
    190201
    191202= 3. Déploiement de l'application MJPEG =
    192203
    193 L'application MJPEG est différente de l'application !SplitMsg car elle utilise deux
    194 périphériques d'entrée/sortie spécialisés :
    195  * le coprocesseur ''Tg'': un composant matériel qui récupère le flux binaire MJPEG
    196    (en analysant un signal radio-fréquence par exemple), effectue la conversion
    197    analogique/numérique et écrit le résultat dans un canal MWMR
    198  * le coprocesseur ''Ramdac'': un composant matériel qui lit une image décompressée
    199    dans un canal MWMR et génère le signal video pour affichage sur l'écran.
    200 
    201 Pour pouvoir déployer ces deux tâches sous forme de coprocesseurs matériels, il faut
    202 prévenir DSX qu'il existe des coprocesseurs implémentant ces tâches. Nous allons donc
    203 modifier les déclarations des modèles de tâches en conséquence.
    204 
    205 Retournez dans le répertoire mjpeg du TP1, et exécutez la commande  {{{./mjpeg -m clean}}}
    206 qui détruit tous les fichiers générés par les différentes compilations effectuées.
    207 Ce ménage est indispensable pour vous éviter de dépasser votre quota d'espace
    208 disque. Recopiez ce répertoire `mjpeg` nettoyé dans votre répertoire TP2.
    209 
    210 Dans la description DSX de l'application MJPEG, modifiez la définition des modèles de tâches
    211 `tg` et `ramdac` pour introduire leurs implémentations matérielles.
    212 Comme ces deux implémentations sont définies dans soclib, la directive
    213 {{{import soclib}}} doit être présente avant la description des tâches dans
    214 votre fichier de description de tâche (`.task`).
     204L'application MJPEG est différente de l'application !SplitMsg car elle utilise
     205deux périphériques d'entrée/sortie spécialisés :
     206 * le coprocesseur ''Tg'' : un composant matériel qui récupère le flux binaire
     207 MJPEG (fournit par un signal radio-fréquence, par exemple), effectue la
     208 conversion analogique/numérique et écrit le résultat dans un canal MWMR
     209 * le coprocesseur ''Ramdac'' : un composant matériel qui lit une image
     210 décompressée dans un canal MWMR et génère le signal video pour affichage sur
     211 l'écran.
     212
     213Pour pouvoir déployer ces deux tâches sous forme de coprocesseurs matériels, il
     214faut prévenir DSX qu'il existe des coprocesseurs implémentant ces tâches. Vous
     215allez donc modifier les déclarations des modèles de tâches en conséquence.
     216
     217Retournez dans le répertoire mjpeg du TP1, et exécutez la commande  {{{./mjpeg
     218-m clean}}} qui détruit tous les fichiers générés par les différentes
     219compilations effectuées. Ce ménage est indispensable pour vous éviter de
     220dépasser votre quota d'espace disque. Recopiez ce répertoire `mjpeg` nettoyé
     221dans votre répertoire TP2.
     222
     223Modifiez la définition des modèles de tâches `tg` et `ramdac` pour introduire
     224leurs implémentations matérielles.  Comme ces deux implémentations sont
     225définies dans soclib, la directive {{{import soclib}}} doit être présente avant
     226la description des tâches dans votre fichier de description de tâche (`.task`).
     227
    215228 * Pour la tâche `tg`, modifiez la déclaration de la tâche pour ajouter l'implémentation matérielle virtuelle (`SyntheticTask`):
    216229{{{
    … …  
    230243 * De même, pour la tâche `ramdac`.
    231244
    232 Décommentez ensuite la partie de la netlist qui instancie les composants tg et ramdac.
    233 
    234  * En vous inspirant de ce qui a été fait pour déployer !SplitMsg, déployez l'application MJPEG
    235    sur la plateforme.
    236    * Les coprocesseurs `tg` et `ramdac` sont spécifiques, ils doivent
    237      faire l'objet d'un déploiement non pas en tant que tâches logicielles sur un processeur, mais
    238      en tant que coprocesseurs rattachés à un contrôleur MWMR. Un déploiement valide pour `tg` est par exemple:
    239 {{{
    240 m.map('tg',
     245 * Recopiez dans le répertoire `mjpeg` la description DSX `vgmn_noirq_mono.py`
     246 que vous avez écrite dans la première partie, puis décommentez la partie de la
     247 description qui instancie les composants tg et ramdac.
     248
     249 * En vous inspirant de ce qui a été fait pour déployer !SplitMsg, déployez
     250 l'application MJPEG sur la plateforme en complétant le fichier de description
     251 `mjpeg`.
     252   * Les coprocesseurs `tg` et `ramdac` sont spécifiques, ils doivent faire
     253   l'objet d'un déploiement non pas en tant que tâches logicielles sur un
     254   processeur, mais en tant que coprocesseurs rattachés à un contrôleur MWMR.
     255   Un déploiement valide pour `tg` est par exemple :
     256{{{
     257mapper.map('tg',
    241258          coprocessor = 'tg0',
    242259          controller = 'tg0_ctrl'
    243260          )
    244261}}}
    245    * De même déployez `ramdac` sur la plateforme.
    246  * Relancez la description, recompilez, lancez la simulation.
    247 {{{
    248 $ ./description
     262 * Relancez la description, recompilez et lancez la simulation.
     263{{{
     264$ ./mjpeg
    249265$ ./exe.muteks_hard
    250266}}}
    … …  
    255271}}}
    256272
    257 L'avion fait le "tour" en 25 images. Vous avez un compteur de cycles sur le terminal qui contient le simulateur.
    258 [[BR]]
    259 [[Image(MjpegCourse:q.gif)]] Q4: '''''Combien faut-il de cycles, approximativement,  pour décompresser 25 images ?'''''
    260 
    261 [[Image(MjpegCourse:q.gif)]] Q5: '''''Supposant un SoC cadencé à 200MHz, combien d'images sont affichées en une seconde ?'''''
     273L'avion fait le "tour" en 25 images. Vous avez un compteur de cycles sur le
     274terminal qui contient le simulateur.
     275
     276[[Image(MjpegCourse:q.gif)]] Q4 : '''''Combien faut-il de cycles,
     277approximativement, pour décompresser 25 images ?'''''
     278
     279[[Image(MjpegCourse:q.gif)]] Q5 : '''''Supposant un SoC cadencé à 200MHz,
     280combien d'images sont affichées en une seconde ?'''''
    262281
    263282= 4. Influence du système d'exploitation embarqué =
    264283
    265 L'environnement DSX permet actuellement d'utiliser deux systèmes d'exploitation embarqués.
    266 
    267  * Mutek/S, un noyau "statique", ne fournissant pas la compatibilité POSIX. En particulier, il ne permet pas la création dynamique de tâches au moment de l'exécution.
    268  * Mutek/H, un noyau fournissant aux applications l'API des threads POSIX (y compris la création dynamique de tâches), permettant d'héberger sur le même système des applications tierces.
    269 
    270 Modifiez la description DSX de l'application MJPEG, pour utiliser l'OS Mutek/H. La section D devient:
     284L'environnement DSX permet actuellement d'utiliser deux systèmes d'exploitation
     285embarqués.
     286
     287 * Mutek/S, un noyau "statique", ne fournissant pas la compatibilité POSIX. En
     288 particulier, il ne permet pas la création dynamique de tâches au moment de
     289 l'exécution.
     290 * Mutek/H, un noyau fournissant aux applications l'API des threads POSIX (y
     291 compris la création dynamique de tâches), permettant d'héberger sur le même
     292 système des applications tierces.
     293
     294Modifiez la description DSX de l'application MJPEG, pour utiliser l'OS Mutek/H.
     295La section D devient:
    271296{{{
    272297mapper.generate( dsx.MutekS() )
    … …  
    274299}}}
    275300
    276  * Relancez la description, recompilez, lancez la simulation du SoC avec Mutek/H
    277    (attention, il y a deux simulateurs avec des noms différents)
    278 {{{
    279 $ ./description
     301 * Relancez la description, recompilez et lancez la simulation du SoC avec
     302 Mutek/H (attention, il y a deux simulateurs avec des noms différents)
     303{{{
     304$ ./mjpeg
    280305$ ./exe.mutekh_hard
    281306}}}
    282307
    283 [[Image(MjpegCourse:q.gif)]] Q6: '''''Combien de cyles faut-il pour décompresser 25 images avec MUTEK/H? Comment expliquer ce résultat?'''''
    284 
    285 [[Image(MjpegCourse:q.gif)]] Q7: '''''En consultant les headers de l'objet binaire généré, déterminez la capacité mémoire des deux bancs mémoire RAM0 et RAM1 suivant qu'on utilise MUTEK/S ou MUTEK/H.'''''
    286 
     308[[Image(MjpegCourse:q.gif)]] Q6 : '''''Combien de cyles faut-il pour
     309décompresser 25 images avec Mutek/H? Comment expliquer ce résultat ?'''''
     310
     311[[Image(MjpegCourse:q.gif)]] Q7 : '''''En consultant les headers de l'objet
     312binaire généré, déterminez la capacité mémoire des deux bancs mémoire RAM0 et
     313RAM1 suivant qu'on utilise Mutek/S ou Mutek/H.'''''
     314
     315Pour analyser les headers d'un fichier binaire, servez vous des commandes
     316suivantes :
    287317{{{
    288318$ mipsel-unknown-elf-objdump -h muteks/soft/bin.soft
    … …  
    292322= 5. Compte-rendu =
    293323
    294 Vous rendrez une archive dans le même format que la semaine précédente, nommée `binome0_binome1.tar.gz`, contenant exactement les fichiers:
     324Vous rendrez une archive dans le même format que la semaine précédente, nommée
     325`binome0_binome1.tar.gz`, contenant exactement les fichiers:
    295326{{{
    296327tp2/
    … …  
    313344}}}
    314345
    315  * Les fichiers `splitmsg.py` et `mjpeg.py` seront complets, avec vos descriptions de TCG et le mapping.
    316    Pour mjpeg, il y aura les directives de génération de code pour Mutek/S et Mutek/D.
    317  * Le répertoire `mjpeg/src` contiendra uniquement les implémentation de vos deux tâches libu et iqzz
    318    (éventuellement mises à jour par rapport à la semaine dernière) vous ayant servi à exécuter les tests de ce TP.
    319  * Le rapport sera court (une table des matières pour dire que tout est sur la même page est superflue), répondant aux questions
    320    posées dans le texte, nommé exactement `tp2/rapport.pdf`.
    321 
    322 Vous livrerez cette archive avant jeudi 15 octobre 2009, 16h00 GMT (18h00 à Paris) à [MailAsim:nipo Nicolas Pouillon].
     346 * Les fichiers `splitmsg.py` et `mjpeg.py` seront complets, avec vos
     347 descriptions de TCG et le mapping. Pour mjpeg, il y aura les directives de
     348 génération de code pour Mutek/S et Mutek/H.
     349 * Le répertoire `mjpeg/src` contiendra uniquement les implémentation de vos
     350 deux tâches libu et iqzz (éventuellement mises à jour par rapport à la semaine
     351 dernière) vous ayant servi à exécuter les tests de ce TP.
     352 * Le rapport sera court (une table des matières pour dire que tout est sur la
     353 même page est superflue), répondant aux questions posées dans le texte, et
     354 nommé exactement `tp2/rapport.pdf`.
     355
     356Vous enverrez cette archive avant le jeudi 16/12/2010, 18h00 (heure de Paris) à
     357[MailAsim:joel.porquet Joël Porquet].
    323358
    324359= Suite =
    325360
    326 TP Suivant: MjpegCourse/Multipro
     361TP Suivant : MjpegCourse/Multipro