Ajout de coprocesseurs

Des accélérateurs plus complexes peuvent nécessiter plusieurs cycles pour l’exécution d’un traitement ou ne pas être prévus pour s’intégrer au jeu d’opérateurs, par exemple en raison d’une alimentation particulière en données, issues du gestionnaire de voisinages.

Leur intégration est donc réalisée entre chaque processeur SplitWay et le gestionnaire de voisinages, comme le schématise la Figure 4.18c. D’une part le processeur SplitWay communique avec son ou ses coproces- seur(s) par l’intermédiaire de l’espace d’adressage de son plan mémoire, d’autre part, le coprocesseur peut être connecté, si nécessaire au gestionnaire de voisinages pour accéder directement aux valeurs des pixels à manipuler, ou encore à d’autres éléments de l’architecture.

4.7. Intégration d’extensions à l’architecture 109 Gestionnaire de voisinages ProcesseurSplitWay N°1 ProcesseurSplitWay N° NbProcs Sérialisation Unitédecontrôle Moduledecommunication Tuile de calcul UF1 UF0 UF3 UF2 UFZi UFAi UFZo UFAo

(a) Unités fonctionnelles dans le flux de don- nées. Filederegistres STO Résultats EXECUTE

FU

(b) Unités fonctionnelles en tant qu’opérateur. COPROCESSEUR Voisinages SplitWay (c) Coprocesseur connecté à SplitWay.

FIG. 4.18:EXEMPLE D’INTÉGRATIONS DE COMPOSANTS DÉDIÉS AU SEIN DES TUILES DE CALCUL,(a) UFS IN-

TÉGRÉES AU FLUX DE DONNÉES,(b) UNITÉ FONCTIONNELLE ACCESSIBLE EN TANT QU’OPÉRATEUR AU SEIN DE

L’UNITÉEXECUTE DU PROCESSEUR,(c) COPROCESSEUR ALIMENTÉ EN DONNÉES PAR LE GESTIONNAIRE DE VOI-

SINAGES ET/OU PAR LE PROCESSEUR VIA L’ESPACE D’ADRESSAGE DU PLAN MÉMOIRE.

Il apparaît que l’utilisation de coprocesseurs induit une forte augmentation de la surface silicium pour des fonctions qui sont dediées. Notons qu’il peut là encore s’agir d’une unité reconfigurable.

Conclusion sur l’intégration de ressources dédiées à l’architecture

Cette section a permis de voir les différents niveaux d’extensions que l’architecture eISP peut supporter. Des composants dédiés peuvent s’ajouter ou remplacer certaines tuiles de calcul, ce qui permet aux intégrateurs d’utiliser directement leurs PIs en leur adjoignant le module de communication. Des opérations peuvent être introduites directement dans le flux de pixels au niveau de chaque tuile de calcul, ce qui permet de décharger les processeurs des opérations régulières au niveau pixel, comme la correction gamma ou des corrections de gain. Ces deux premiers modes d’extension n’ont pas d’impact sur la programmabilité des différentes tuiles de calcul.

Le niveau supplémentaire consiste à étendre le jeu d’instructions en ajoutant des opérateurs aux proces- seurs, ces opérateurs bénéficient alors de l’accès complet aux ressources du processeur. Enfin des coproces- seurs peuvent être ajoutés aux processeurs qui leur sont accessibles par le plan mémoire. Leur alimentation en données peut être réalisée par connexion directe avec le gestionnaire de voisinages.

Si l’utilisation d’extensions dédiées permet d’augmenter drastiquement la capacité de calcul de l’architecture, elle induit aussi l’augmentation de sa surface silicium et de sa consommation électrique. Cette augmentation peut être acceptable si elle n’implique pas une trop grande spécialisation de certaines tuiles de calcul pour des classes de traitement données. Aussi est-il essentiel de déterminer avec précision le choix de chaque accélérateur à utiliser pour ne pas s’éloigner de la flexibilité initiale de l’architecture.

Conclusion

Ce chapitre a détaillé la conception de l’architecture eISP dans son ensemble, ainsi que des différents éléments qui la compose. Cette architecture de calcul programmable permet le traitement de flux de données en temps réel, et peut être dimensionnée à la conception du circuit en fonction des besoins de l’utilisateur. Elle est construite autour d’un ensemble de tuiles de calcul, schématisé en Figure4.19, qui sont interconnectées entre elles par un busTDMAspécialement conçu.

Gestionnaire devoisinages Processeur SplitWay N° 1 Processeur SplitWay N° 2 Processeur SplitWay N° NbProcs Sérialisation Unité de contrôle Module de communication Gestionnaire devoisinages Processeur SplitWay N° 1 Processeur SplitWay N° 2 Processeur SplitWay N° NbProcs Sérialisation Unité de contrôle Module de communication Bus TD_MA

FIG. 4.19: REPRÉSENTATION DE L’ARCHITECTURE DANS SON ENSEMBLE, PLUSIEURS TUILES DE CALCUL QUI

PEUVENT ÊTRE HÉTÉROGÈNES SONT INTERCONNECTÉES ENTRE-ELLES.

Afin de maximiser le nombre d’opérations par pixel pouvant être exécutées, différents mécanismes sont mis en œuvre. Comme la surface silicium et la consommation électrique sont deux éléments essentiels de la concep- tion de l’architecture eISP, différentes techniques ont été mises en œuvre pour réduire la surface silicium et la consommation électrique de l’architecture et de chaque composant qui la constitue. Les différentes formes de parallélisme extraites lors de l’analyse algorithmique sont traduites d’un point de vue architectural. Les diffé- rents éléments de l’architecture sont conçus pour limiter d’abord la surface silicium, ensuite la consommation, tout en assurant les performances attendues.

Le parallélisme de tâche est exploité en enchaînant les tuiles de calcul, qui exécutent chacune des traite- ments différents. Il est aussi exploité en séparant les tâches d’accès aux données, de contrôle et de calcul, mais aussi d’autres opérations comme l’extraction des métadonnées, ou l’utilisation d’éventuels accélérateurs dé- diés. Ces derniers peuvent être intégrés à différents niveaux de la tuile de calcul. Ainsi, le programmeur décrit uniquement les cœurs de boucles correspondant aux équations des filtres qu’il doit porter, sans se soucier de la

4.7. Intégration d’extensions à l’architecture 111

manipulation des données. La parallélisme spatial inhérent au traitement d’image est exploité en traitant plu- sieurs pixels simultanément. Enfin le parallélisme au niveau instruction l’est grâce à l’utilisation de processeurs

VLIWdeux voies.

L’accès aux données, qui représente la part la plus importante des ressources de calcul requises, est géré à plusieurs niveaux, les processeurs de calcul sont déchargés de ces ressources. D’abord, une hiérarchie mémoire prépare en temps masqué l’ensemble des données à manipuler au sein de la tuile. Il s’agit du gestionnaire de voisinages, qui, comme son nom l’indique, organise les données de l’image sous forme de voisinages. Ceux- ci sont directement accessibles par le processeur, et/ou d’éventuelles PIs dédiées. Ensuite, Le processeur de calcul possède un jeu d’instructions orthogonal qui lui permet d’utiliser n’importe quelle source de données en tant qu’opérande. Enfin, l’utilisation de données composites au niveau de la tuile de calcul dont le format est paramétrable n’induit pas de surcoût algorithmique.

Les ressources programmables de la tuile de calcul reposent sur les processeurs SplitWay regroupés pour fonctionner en mode Multi-SIMD. Ce mode de fonctionnement permet de réduire le nombre d’instructions nécessaires au traitement des images brutes, mais aussi des programmes pour lesquels des prédicats de type

IF/ELSE/CASE sont utilisés et que le modeSIMDn’exécute pas de manière optimale. Toutes les instructions qui sont implémentées traitent des données entières signées et sont exécutées en un seul cycle processeur. Le jeu d’opérations, qui peut être étendu, n’est pas spécifique au traitement d’image, permettant ainsi l’utilisation du processeur SplitWay pour tout type de traitement en mode flux de données.

L’unité de contrôle couplée avec le gestionnaire de voisinages assure le fonctionnement des processeurs en modeMulti-SIMD. En modeSIMD, les mêmes instructions du programme sont transmises à l’ensemble des processeurs dès qu’un événement comme l’arrivée de pixels à traiter le commande, tandis qu’en modeMulti- SIMDdifférents segments de code sont transmis à différents processeurs. Cette fonctionnalité permet d’adapter efficacement le programme aux données, et notamment au traitement d’images brutes constituées d’alternances de pixels de type différents.

Enfin, une unité de communication est intégrée aux tuiles de calcul pour leur permettre de communiquer entre elles sur le bus TDMAou avec d’autres composants comme un capteur ou un processeur. Les valeurs des pixels sont donc extraites du flux et transmises au gestionnaire de voisinages, tandis que les résultats des processeurs permettent de régénérer un flux de pixels pour l’envoyer à d’autres tuiles de calcul. Pour plus de flexibilité, l’enchaînement des tuiles de calcul est configurable, et par conséquent celui des traitements qui sont programmés dessus. L’unité de communication sépare en outre les domaines d’horloges des tuiles et du bus puisque chaque tuile fonctionne à une fréquence adaptée au traitement qu’elle doit réaliser.

113

C

HAPITRE

5

Génération et validation de l’architecture

Où sont caractérisées les surfaces silicium et les consommations électriques de l’architecture eISP. Où est montré comment déterminer le nombre de tuiles de calcul et de processeurs de l’architecture en respectant les contraintes initialement fixées.

Où est expliqué comment une chaîne de traitement d’image est portée sur l’architecture eISP. Où l’architecture eISP est comparée à l’état de l’art.

Introduction

L

E CHAPITRE 3 a permis de déterminer les ressources de calcul nécessaires à l’exécution de la chaîne d’amélioration d’image en aval du capteur. Le chapitre 4 a détaillé la conception de l’architecture eISP composant par composant, et notamment celle du processeur SplitWay qui est utilisé en modeMulti-SIMDau sein de tuiles de calcul programmables. La description comportementale de cette architecture et de ses compo- sants en langage SystemC a permis d’en valider le fonctionnement. L’architecture a ensuite fait l’objet d’une description VHDLsynthétisable afin d’obtenir des tuiles de calcul programmables dont le fonctionnement en technologie ASIC TSMC 65 nm a été validé après synthèse. Leur nombre, ainsi que leur contenu (nombre de processeurs, éléments de mémorisation, taille maximale des voisinages etc.) doivent être déterminés lors la création du circuit en fonction des contraintes d’intégration. Si ces choix impactent la capacité de calcul et la flexibilité du système, ils impactent aussi la surface silicium et la consommation électrique. En effet, à surface silicium équivalente, plus la surface dédiée aux éléments de mémorisation est importante et plus celle dédiée aux ressources de calcul sera réduite. Il est aussi possible d’augmenter la flexibilité de l’architecture en intervenant par exemple sur la diversité des opérateurs ou sur le volume de ressources de mémorisation.

La Section5.1réalise une estimation des surfaces et des consommations électriques que différentes instances de l’architecture eISP peuvent prendre. Pour cela il est d’abord nécessaire d’identifier les différents paramètres permettant d’intervenir sur la flexibilité, la capacité de calcul, la surface silicium et la consommation électrique de l’architecture. Un générateur automatique de l’architecture est mis en place pour différentes valeurs de ces paramètres, ce qui permet l’exploration de plusieurs configurations possibles (taille des chemins de données, taille des éléments mémoire, nombre de registres, etc.). A partir des configurations sélectionnées, les surfaces et les consommations électriques sont estimées par synthèse et simulation de différentes instances de l’archi- tecture.

La Section5.2 présente une évaluation des performances de l’architecture eISP en fonction des différentes configurations. Une approche est proposée pour prendre en compte les ressources des fonctionnalités de chaque composant de la tuile de calcul. Enfin, la capacité de calcul effectivement disponible pour le programmeur est présentée en fonction des surfaces silicium et des consommations obtenues.

Après avoir expliqué par l’exemple comment un programme peut être porté sur une tuile de calcul, la section

5.3 présente Vid’eISP.1, une instance de l’architecture eISP suffisamment flexible et capable de supporter les chaînes d’amélioration vidéo qui ont été présentées dans le chapitre1. Cette instance est conçue à partir d’une démarche Adéquation Algorithme-Architecture, qui tient compte des résultats obtenus en 5.2 ainsi que des

spécificités des algorithmes. Le portage de la chaîne complète de traitement sur Vid’eISP.1 est ensuite présenté. Pour démontrer la flexibilité du modèle architecturale eISP, deux instances supplémentaires sont présentées dont la surface est de l’ordre du millimètre carré. La première est destinée à privilégier la capacité de calcul, l’autre la flexibilité de programmation.

Enfin, avant de conclure, la dernière Section 5.4présente une comparaison de l’architecture eISP avec les différentes solutions proposées pour le traitement du signal introduites dans le chapitre2.

5.1

Estimation des surfaces et de la consommation

Nous avons vu que l’architecture eISP est constituée de tuiles de calcul programmables. Ces tuiles de calcul, interconnectées entre elles par un busTDMA, permettent de traiter des flux de données, typiquement des vidéos. Chaque tuile, grâce aux processeurs SplitWay qu’elles intègrent, est programmable et présente une capacité de calcul qui dépend du nombre de processeurs et de leur fréquence de fonctionnement. D’une manière générale, la surface et la consommation de l’architecture dépend donc du nombre de tuiles utilisées dans l’architecture ainsi que des éléments qui les constituent. Les paramètres de ces composants ont un impact sur la flexibilité globale de l’architecture. Fixons par exemple le chemin de données des processeurs à 8 bits, la dynamique des calculs possibles sera moindre que s’il est fixé à 16 ou 24 bits rendant ainsi difficile le portage de certains traitements. Par contre, la surface silicium des processeurs étant inférieure, un plus grand nombre d’entre eux pourra être intégré au sein des tuiles de calcul. La capacité de calcul globale s’en trouve ainsi augmentée. Il est même possible, dans certains cas, que ce surcroît de ressources programmables pallie au manque de flexibilité globale de la structure.

Dans le document Conception et validation d'un processeur programmable de traitement du signal à faible consommation et à faible empreinte silicium : application à la vidéo HD sur téléphone mobile (Page 123-129)