{{{
#!html
TP2: Déploiement de l'application MJPEG sur une architecture SoC monoprocesseur
}}}
[[PageOutline]]
TP Précédent: MjpegCourse/Station
= 0. Objectif =
La première partie de ce TP vise à montrer comment décrire - en utilisant le
langage DSX/L -une architecture matérielle de système intégré sur puce exploitant les
composants matériels de la bibliothèque SoCLib. On rappelle que la
bibliothèque SoCLib contient un ensemble modèles de simulation de composants
matériels (IP cores), décrits en langage SystemC. L'intérêt d'utiliser DSX
(plutôt que de décrire directement l'architecture en langage SystemC),
est qu'il permet de décrire facilement des architectures génériques
(nombre variable de processeurs ou de bancs mémoire par exemple).
La seconde partie du TP vous permettra d'utiliser DSX pour décrire et
contrôler précisément le déploiement de l'application logicielle !SplitMsg,
sur l'architecture matérielle décrite dans la première
partie. On validera ce déploiement en simulant l'exécution du code binaire
de l'application logicielle sur le modèle SystemC de
l'architecture matérielle.
La troisième partie du TP vous permettra d'atteindre notre véritable but, qui est
de déployer l'application MJPEG du TP1 sur l'architecture de SoC monoprocesseur
décrite dans la première partie, en contrôlant précisément le placement des tâches sur
les processeurs ou coprocesseurs, et le placement des tampons de communication
sur les bancs mémoire embarqués.
= 1. Description de l'architecture matérielle =
On se limitera dans ce TP à une architecture ne contenant qu'un seul processeur
programmable de type MIPS32. Cette architecture matérielle est
appelée '!VgmnNoirqMono'.
[[Image(MjpegCourse/VgmnNoirqMono:vgmn_noirq_mono.png, align=right)]]
* Elle est organisée autour d'un micro-réseau générique à interface VCI (composant VGMN).
Ce composant est générique en ce sens qu'il accepte un nombre quelconque d'inititiateurs
VCI, et un nombre quelconque de cibles VCI, ainsi qu'un paramètre définissant
la latence du réseau: nombre minimal de cycles pour une traversée du réseau
"one-way".
* Elle comporte un processeur et son cache, deux contrôleurs mémoire RAM0 et RAM1, et un contrôleur de terminal TTY.
'''Attention''': les deux coprocesseurs matériels d'entrée/sortie TG et RAMDAC, doivent
être décrits dans l'architecture !VgmnNoirqMono.
Ces deux coprocesseurs, ainsi que les deux contrôleurs MWMR leur permettant d'accéder aux canaux MWMR ne sont utilisés
que par l'application MJPEG, et pas par l'application !SplitMsg. Ils seront
donc inutiles pour !SplitMsg.
Commencez par créer un répertoire de travail TP2.
Pour faciliter la réutilisation, l'architecture matérielle est généralement décrite
dans un fichier séparé. Créez, dans le répertoire TP2, le fichier `vgmn_noirq_mono.py`.
[MjpegCourse/VgmnNoirqMono VgmnNoirqMono] contient une descrition incomplète que vous
devez compléter, en consultant la documentation SoclibComponents qui définit les
paramètres des différents composants de la bibliothèque SoCLib.
[[Image(MjpegCourse:q.gif)]] Q1: '''''Quelle est la syntaxe utilisée par DSX pour exprimer
que le port P,,0,, du composant matériel C,,0,, est connecté au port P,,1,, du composant matériel C,,1,,?'''''
Une fois la description de la plateforme complète, nous pouvons la tester en générant
une netlist SystemC décrivant la ''top-cell''.
* Rendez le fichier de description exécutable, lancez-le.
Si tout se passe bien, vous devriez avoir un nouveau répertoire `hard` dans le répertoire courant.
La description SystemC de la ''top-cell'' est dans `hard/topcell.cpp`.
= 2. Déploiement de l'application SplitMsg =
On va commencer par déployer l'application !SplitMsg, qui ne comporte que deux tâches et un canal
sur notre architecture de SoC monoprocesseur.
* Créez dans le répertoire TP2 un sous-répertoire 'splitmsg'
* Recopiez dans ce répertoire la description DSX de l'application !SplitMsg du TP1.
* Recopiez dans ce répertoire la description DSX vgmn_noirq_mono.py
* Modifiez cette description DSX en ajoutant après la description du TGG l'instanciation de l'architecture matérielle !VgmnNoirqMono.
{{{
#########################################################
# Section B : Hardware architecture
#
# The file containing the architecture definition
# must be included, and the path to the directory
# containing this file must be defined
#########################################################
from vgmn_noirq_mono import VgmnNoirqMono
archi = VgmnNoirqMono()
}}}
* Définissez le mapping de l'application !SplitMsg sur l'architecture !VgmnNoirqMono.
Vous devez consulter la page DsxMapping pour plus d'informations.
Dans cette section, un objet `Mapper` doit être créé.
Supposons qu'on crée une variable `mapper`,
les objets logiciels doivent être identifiés par leur nom.
Il va falloir placer tous les canaux de communication, toutes les tâches,
tous les objets logiciels associés aux processeurs et enfin les objets globaux du système; dans cet ordre.
{{{
#########################################################
# Section C : Mapping
#
#########################################################
mapper = dsx.Mapper(archi, tcg)
# mapping the MWMR channel
mapper.map( "fifo0",
buffer = "cram1",
status = "cram1",
desc = "cram1")
# mapping the "prod0" and "cons0" tasks
mapper.map("prod0",
run = "cpu0",
stack = "cram0",
desc = "cram0",
status = "uram0")
mapper.map("cons0",
run = "cpu0",
stack = "cram0",
desc = "cram0",
status = "uram0")
# mapping the software objects associated to a processor
mapper.map( 'cpu0',
private = "cram0",
shared = "cram0")
# mapping the software objects used by the embedded OS
mapper.map(tcg,
private = "cram1",
shared = "uram1",
code = "cram1",
# These lines are for getting output messages:
tty = "tty0",
tty_no = 0)
}}}
* La dernière étape consiste à générer le code
{{{
######################################################
# Section D : Code generation
######################################################
# Embedded software linked with the Mutek/S OS
mapper.generate( dsx.MutekS() )
# The software application for a POSX workstation can still be generated
tcg.generate( dsx.Posix() )
}}}
[[Image(MjpegCourse:q.gif)]] Q2: '''''Quels objets logiciels doit-on placer dans
l'espace addressable pour une tâche ? pour un canal mwmr ? pour un processeur ?'''''
* Relancez l'exécution de la description DSX de votre application
{{{
$ ./SplitMsg.py
}}}
* Executez l'application logicielle sur la station de travail
{{{
$ ./exe.posix
}}}
* Simulez l'exécution de l'application logicielle sur le modèle SystemC du SoC
{{{
$ ./exe.muteks_hard
}}}
[[Image(MjpegCourse:q.gif)]] Q3: '''''Qu'observez-vous ? En quoi est-ce différent de ce
qui se passe dans la version pour station de travail ?'''''
= 3. Déploiement de l'application MJPEG =
L'application MJPEG est différente de l'application !SplitMsg car elle utilise deux
périphériques d'entrée/sortie spécialisés :
* le coprocesseur ''Tg'': un composant matériel qui récupère le flux binaire MJPEG
(en analysant un signal radio-fréquence par exemple), effectue la conversion
analogique/numérique et écrit le résultat dans un canal MWMR
* le coprocesseur ''Ramdac'': un composant matériel qui lit une image décompressée
dans un canal MWMR et génère le signal video pour affichage sur l'écran.
Pour pouvoir déployer ces deux tâches sous forme de coprocesseurs matériels, il faut
prévenir DSX qu'il existe des coprocesseurs implémentant ces tâches. Nous allons donc
modifier les déclarations des modèles de tâches en conséquence.
Retournez dans le répertoire mjpeg du TP1, et exécutez la commande {{{./mjpeg -m clean}}}
qui détruit tous les fichiers générés par les différentes compilations effectuées.
Ce ménage est indispensable pour vous éviter de dépasser votre quota d'espace
disque. Recopiez ce répertoire `mjpeg` nettoyé dans votre répertoire TP2.
Dans la description DSX de l'application MJPEG, modifiez la définition des modèles de tâches
`tg` et `ramdac` pour introduire leurs implémentations matérielles.
Comme ces deux implémentations sont définies dans soclib, la directive
{{{import soclib}}} doit être présente avant la description des tâches dans
votre fichier de description de tâche (`.task`).
* Pour la tâche `tg`, modifiez la déclaration de la tâche pour ajouter l'implémentation matérielle virtuelle (`SyntheticTask`):
{{{
from soclib import SyntheticTask
TaskModel(
'tg',
ports = {'output':MwmrOutput(32)},
impls = [ SwTask( 'tg',
bootstrap = 'bootstrap',
stack_size = 4096,
sources = [ 'tg.c' ],
defines = [ 'FILE_NAME' ] ),
SyntheticTask( defines = {"FILE_NAME":'"plan.jpg"'} )
] )
}}}
* De même, pour la tâche `ramdac`.
Décommentez ensuite la partie de la netlist qui instancie les composants tg et ramdac.
* En vous inspirant de ce qui a été fait pour déployer !SplitMsg, déployez l'application MJPEG
sur la plateforme.
* Les coprocesseurs `tg` et `ramdac` sont spécifiques, ils doivent
faire l'objet d'un déploiement non pas en tant que tâches logicielles sur un processeur, mais
en tant que coprocesseurs rattachés à un contrôleur MWMR. Un déploiement valide pour `tg` est par exemple:
{{{
m.map('tg',
coprocessor = 'tg0',
controller = 'tg0_ctrl'
)
}}}
* De même déployez `ramdac` sur la plateforme.
* Relancez la description, recompilez, lancez la simulation.
{{{
$ ./description
$ ./exe.muteks_hard
}}}
Pour avoir des statistiques, vous pouvez positionner la variable d'environnement `STATS_EVERY` à un nombre de cycles (500000 semble une bonne valeur):
{{{
$ STATS_EVERY=500000 ./exe.muteks_hard
}}}
L'avion fait le "tour" en 25 images. Vous avez un compteur de cycles sur le terminal qui contient le simulateur.
[[BR]]
[[Image(MjpegCourse:q.gif)]] Q4: '''''Combien faut-il de cycles, approximativement, pour décompresser 25 images ?'''''
[[Image(MjpegCourse:q.gif)]] Q5: '''''Supposant un SoC cadencé à 200MHz, combien d'images sont affichées en une seconde ?'''''
= 4. Influence du système d'exploitation embarqué =
L'environnement DSX permet actuellement d'utiliser deux systèmes d'exploitation embarqués.
* 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.
* 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.
Modifiez la description DSX de l'application MJPEG, pour utiliser l'OS Mutek/H. La section D devient:
{{{
mapper.generate( dsx.MutekS() )
mapper.generate( dsx.MutekH() )
}}}
* Relancez la description, recompilez, lancez la simulation du SoC avec Mutek/H
(attention, il y a deux simulateurs avec des noms différents)
{{{
$ ./description
$ ./exe.mutekh_hard
}}}
[[Image(MjpegCourse:q.gif)]] Q6: '''''Combien de cyles faut-il pour décompresser 25 images avec MUTEK/H? Comment expliquer ce résultat?'''''
[[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.'''''
{{{
$ mipsel-unknown-elf-objdump -h muteks/soft/bin.soft
$ mipsel-unknown-elf-objdump -h mutekh/soft/bin.soft
}}}
= 5. Compte-rendu =
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:
{{{
tp2/
tp2/rapport.pdf
tp2/vgmn_noirq_mono.py
tp2/splitmsg/
tp2/splitmsg/producer.c
tp2/splitmsg/producer.task
tp2/splitmsg/consumer.c
tp2/splitmsg/consumer.task
tp2/splitmsg/splitmsg.py
tp2/mjpeg/mjpeg.py
tp2/mjpeg/src/
tp2/mjpeg/src/iqzz/
tp2/mjpeg/src/iqzz/iqzz.c
tp2/mjpeg/src/iqzz/iqzz.task
tp2/mjpeg/src/libu/
tp2/mjpeg/src/libu/libu.c
tp2/mjpeg/src/libu/libu.task
}}}
* Les fichiers `splitmsg.py` et `mjpeg.py` seront complets, avec vos descriptions de TCG et le mapping.
Pour mjpeg, il y aura les directives de génération de code pour Mutek/S et Mutek/D.
* Le répertoire `mjpeg/src` contiendra uniquement les implémentation de vos deux tâches libu et iqzz
(éventuellement mises à jour par rapport à la semaine dernière) vous ayant servi à exécuter les tests de ce TP.
* 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
posées dans le texte, nommé exactement `tp2/rapport.pdf`.
Vous livrerez cette archive avant jeudi 15 octobre 2009, 16h00 GMT (18h00 à Paris) à [MailAsim:nipo Nicolas Pouillon].
= Suite =
TP Suivant: MjpegCourse/Multipro