Changes between Version 11 and Version 12 of MjpegCourse/Coproc


Ignore:
Timestamp:
Mar 5, 2007, 8:16:12 PM (17 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MjpegCourse/Coproc

    v11 v12  
    4141puisqu'il doit être configuré par le logiciel. C'est ce même
    4242contrôleur MWMR qui a déjà été utilisé pour interfacer les composants matériels RAMDAC et TG.
    43 Nous repartirons de la plateforme du [MjpegCourse/Multipro TP3]: !VgmnNoirqMulti.
    44 Nous modifierons cette plateforme comportant trois processeurs Mips, pour remplacer
     43Nous repartirons de la plateforme du [MjpegCourse/Multipro TP3]: !VgmnNoirqMulti, pour une architecture comportant 3 processeurs.
     44Nous modifierons cette architecture, pour remplacer
    4545un des processeurs programmable par un coprocesseur matériel dédié à la transformation IDCT.
    4646
    47 == Mettre ici le dessin de la plate-forme matérielle complête avec 2 processeurs et 3 controleurs MWMR ==
     47== Mettre ici le dessin de la plate-forme matérielle complête avec 2 processeur et 3 controleurs MWMR ==
    4848
    4949Reprenez les fichiers du TP3:
    … …  
    5353
    5454[[Image(MjpegCourse:q.gif)]] Q1.  Rappelez le temps
    55 nécessaire pour décoder 25 images, dans le cas d'une implantation
    56 utilisant trois processeurs, lorsque la tâche {{{idct}}} est placée sur un processeur,
    57 que la tâche {{{vld}}} est placée sur un second processeur, et que toutes les autres
    58 tâches logicielles se partagent le troisième processeur.
     55nécessaire pour décoder 25 images, dans le cas d'un déploiement
     56utilisant 2 processeurs, lorsque la tâche {{{idct}}} est placée sur le premier processeur,
     57que la tâche {{{vld}}} est placée sur le second processeur,
     58et que toutes les autres tâches logicielles se partagent le troisième processeur.
    5959
    6060= 1. Coprocesseur virtuel =
    … …  
    8080En pratique, la simulation dans ce mode consiste à exécuter un programme parallèle comportant
    8181deux processus UNIX communicant entre eux par des ''pipes'' UNIX.
    82  * Le premier processus est le simulateur SystemC modélisant l'architecture matérielle (y compris le ''contrôleur MWMR'' et le composant ''threader'').
    83  * Le second processus est la tâche logicielle {{{idct}}} encapsulée dans le composant ''threader''.
     82Le premier processus est le simulateur SystemC modélisant l'architecture matérielle
     83(y compris le contrôleur MWMR et le composant ''threader''). Le second processus est la tâche logicielle encapsulée.
    8484
    85 Pour utiliser ce mode d'émulation, il faut modifier deux choses dans la description DSX:
     85== mettre ici le dessin contenant le threader ==
     86
     87Pour utiliser un tel coprocesseur ''virtuel'', il faut modifier deux choses dans la description DSX:
    8688 * dans la définition du modèle de la tâche {{{idct}}}, il faut ajouter l'implémentation `SyntheticTask()`
    8789{{{
    … …  
    9496                                                 sources = [ 'src/idct.c' ],
    9597                                                 defines = [ 'WIDTH', 'HEIGHT' ] ),
    96                                  Synthetic()
    97                                  ] )
     98                              SyntheticTask()   ] )
    9899}}}
    99100 * 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}}}.
    … …  
    102103}}}
    103104
    104 Le coprocesseur matériel IDCT (comme beaucoup de coprocesseurs matériels de type ''flot de données'')
     105Après synthèse, le coprocesseur matériel IDCT (comme beaucoup de coprocesseurs matériels de type ''flot de données'')
    105106exécute une boucle infinie dans laquelle il effectue successivement les actions suivantes:
    106107 1. recopie d'un bloc de 64 coefficients du canal MWMR d'entrée vers une mémoire locale BUFIN,
    … …  
    108109 1. recopie de ces 64 pixels de la mémoire locale BUFOUT vers le canal MWMR de sortie.
    109110
    110 Compte-tenu des caractéristiques
    111 Pour modéliser le temps de traitement la tâche matérielle virtuelle plus exacte en temps de simulation, on peut ajouter des directives
    112 dans le code source C des tâches pour préciser le temps qu'il faudrait pour réaliser la même action en matériel:
    113 `srl_busy_cycles` (voir SrlApi).
     111[[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
     112transfé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.
    114113
    115 Il n'existe aucune référence au temps de calcul dans le code C de la tâche {{{idct}}} logicielle.
    116 En lisant le code de l'implémentation matérielle du coprocesseur `Idct`, déduisez les temps
    117 nécessaires aux différentes parties du traitement.
    118 our introduire un coprocesseur matériel,
    119 il faut commencer par modifier le modèle de la tâche {{{idct}}},
    120 en définissant une implémentation matériellel:
     114Les temps de communication correspondant aux étapes 1 et 3 sont précisément décrits par le simulateur SystemC,
     115qui reproduit (cycle par cycle) le comportement des interfaces FIFO entre le threader et le contrôleur MWMR
     116(y compris en cas de contention pour l'accès à la mémoire).
    121117
    122 [[Image(MjpegCourse:q.gif)]] En utilisant un coprocesseur virtuel, pour la tâche {{{idct}}},
    123 détermidez quel est le gain en performances apporté par le coprocesseur, pour
    124 différents temps de traitement (1 cycle, 8 cycles, 64 cycles, 512 cycles ou 2048 cycles
    125 pour traiter un bloc de 64 pixels).quel est le temps
    126 nécessaire pour décoder 25 images ?
     118En revanche, le nombre de cycles nécessaires pour exécuter l'étape 2 ci-dessus (temps de calcul "interne" à la tâche logicielle)
     119n'est pas défini par le code de la tâche logicielle. Si on ne précise rien, cela correspond à un temps d'exécution du calcul
     120en ""zéro" cycles. Pour préciser un nombre de cycles d'exécution, il faut modifier le code C de la tâche {{{idct}}}, et insérer,
     121entre les deux primitives ''srl_mwmr_read()'' et '''srl_mwmr_write()'',
     122un appel à la  la fonction bloquante srl_busy_cycles( ncycles ). L'argument ''ncycles'' est le nombre de cycles d'attente entre les
     123deux primitives de communication, et il modélise donc le temps de calcul (voir SrlApi).
     124{{{
     125...
     126srl_mwmr_read();
     127...
     128srl_busy_cycles( n );
     129...
     130srl_mwmr_write();
     131...
     132}}}
     133
     134[[Image(MjpegCourse:q.gif)]] Q3. pour quelle raison peut-on affirmer sans aucune expérimentation (c'est à dire sans aucune simulation),
     135qu'il est sans intérêt de synthétiser un coprocesseur matériel dont le temps de calcul pour traiter un bloc de
     13664 pixels soit inférieur à 64 cycles?
     137
     138Modifier la description DSX pour déployer l'application MJPEG sur une architecture comportant 2 processeurs MIPS et un coprocesseur
     139''virtuel'' pour la tâche {{{idct}}}.
     140
     141[[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.
     142En déduire un objectif de performance "raisonnable" pour la synthèse du coprocesseur IDCT.
    127143
    128144= 3. Coprocesseur matériel =
    129145
    130 Remplacez la déclaration `Synthetic()` par une déclaration de coprocesseur matériel virtuel `HwTask( IdctCoproc )`.
     146On va maintenant utiliser un "vrai" coprocesseur matériel IDCT, disponible dans la bibliothèque SoCLib.
     147Ce coprocesseur matériel est générique, en ce sens qu'on peut paramètrer le nombre de cycles
     148pour effectuer la transformation d'un bloc de 64 pixels. Les valeurs possibles de ce paramètre
     149sont 8, 64, 512, et 4096 cycles.
    131150
    132 [[Image(MjpegCourse:q.gif)]] Quel est maintenant le temps de simulation nécessaire pour 25 images ?
     151Remplacez dans le modèle DSX de la tâche {{{idct}}, la déclaration `SyntheticTask()` par
     152une déclaration de coprocesseur matériel `HwTask( IdctCoproc )`, et relancez la simulation
     153de cette nouvelle plate-forme, pour les 4 valeurs possibles du paramètre.
    133154
    134 [[Image(MjpegCourse:q.gif)]] Qu'en déduisez-vous sur la différence entre les deux possibilités pour tester
    135 une implémentation matérielle ?
    136 
    137 [[Image(MjpegCourse:q.gif)]] Quel intérêt y a-t-il à pouvoir caractériser précisément le temps de traitement
    138 d'une tâche matérielle à partir d'un code en C ?
     155[[Image(MjpegCourse:q.gif)]] Q5. Comment expliquez-vous les différences entre les performances
     156obtenues, suivant qu'on utilise un processeur réel ou virtuel?
    139157
    140158= 4. Compte-Rendu =