Changes between Version 20 and Version 21 of MjpegCourse/Coproc


Ignore:
Timestamp:
Mar 7, 2007, 1:16:01 AM (18 years ago)
Author:
Nicolas Pouillon
Comment:

Modifs aléatoires

Legend:

Unmodified
Added
Removed
Modified

  • MjpegCourse/Coproc

    v20 v21  
    3434 * libération du verrou.
    3535
    36 Pour simplifier le travail de l'outil de synthèse de coprocesseur, et séparer clairement les fonctions de calcul et les
    37 fonctions de communication, ce n'est pas le coprocesseur matériel synthétisé qui implémente le
    38 protocole MWMR. On utilise pour accéder aux canaux MWMR un composant matériel générique, appelé contrôleur MWMR.
    39 Cet initiateur VCI est capable de lire ou d'écrire dans les canaux MWMR (en respectant le protocole à 5 étapes), et  fournit au coprocesseur
    40 autant d'interfaces de type FIFO que celui-ci en a besoin. Ce composant est également une cible VCI,
    41 puisqu'il doit être configuré par le logiciel. C'est ce même
    42 contrôleur MWMR qui a déjà été utilisé pour interfacer les composants matériels RAMDAC et TG.
     36Pour simplifier le travail de l'outil de synthèse de coprocesseur,
     37et séparer clairement les fonctions de calcul et les fonctions de communication,
     38ce n'est pas le coprocesseur matériel synthétisé qui implémente le  protocole MWMR.
     39On utilise pour accéder aux canaux MWMR un composant matériel générique, appelé
     40contrôleur MWMR. Cet initiateur VCI est capable de lire ou d'écrire dans les canaux
     41MWMR (en respectant le protocole à 5 étapes), et  fournit au coprocesseur autant d'interfaces
     42de type FIFO que celui-ci en a besoin. Ce composant est également une cible VCI,
     43puisqu'il doit être configuré par le logiciel. C'est ce même contrôleur MWMR qui a déjà
     44été utilisé pour interfacer les composants matériels `Ramdac` et `Tg`.
    4345
    44 Vous repartirez de la plateforme du [MjpegCourse/Multipro TP3]: !VgmnNoirqMulti, pour une architecture comportant 3 processeurs,
     46Vous repartirez de la plateforme du [MjpegCourse/Multipro TP3]:
     47!VgmnNoirqMulti, pour une architecture comportant 3 processeurs,
    4548et vous modifierez cette architecture, pour remplacer
    46 un des processeurs programmable par un coprocesseur matériel dédié à la transformation IDCT.
     49un des processeurs programmable par un coprocesseur matériel dédié à
     50la transformation IDCT.
    4751
    48 == Mettre ici le dessin de la plate-forme matérielle complête avec 2 processeur et 3 controleurs MWMR ==
     52[[Image(vgmn_coproc.png, align=right)]]
    4953
    5054Reprenez les fichiers du TP3:
    … …  
    5357 * Le code des tâches (`Libu` ne gère qu'un seul pipeline et `Split` n'existe pas)
    5458
    55 [[Image(MjpegCourse:q.gif)]] Q1.  Rappelez le temps
     59[[Image(MjpegCourse:q.gif)]] Rappelez le temps
    5660nécessaire pour décoder 25 images, dans le cas d'un déploiement
    5761utilisant 3 processeurs, lorsque la tâche {{{idct}}} est placée sur le premier processeur,
    … …  
    7377architecturale ''avant synthèse''.
    7478
     79[[Image(threader.png, align=right)]]
     80
    7581Pour cela, on commence par ''émuler'' le coprocesseur matériel - sans le synthétiser -
    76 en encapsulant la tâche logicielle {{{idct}}} existante dans un composant matériel générique
    77 appelé ''threader'', qui est un service fourni par l'environnement DSX.
    78 Pour ce qui concerne le matériel, ce composant ''threader'' s'interface avec le composant matériel
    79 ''contrôleur MWMR'', mais il est également capable de communiquer avec la tâche logicielle {{{idct}}},
    80 de façon a utiliser le code existant - sans modification - pour effectuer les calculs qui devront être réalisés par le
    81 coprocesseur matériel.
     82en encapsulant la tâche logicielle {{{idct}}} existante dans un composant matériel générique
     83qui est un service fourni par l'environnement DSX.
     84 * du côté matériel, ce composant s'interface avec le composant matériel ''contrôleur MWMR''
     85 * du côté logiciel, ce composant dialogue avec un processus hébergeant la tâche logicielle {{{idct}}}.
     86
     87Ceci permet une utilisation du code existant - sans modification - pour effectuer les calculs
     88qui devront être réalisés par le coprocesseur matériel.
     89
    8290En pratique, la simulation dans ce mode consiste à exécuter un programme parallèle comportant
    83 deux processus UNIX communicant entre eux par des ''pipes'' UNIX.
     91deux processus UNIX communicant entre eux par des ''pipes''.
    8492Le premier processus est le simulateur SystemC modélisant l'architecture matérielle
    85 (y compris le contrôleur MWMR et le composant ''threader''). Le second processus est la tâche logicielle encapsulée.
    86 
    87 == mettre ici le dessin contenant le threader ==
     93(y compris le contrôleur MWMR et le composant d'émulation), le second processus
     94est la tâche logicielle encapsulée.
    8895
    8996Pour utiliser un tel coprocesseur ''virtuel'', il faut modifier trois choses dans la description DSX:
    90  * dans la définition du modèle de la tâche {{{idct}}}, il faut ajouter l'implémentation `SyntheticTask()`. Le coprocesseur matériel étant paramètrable, il faut également définir un nouveau paramètre `EXEC_TIME` dans la liste des paramètres de la tâche {{{idct}}}. Ce paramètre permet de spécifier le nombre de cycles utilisés par le coprocesseur matériel pour effectuer la transformation IDCT d'un bloc de 64 pixels.
     97 * dans la définition du modèle de la tâche {{{idct}}}, il faut ajouter l'implémentation `SyntheticTask()`.
     98   Le coprocesseur matériel étant paramètrable, il faut également définir un nouveau paramètre `EXEC_TIME`
     99   dans la liste des paramètres de la tâche {{{idct}}}. Ce paramètre permet de spécifier le nombre de cycles
     100   utilisés par le coprocesseur matériel pour effectuer la transformation IDCT d'un bloc de 64 pixels.
    91101{{{
    92102idct = TaskModel( 'idct',
    93         infifos = [ 'input' ],
    94         outfifos = [ 'output' ],
    95         impl = [ SwTask( 'idct',
    96                        stack_size = 1024,
    97                        sources = [ 'src/idct.c' ],
    98                        defines = [ 'WIDTH', 'HEIGHT','EXEC_TIME' ] ),
    99                 SyntheticTask() ] )
     103                  infifos = [ 'input' ],
     104                  outfifos = [ 'output' ],
     105                  impl = [ SwTask( 'idct',
     106                                   stack_size = 1024,
     107                                   sources = [ 'src/idct.c' ],
     108                                   defines = [ 'WIDTH', 'HEIGHT','EXEC_TIME' ] ),
     109                           SyntheticTask()
     110                          ] )
    100111}}}
    101112 * La valeur du paramètre  EXEC_TIME doit être définie au moment où on instancie la tâche {{{idct}}} dans le TCG.
    102113{{{
    103 Task( 'idct0' , idct ,
    104         portmap = { 'output':idct_libu,
    105                     'input' :iqzz_idct },
    106         defines = {     'XSIZE':'48', 'YSIZE':'48', 'EXEC_TIME':'64'} )
     114Task( 'idct0', idct,
     115      portmap = { 'output':idct_libu,
     116                  'input' :iqzz_idct },
     117      defines = { 'XSIZE':'48', 'YSIZE':'48', 'EXEC_TIME':'64' }
     118    )
    107119}}}
    108  * Dans la partie déploiement, il faut déployer la tâche {{{idct}}} comme une tâche matérielle (comme on l'a fait pour les tâches {{{ramdac}}} ou {{{tg}}}.
     120 * Dans la partie déploiement, il faut déployer la tâche {{{idct}}} comme une tâche matérielle
     121   (comme on l'a fait pour les tâches {{{ramdac}}} ou {{{tg}}}.
    109122{{{
    110123mapper.map("idct0", vci = mapper.hard.vgmn)
    … …  
    113126Le coprocesseur matériel IDCT (comme beaucoup de coprocesseurs matériels orientés "flot de données'")
    114127exécute une boucle infinie dans laquelle il effectue successivement les actions suivantes:
    115  1. recopie d'un bloc de 64 coefficients du canal MWMR d'entrée vers une mémoire locale BUFIN,
    116  1. calcul d'un bloc de 64 pixels, et stockage de ces pixels dans une seconde mémoire locale BUFOUT,
    117  1. recopie de ces 64 pixels de la mémoire locale BUFOUT vers le canal MWMR de sortie.
     128 1. recopie d'un bloc de 64 coefficients du canal MWMR d'entrée vers une mémoire locale,
     129 1. calcul d'un bloc de 64 pixels, et stockage de ces pixels dans une seconde mémoire locale,
     130 1. recopie de ces 64 pixels de la mémoire locale vers le canal MWMR de sortie.
    118131
    119132Les temps de communication correspondant aux étapes 1 et 3 sont précisément décrits par le simulateur SystemC,
    120 qui reproduit (cycle par cycle) le comportement des interfaces FIFO entre le threader et le contrôleur MWMR
     133qui reproduit (cycle par cycle) le comportement des interfaces FIFO entre le coprocesseur émulé et le contrôleur MWMR
    121134(y compris en cas de contention pour l'accès à la mémoire).
    122135
    123 [[Image(MjpegCourse:q.gif)]] Q2. Combien de coefficients sont transférés par cycle sur  l'interface FIFO d'entrée? Combien  de pixels sont
     136[[Image(MjpegCourse:q.gif)]] Combien de coefficients sont transférés par cycle sur  l'interface FIFO d'entrée? Combien  de pixels sont
    124137transférés par cycle sur l'interface FIFO de sortie? En déduire les durées minimales (en nombre de cycles) pour les étapes 1 et 3 ci-dessus.
    125138
    … …  
    140153deux primitives de communication, et modélise donc le temps de calcul (voir SrlApi).
    141154
    142 [[Image(MjpegCourse:q.gif)]] Q3. pour quelle raison peut-on affirmer sans aucune expérimentation (c'est à dire sans aucune simulation),
     155[[Image(MjpegCourse:q.gif)]] pour quelle raison peut-on affirmer sans aucune expérimentation (c'est à dire sans aucune simulation),
    143156qu'il est sans intérêt de synthétiser un coprocesseur matériel dont le temps de calcul soit inférieur à une centaine de cycles?
    144157
    … …  
    146159''virtuel'' pour la tâche {{{idct}}}.
    147160
    148 [[Image(MjpegCourse:q.gif)]] Q4. Mesurez le nombre de cycle pour décompresser 25 images, en faisant varier la valeur du paramètre ''ncycles'' de la fonction ''srl_busy_cycles()'', dans le code C de la tâche {{{idct}}}. On essaiera les valeurs 8, 64, 512, et 4096 cycles.
     161[[Image(MjpegCourse:q.gif)]] Mesurez le nombre de cycle pour décompresser 25 images,
     162en faisant varier la valeur du paramètre ''EXEC_TIME''. On essaiera les valeurs 8, 64, 512, et 4096.
    149163En déduire un objectif de performance "raisonnable" pour la synthèse du coprocesseur IDCT.
    150164
    … …  
    160174de cette nouvelle plate-forme, pour les 4 valeurs possibles du paramètre.
    161175
    162 [[Image(MjpegCourse:q.gif)]] Q5. Comment expliquez-vous les différences entre les performances
    163 obtenues, suivant qu'on utilise un processeur réel ou virtuel?
     176[[Image(MjpegCourse:q.gif)]] Quelles différences de performance observez-vous suivant
     177qu'on utilise un processeur réel ou virtuel ?
     178
     179[[Image(MjpegCourse:q.gif)]] Quel intérêt a-t-on à utiliser un coprocesseur virtuel ?
    164180
    165181= 4. Compte-Rendu =