| 35 | | Pour simplifier le travail des outils de synthèse, on utilise pour cela un composant |
| 36 | | matériel générique, appelé contrôleur MWMR qui est un initiateur VCI, capable |
| 37 | | de lire ou d'écrire en mémoire, dans des FIFO MWMR, et qui fournit au coprocesseur |
| 38 | | autant de canaux de communications que celui-ci en a besoin. C'est ce même |
| 39 | | composant matériel qui est utilisé par les composants RAMDAC et TG. |
| | 36 | Pour simplifier le travail des outils de synthèse, 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. |
| | 43 | Nous repartirons de la plateforme du [MjpegCourse/Multipro TP3]: !VgmnNoirqMulti. |
| | 44 | Nous modifierons cette plateforme comportant trois processeurs Mips, pour remplacer |
| | 45 | un des processeurs programmable par un coprocesseur matériel dédié à la transformation IDCT. |
| 51 | | nécessaire pour décoder 25 images, dans le cas d'une implantation logicielle |
| 52 | | utilisant deux processeurs. |
| | 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. |
| 56 | | Pour introduire un coprocesseur matériel, |
| 57 | | il faut commencer par modifier le modèle de la tâche {{{idct}}}, |
| 58 | | en définissant une implémentation matériellel: |
| | 62 | Il existe plusieurs solutions micro-architecturales pour la réalisation |
| | 63 | d'un coprocesseur matériel spécialisé. Dans le cas d'une transformation IDCT, |
| | 64 | on peut, suivant le nombre d'opérateurs arithmétiques utilisés, effectuer le calcul d'un bloc de 64 pixels |
| | 65 | en un cycle, en 8 cycles, en 64 cycles, en 512 cycles ou plus. En première approxiation, |
| | 66 | le coût matériel est inversement proportionnel au temps de calcul. |
| | 67 | |
| | 68 | Pour éviter de gaspiller du silicium, il faut donc - avant de se lancer dans la synthèse - évaluer précisément |
| | 69 | la puissance de calcul requise pour le coprocesseur, une fois celui-ci placé |
| | 70 | dans son environnement de travail. Il faut donc faire de l'exploration |
| | 71 | architecturale ''avant synthèse''. |
| | 72 | |
| | 73 | Pour cela, on commence par ''émuler'' le coprocesseur matériel - sans le synthétiser - |
| | 74 | en encapsulant la tâche logicielle {{{idct}}} existante dans un composant matériel générique |
| | 75 | appelé ''threader'', qui est un service fourni par l'environnement DSX. |
| | 76 | Pour ce qui concerne le matériel, ce composant ''threader'' s'interface avec le composant matériel |
| | 77 | ''contrôleur MWMR'', mais il est également capable de communiquer avec la tâche logicielle {{{idct}}}, |
| | 78 | de façon a utiliser ce code pour effectuer les calculs qui devront être réalisés par le |
| | 79 | coprocesseur matériel. |
| | 80 | En pratique, la simulation dans ce mode consiste à exécuter un programme parallèle comportant |
| | 81 | deux 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''. |
| | 84 | |
| | 85 | Pour utiliser ce mode d'émulation, il faut modifier deux choses dans la description DSX: |
| | 86 | * dans la définition du modèle de la tâche {{{idct}}}, il faut ajouter l'implémentation `SyntheticTask()` |
| 71 | | |
| 72 | | = 2. Coprocesseur virtuel = |
| 73 | | |
| 74 | | Il existe plusieurs solutions micro-architecturales pour la réalisation |
| 75 | | d'un coprocesseur matériel spécialisé. Dans le cas d'une transformation IDCT, |
| 76 | | on peut, suivant le nombre d'opérateurs arithmétiques utilisés, effectuer le calcul d'un bloc de 64 pixels |
| 77 | | en un cycle, en 8 cycles, en 64 cycles ou en 256 cycles. Le coût matériel est inversement |
| 78 | | proportionnel au temps de calcul. |
| 79 | | |
| 80 | | Avant de se lancer dans la synthèse, il faut donc évaluer précisément |
| 81 | | la puissance de calcul requise pour le coprocesseur, une fois celui-ci placé |
| 82 | | dans son environnement de travail. On commence donc par ''encapsuler'' |
| 83 | | la tâche matérielle `idct` dans un composant matériel générique appelé ''threader''. |
| 84 | | Ce composant s'interface d'un côté avec le contrôleur MWMR, et de l'autre avec |
| 85 | | la tâche logicielle. |
| 86 | | |
| 87 | | L'implémentation `Synthetic()` sert à déclarer cette implémentation et doit |
| 88 | | être accompagnée d'une déclaration de tâche logicielle (`SwTask`). |
| 89 | | Elle permet la synthèse virtuelle de la tâche. On peut alors déployer la tâche comme si |
| 90 | | elle était matérielle, son comportement est simulé. |
| | 99 | * 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}}}. |
| | 100 | {{{ |
| | 101 | mapper.map("idct", vci = mapper.hard.vgmn) |
| | 102 | }}} |
| 93 | | exécute une boucle infinie dans laquelle if effectue successivement les actions suivantes: |
| 94 | | * recopie d'un bloc de 64 coefficients du canal MWMR d'entrée vers une mémoire locale BUFIN, |
| 95 | | * calcul d'un bloc de 64 pixels, et stockage de ces pixels dans une seconde mémoire locale BUFOUT, |
| 96 | | * recopie de ces 64 pixels de la mémoire locale BUFOUT vers le canal MWMR de sortie. |
| | 105 | exécute une boucle infinie dans laquelle il effectue successivement les actions suivantes: |
| | 106 | 1. recopie d'un bloc de 64 coefficients du canal MWMR d'entrée vers une mémoire locale BUFIN, |
| | 107 | 1. calcul d'un bloc de 64 pixels, et stockage de ces pixels dans une seconde mémoire locale BUFOUT, |
| | 108 | 1. recopie de ces 64 pixels de la mémoire locale BUFOUT vers le canal MWMR de sortie. |
