eISP : processeur vidéo pour la téléphonie mobile
Mathieu Thevenin
et Laurent Letellier
CEA LIST – Laboratoire Calculs Embarqués
F-91191 Gif sur Yvette – France
Michel Paindavoine
Université de Bourgogne – UMR CNRS 5158
Rue Alain Savary
F-21000 Dijon – France
Email : Michel.Paindavoine@u-bourgogne.fr
AbstractToday’s smart phones, with their embedded high-
resolution video sensors, require computing capacities that are
too high to easily meet stringent silicon area and power consump-
tion requirements (some one and a half square millimeters and
half a watt) especially when programmable components are used.
To develop such capacities, integrators still rely on dedicated
low resolution video processing components, whose drawback is
low flexibility. With this in mind, our paper presents eISP –
a new, fully programmable Embedded Image Signal Processor
architecture, now validated in TSMC 65nm technology to achieve
a capacity of 16.8 GOPs at 233 MHz, for 1.5 mm2of silicon area
and a power consumption of 250 mW. Its resulting efficiency
(67 MOPs/mW), has made eISP the leading programmable
architecture for signal processing, especially for HD 1080p video
processing on embedded devices such as smart phone.
I. INTRODUCTION
Les capteurs vidéo embarqués au sein de dispositifs mobiles
font maintenant partie de notre quotidien et tout spécialement
dans les téléphones portables. Il est nécessaire d’associer
au capteur un processeur de traitement du signal permettant
non seulement la reconstruction des images couleur, mais
aussi d’en améliorer la qualité intrinsèque. Les consommations
électriques consenties dans le domaine de l’embarqué sont de
l’ordre de quelques centaines de milliwatts pour une puissance
de calcul de plusieurs milliards d’opérations par seconde alors
que la surface silicium est de l’ordre du millimètre carré ce
qui permet de limiter les coûts de fabrication. Aujourd’hui les
intégrateurs utilisent des composants dédiés qui manquent de
flexibilité. Par ailleurs la vidéo Haute Définition (HD), qui
n’est, pour l’heure, pas supportée par les téléphones portables
nécessite une capacité de calcul telle (plusieurs dizaines de
GOPs) qu’il est impossible de l’embarquer sur ces dispositifs
mobiles en utilisant les architectures programmables usuelles.
Comme les intégrateurs veulent souvent utiliser leurs propres
fonctions d’amélioration d’image, il est crucial de rendre
flexible et programmable l’ensemble de la structure de calcul
en aval du capteur. Les différentes méthodes de reconstruction
et d’amélioration sont étudiées, ce qui permet de déterminer
les ressources nécessaires à leur exécution. L’architecture
embedded Image Signal Processor (eISP) entièrement pro-
grammable qui est destinée à exécuter des traitements vidéo
HD 1080p – 1920 ×1080 pixels à 25 trames par seconde –
est enfin présentée.
II. CHAÎNE DE RECONSTRUCTION VIDÉO ET CAPACITÉ DE
CALCUL NÉCESSAIRE
Un ensemble de traitements sont nécessaires à l’acquisition
puis à l’amélioration des images issues des capteurs Comple-
mentary Metal Oxide Semiconductor (CMOS). De nombreux
types de traitements et algorithmes peuvent être utilisés dans
la chaîne de reconstruction de l’image. La réduction du bruit
est une étape essentielle. Différents algorithmes de réduction
de bruits sont mis œuvre afin d’améliorer le rapport signal
sur bruit des capteurs utilisant des photosites de plus en
plus petits. Par ailleurs, comme le capteur est recouvert d’un
filtre alternant les couleurs primaires (le filtre de Bayer),
il est nécessaire de reconstruire les plans couleurs à pleine
résolution. C’est le démosaïquage de l’image brute. Enfin,
il est possible d’améliorer la qualité visuelle des images par
le rehaussement des contrastes et des contours ainsi que par
des techniques de "tone mapping". D’autres variantes de la
chaîne d’acquisition d’image sont couramment utilisées, c’est
pourquoi il est crucial de les inventorier.
Une fois que les algorithmes correspondants aux traitements
sont identifiés, il est possible de déterminer la capacité de cal-
cul nécessaire à leur exécution. Pour cela un profil dynamique
de leur exécution est réalisé et qui permet d’obtenir le graphe
d’exécution des traitements. Son analyse permet d’identi-
fier avec précision les opérations réalisées ainsi que leur
enchaînement, mais aussi d’identifier les principaux modes
d’accès aux données de l’image. Ces données permettent de
dimensionner l’architecture. Ainsi il apparaît que pour traiter
un flux vidéo HD 1080p une capacité de calcul de 30 GOPs est
nécessaire. Plus de la moitié de ces opérations sont dédiées à
l’accès aux données (calcul d’adresses, lecture) et au contrôle
(parcours de l’image, compteurs/indices). Or il apparaît que
ces tâches présentent d’importantes similitudes pour l’en-
semble des algorithmes de la chaîne de traitement. Aussi est-il
envisageable de les exploiter au sein de l’architecture afin que
la capacité de calcul programmable soit effectivement dédiée
au traitement.
III. LARCHITECTURE EISP ET SON IMPLÉMENTATION
En considérant un flux HD 1080p devant être traité en
temps réel par un seul processeur fonctionnant par exemple
à 233 MHz, seuls trois cycles d’horloges processeur sont
disponibles pour réaliser les opérations de traitement, ce qui
est insuffisant au regard des dizaines de cycles par pixel
nécessaires pour la réalisation d’une simple convolution. Afin
de maximiser le temps processeur disponible par pixel, il est
crucial d’exploiter toutes les formes de parallélisme. Le paral-
lélisme au niveau des instructions est supporté par l’utilisation
de processeurs Very Long Instruction Word (VLIW) deux
voies, le parallélisme spatial l’est par l’utilisation de plusieurs
processeurs en parallèle et en leur associant à chacun un pixel
différent à traiter. Le parallélisme temporel est exploité en
enchaînant les différents traitements ainsi qu’en réalisant les
opérations de contrôle, d’adressage et d’accès aux données en
temps masqué.
L’architecture eISP est composée de tuiles de calcul pro-
grammable. Comme le présente la Figure 1, ces tuiles in-
tègrent des processeurs VLIW deux voies spécifiquement
conçus pour limiter la surface silicium et la consommation
électrique. Contrairement aux processeurs VLIW traditionnels,
l’ensemble des opérateurs et des registres sont mutualisés
entre les deux voies. Une instance 24 bits d’un tel processeur
présente une complexité de 5200 portes logiques et peut
être associée à une mémoire de travail pouvant atteindre
224 mots de 24 bits. Avec deux instructions par cycle d’horloge
processeur, sa capacité est 466 MOPs à 233 MHz. Ces
processeurs, fonctionnant en mode Single Instruction Multiple
Data (SIMD), sont associés à une mémoire programme. Cette
association constitue la partie calculatoire d’une tuile à la-
quelle est ajouté un gestionnaire de voisinages, dont la fonction
est de transformer le flux de pixels entrant en une structure
directement accessible aux processeurs, tant au niveau du pixel
que du voisinage considéré. Son utilisation permet de masquer
les temps d’accès aux données et de supprimer l’ensemble
des coûts d’accès aux données au niveau du processeur. Ce
gestionnaire de voisinage est conçu pour limiter la consom-
mation et le surface silicium tout en permettant un accès direct
à l’ensemble des données par les processeurs. Une telle tuile
peut intégrer typiquement quatre à seize processeurs.
La tuile comporte aussi un module d’entrées et sortie qui
permet d’extraire les valeurs des pixels du flux à traiter, mais
aussi de reconstruire un flux avec les données calculées par
la tuile. Ce module permet d’associer différentes tuiles entre
elles afin de former l’architecture eISP dans son ensemble.
Les données sont transmises entre les tuiles en flux sur un
bus Time Delay Multiplexed Access (TDMA). Ce bus a
été conçu pour rendre configurable l’ordre dans lequel les
tuiles se transmettent leurs données tout en les maintenant
synchronisées. Une instance en technologie TSMC 65 nm de
l’architecture eISP sur 1,5 mm2de surface silicium développe
16,8 GOPs à 233 MHz avec 6 tuiles de calcul de 2,8 GOPs,
chacune consommant environ 40 mW. L’efficacité de cette
architecture est de 70 MOPs/mW. La surface totale est de
1,5 mm2pour 250 mW. L’organisation de ces algorithmes
sur ces différentes tuiles de calcul peut être organisée comme
présenté en Figure 2.
IV. CONCLUSION
Dans un contexte embarqué dur où les calculs embarqués
au sein de dispositifs mobiles sont essentiellement constitués
Resultsserialization
Input Output
Instructions
Pixel1&neighborhoodaccess
Results
Channel
VLIW
#1
Program
Memory
Program
Counter
Insctruction
Contoller
Linebuffer1
Linebuffer2
Linebuffer3
Neighborhood
Controller
FSM
Neighborhood
registers
Neighborhood
controller
Controlunit
Streamcontroller
Instructions
VLIW
#2
VLIW
#3
VLIW
#4
VLIW
#5
VLIW
#6
Fig. 1. Une tuile de calcul programmable intégrant 6 processeurs.
Normalisationd’histogramme
Tuile1: 23cycles
6PE@233MHz-72%
Réductiondubruit
Correctiongamme
Tuile2: 18cycles
6PE@233MHz-100%
Balancedesblancs
Démosaïquagebilinéaire
Tuile3: 14cycles
6PE@233MHz-77%
Rehaussementdescontours
chaîneverte
Tuile5: 12cycles
6PE@166MHz-79%
Rehaussementdescontours
chaînebleue
Tuile6: 12cycles
6PE@166MHz-79%
Rehaussementdescontours
chaînerouge
Tuile4: 12cycles
6PE@166MHz-79%
Fig. 2. Arrangement des algorithmes sur les différentes tuiles de calcul.
de composants dédiés, nous avons conçu l’architecture de
calcul eISP entièrement programmables. Non seulement, la
consommation électrique et la surface silicium sont maîtrisées
(1,5 mm2, 250 mW), mais la puissance de calcul disponible
(16,8 GOPs effectifs) permet de gérer des flux vidéo haute dé-
finition aux standards 720p ou 1080p, bientôt incontournables
en téléphonie mobile. Les résultats présentés s’appuient sur
une synthèse en technologie TSMC 65 nm pour une fréquence
pouvant aller jusqu’à 400 MHz pour laquelle un layout est
visible en figure 3.
De par sa conception, il est possible d’adapter la capacité
de calcul de l’architecture en fonction des besoins, en aug-
mentant le nombre de processeurs par tuile, leurs fréquences
de fonctionnement ou encore le nombre de tuiles de calcul.
Une telle architecture permet d’intégrer les dernières avancées
algorithmiques. D’autres améliorations sont à l’étude afin
d’élargir l’utilisation d’eISP à d’autres domaines d’applica-
tions de traitement vidéo embarqué.
Programmem.
ControlUnit.1
NeighborhoodRegisters.
VLIW #0
InputOutput
Addresscontroller
Scratchpadmem.#0
Scratchpadmem.#1
Scratchpadmem.#2
Scratchpadmem.#3
Scratchpadmem.#4
Scratchpadmem.#5
LineBuffer#0
LineBuffer#1
LineBuffer#2
VLIW #1
Programmem.
ControlUnit.0
VLIW #2
VLIW #3
VLIW #4
VLIW #5
Fig. 3. Layout après placement routage d’une tuile de calcul.
1 / 2 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !