Changes between Version 12 and Version 13 of MjpegCourse/Coproc

Timestamp:

Mar 5, 2007, 8:32:04 PM (17 years ago)

Author:

alain

Comment:

--

MjpegCourse/Coproc

@@ -34 +34 @@
  * libération du verrou.
 
-Pour simplifier le travail des outils de synthèse, et séparer clairement les fonctions de calcul et les
+Pour simplifier le travail de l'outil de synthèse de coprocesseur, et séparer clairement les fonctions de calcul et les
 fonctions de communication, ce n'est pas le coprocesseur matériel synthétisé qui implémente le 
 protocole MWMR. On utilise pour accéder aux canaux MWMR un composant matériel générique, appelé contrôleur MWMR.
@@ -41 +41 @@
 puisqu'il doit être configuré par le logiciel. C'est ce même
 contrôleur MWMR qui a déjà été utilisé pour interfacer les composants matériels RAMDAC et TG.
-Nous repartirons de la plateforme du [MjpegCourse/Multipro TP3]: !VgmnNoirqMulti, pour une architecture comportant 3 processeurs.
-Nous modifierons cette architecture, pour remplacer
+
+Vous repartirez de la plateforme du [MjpegCourse/Multipro TP3]: !VgmnNoirqMulti, pour une architecture comportant 3 processeurs,
+et vous modifierez cette architecture, pour remplacer
 un des processeurs programmable par un coprocesseur matériel dédié à la transformation IDCT.
 
@@ -63 +64 @@
 d'un coprocesseur matériel spécialisé. Dans le cas d'une transformation IDCT,
 on peut, suivant le nombre d'opérateurs arithmétiques utilisés, effectuer le calcul d'un bloc de 64 pixels 
-en un cycle, en 8 cycles, en 64 cycles, en 512 cycles ou plus. En première approxiation,
-le coût matériel est inversement proportionnel au temps de calcul.
+en u1 cycle, en 8 cycles, ou en 64 cycles,  ou plus. En première approximation,
+le coût matériel  est proportionnel au le nombre d'opérateurs arithmétiques travaillant en parallèle,
+et ce nombre est inversement proportionnel au temps de calcul.
 
 Pour éviter de gaspiller du silicium, il faut donc - avant de se lancer dans la synthèse - évaluer précisément 
@@ -118 +120 @@
 En revanche, le nombre de cycles nécessaires pour exécuter l'étape 2 ci-dessus (temps de calcul "interne" à la tâche logicielle)
 n'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
-en ""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, 
-entre les deux primitives ''srl_mwmr_read()'' et '''srl_mwmr_write()'',
-un appel à la  la fonction bloquante srl_busy_cycles( ncycles ). L'argument ''ncycles'' est le nombre de cycles d'attente entre les
+en "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, 
+entre les deux primitives ''srl_mwmr_read()'' et ''srl_mwmr_write()'',
+un appel à la  la fonction bloquante ''srl_busy_cycles(ncycles)''. L'argument ''ncycles'' est le nombre de cycles d'attente entre les
 deux primitives de communication, et il modélise donc le temps de calcul (voir SrlApi).
 {{{
-...
 srl_mwmr_read();
 ...
@@ -129 +130 @@
 ...
 srl_mwmr_write();
-...
 }}}
 
 [[Image(MjpegCourse:q.gif)]] Q3. pour quelle raison peut-on affirmer sans aucune expérimentation (c'est à dire sans aucune simulation),
-qu'il est sans intérêt de synthétiser un coprocesseur matériel dont le temps de calcul pour traiter un bloc de
-64 pixels soit inférieur à 64 cycles?
+qu'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?
 
 Modifier la description DSX pour déployer l'application MJPEG sur une architecture comportant 2 processeurs MIPS et un coprocesseur