Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Février 20141 Logique programmable avancée Projet PTIPO ( P ré T raitement

Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Février 2014 1

Logique programmableavancée

Projet PTIPO

(Pré Traitement d’Image de POteau)

Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Février 2014 2

Avertissement

Cette présentation ainsi que les fichiers mentionnés se trouvent sur le campus numérique, espace S8 EE – Logique programmable avancée :

http://campus.eseo.fr/course/view.php?id=424

http://campus.eseo.fr/course/view.php?id=424

Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009 3

Thème : traitement d’image temps réel

L’information de luminance

Une image couleur

Le flot de pixels délivré par un capteur d’image va être traité à traversune cascade d’unités fonctionnelles visant à fournir successivement :

Une image binarisée selon un seuillage adaptatif par moyennage local de la luminance

Le gradient horizontal de l’image binarisée

Un moniteur VGA permettra de contrôler la conformité du traitementen chaque point de la chaîne.


Objectif du traitement

Effectuer un prétraitement de l’image de manière à y faire apparaître les contours verticaux.

Ce prétraitement permet par exemple la détection automatique et identification d’objets portant un motif adapté (ex. : code à barres)


Exemple d’objet à détecter : piquet codé

Anneaux périodiques alternativementnoirs et blancs (4 anneaux noirsau minimum)

Anneau rouge

Code barre d’identification sur 4 bits(ici 1001, soit poteau n° 9).La périodicité des bits du code barreest la même que celle des anneaux quile précèdent.


Détection d’un piquet codé

X

Y

Sens de scrutation

Lorsque l’analyseur détecte sur une ligne de l’image des transitions périodiquesen nombre suffisant avec une plage rouge, on présumera de la présence d’unpiquet codé, dont le code à 4 bits peut être lu après mesure de la périodespatiale des transitions lors de la détection.


Valeur ajoutée :

Configuration d’un capteur d’image par bus I2C

Configuration d’une PLL pour synthèse de fréquence

Utilisation de blocs de RAM embarquée

Exploitation d’une matrice de Bayer

Résolution de contraintes de timing

… et du traitement d’image temps réel avec un FPGA


Structure générale du système


Architecture globale du système

CAMERAInterface

Désérialiseur+

visualisation

CarteSPARTAN3

Ecran de contrôle

Liaison sérieLVDS

Bus I2C

2

2

Capteurswitches de configuration


Montage du système

Ecran VGA de contrôle

Camérasérie


La caméra

Capteur CMOS Support de lentille pourobjectif à monture C

Câble RJ45(à ne pas connecter au réseau Ethernet !)


La caméra, caractéristiques

Taille des pixels : 6 µm x 6 µm

Format Wide VGA à pleine résolution : 480 (V) x 752 (H)

La caméra est équipée d’un capteur couleur CMOS MT9V032L12STC conçu par Micron, dont les principales caractéristiques sont :

Sortie parallèle 12 bits

Sérialiseur intégré : sortie LVDS série 10 bits

Seule la sortie série est utilisée. La caméra est cadencée à 27 MHz, ce quipermet un débit de l’ordre de 60 trames par seconde à pleine résolution.Elle est alimentée en 3.3 V.

Configurable par bus I2C

Matrice de filtres colorés de Bayer


La caméra, composant I2C esclave

Le débit du bus I2C peut atteindre 400 kbits/s.

La caméra est matériellement configurée pour être reconnue sur le bus I2C avec l’adresse esclave

"1011100"


Le système SERDES (SERializer-DESerializer)

Convenablement configuré (via son bus I2C), le capteur produit un flot de pixels codés sur 8 bits (+ 2 bits pour la synchro) et transmis par son sérialiseur intégré. A 27 MHz, cela correspondra à un débit de 270 Mbits/s.

Electriquement, la transmission se fait en mode LVDS (Low VoltageDifferential Signaling) permettant une longueur maximum de câble de 8 mètres.

Un circuit désérialiseur reçoit le flux série. Piloté par un oscillateur local27 MHz (asynchrone de celui de la caméra), le circuit fournit les pixels désérialisés sous forme de mots de 8 bits ainsi que les bits de synchronisation Line Valid (LV) et Frame Valid (FV).


Le désérialiseur

SN65LV1212

Désérialiseur

LVDS_POS

LVDS_NEG

DATA [7:0]

FV

LV

8

RCLK

LOCK_N

REFCLK

RF_N

Liaisons avec la caméra

Liaisons avec la carte Spartan 3

Configuration locale (0 ou 1)


La PLL du désérialiseur

DésérialiseurRCLK

LOCK_N

REFCLK

Le circuit possède en interne une PLL qui va se verrouiller sur l’horlogede transmission TCLK incluse dans les signaux LVDS. Elle a besoin pourcela d’une horloge locale de référence REFCLK à peu près de même fréquence (+/- 5%) que celle de l’oscillateur local de la caméra.

Le verrouillage de la PLL est signalé par la sortie LOCK_N à l’état bas.

Lorsque la PLL est verrouillée, le circuit délivre l’horloge restaurée RCLK,synchrone de celle de la caméra et donc des pixels délivrés.


Désérialiseur : les horloges

Désérialiseur RCLKREFCLK

Comme la caméra est cadencée à 27 MHz, la carte Spartan 3 devraproduire une horloge locale REFCLK à peu près de même fréquence,donc de 27 MHz (+/- 5%).

L’horloge restaurée RCLK (asynchrone de REFCLK) servira à cadencertout le domaine synchrone propre au traitement des pixels.

L’entrée RF_N permet de choisir le front de RCLK (rising or falling) quiservira à échantillonner les pixels.

RF_N

Groupe ESEO – D.Genet – R. Perdriau – G. Savaton - Logique programmable avancée – Avril 2009 18

Le signal RF_N (strap R/F)

Le signal RF_N, ajustable manuellement à 0 ou 1, permet de choisir la phase de l’horloge RCLK par rapport au flux DATA délivré par le deserializer.

DATA

RCLK(RF_N=0)

RCLK(RF_N=1)

strap

Par défaut, on utilisera le mode RF_N = 1. Cependant, en cas de dysfonctionnement,on pourra toujours tester le mode RF_N=0.


Les signaux de synchronisation FV et LV

Par défaut, FV (Frame Valid) et LF (Line Valid) auront les formes suivantes :

LVDS_POS

LVDS_NEG

DATA [7:0]

FV

LV

8

Désérialiseur

Lign

e 0

Lign

e 1

Lign

e 2

Lign

e 47

8

Lign

e 47

9

FV

LV

Blanking ligne

Blanking trame

16,66 ms (60Hz)

32 µs


Architecture du système de traitement : vue externe

QUARTZ

RAZ

REFCLK

SDA

SCLK

CAM_RESET_N

LED_PLL_LOCK

LED_CAM_READY

LED_DES_LOCK

LOCK_N

RCLK

FV

LV

DATA8

SW8

Signaux internes à la carte S3

Signaux d’échange avec l’interface (connecteur d’extension A2)

H_SYNC

V_SYNC

RVB3x4


Architecture interne : domaines synchrones

Le système doit traiter les pixels délivrés par la caméra en synchronisme avec l’horloge de celle-ci.

Le système doit pouvoir initialiser ou modifier la configurationde la caméra par son bus I2C, indépendamment du verrouillagedu désérialiseur.

Domaine synchrone de CLK25, horloge 25 MHz obtenuepar prédivision par 2 de QUARTZ (50 MHz).

Domaine synchrone de RCLK, horloge caméra 27 MHz restauréepar le désérialiseur.

Groupe ESEO – D.Genet – R. Perdriau – G. Savaton - Logique programmable avancée – Avril 2009 22

Architecture interne : domaines synchrones

/2 DCM

Config.I2C

Caméra

Traitementd’image

QUARTZ50MHz

CLK2525 MHz

REFCLK27 MHz

RCLK27 MHz

Le domaine « traitement d’image »doit être cadencé uniquement par RCLK, y compris la visualisation.


Architecture interne : domaine CLK25 (25 MHz)

CTRL_CAM

SDASCLK

CAM_RESET

LED_CAM_READY

LOCK_N

LED_DES_LOCK

QUARTZ

CLK25 REFCLKLED_PLL_LOCKPLL

PREDIV

RAZ

Signaux internes à la carte S3

Signaux d’échange avec l’interface (connecteur d’extension A2)


Architecture interne : domaine RCLK (27 MHz)

SW0SW1

LUMINANCE

LV

H_SYNC

CTRL_WVGAFV

LV_PULSE

FV_PULSE V_SYNC

BLANKXY

RVB

BAYERDATA

8

P_RVB3x4

PIX_COL

X Y

SW[2..6]

GRADIENT PIX_GRAD


Développement


Etapes du développement

Construction du contrôleur CTRL_CAM (utilise le bus I2C)

Construction d’une PLL 27 MHz

Après avoir créé un projet PTIPO incluant le source canevas PTIPO.vhd :

Construction du générateur de GRADIENT

Chaque étape sera validée par visualisation soit des leds de contrôle,soit de l’image produite sur moniteur VGA.

Construction du filtre inverse de BAYER


Génération de la PLL 27 MHz

Les versions 8.2 et plus de l’outil ISE de Xilinx intègrent dans leurs accessoires un générateur de code (CORE Generator) configurant de façon interactive les ressources spécialisées offertes par le FPGA cible, telles que les DCM (Digital Clock Manager) ou les blocs RAM.

Activation :Démarrer -> Tous les programmes -> Xilinx ISE Design Suite 12.3 -> ISE Design Tools

-> 64-bit Tools -> CORE Generator


Génération de la PLL 27 MHz

Désignation de la cible :

Sélection de laressource à configurer

Dans la fenêtre de droite demander« Customize and Generate »


Après avoir accepté les paramètres de setup,configurer la PLL avec :

CLKIN interne de 25 MHz

Sorties sélectionnées : CLK0, LOCKED et CLKFX

Le reste est inchangé.

Attention : la capture d’écran ci-contre est la vue par défaut et non l’objectif à atteindre.


Accepter les buffers pour les sorties sélectionnées.

Dernière étape :configuration de la fréquence de sortie

(27 MHz).

Valeur des modulosM & D ?


Instanciation de PLL27 et validation.

Après avoir terminé la configuration de l’IP "pll27", on dispose du code du component "pll27.vhd" que l’on instanciera au niveau supérieurdu projet, conformément à l’architecture prévue pour le domaineCLK25.

Test :

La led LED_PLL_LOCK doit s’allumer. Une mesure de la fréquencede REFCLK à l’oscilloscope doit donner 27 MHz.


Contrôleur caméra CTRL_CAM

L’envoi des commandes par le bus I2C

Le reset de la caméra par CAM_RESET

Ce contrôleur intervient au démarrage du système et doit produire une séquence d’initialisation assurant successivement :

Un component I2C_MASTER sera importé et instancié dans ce contrôleur.Il assurera la communication avec le capteur de la caméra via les signauxSDA et SCL, conformément au protocole du bus I2C.

La signalisation par LED_CAM_READY du succés de l’opération.


CTRL_CAM : vue externe

CTRL_CAM

SDA (inout)SCLK (inout)

CAM_RESET

CAM_READYCLK

RAZ

LOCK_N


CTRL_CAM : architecture interne

CAM_RESETCAM_READY

SDASCLK

I2C_MASTER

SEQUENCEUR

MODE : 2

SLAVE_ADDRESS : "1011100"

REG_I2C 8

DATA_TO_I2C

16

WORD_I2C24

CW4

START

ETAT

TIMER

BUSYLOCK_N


CTRL_CAM : Component I2C_MASTER

C’est un component destiné à contrôler un composant configurable par bus I2C, un peu allégé par rapport à la norme du protocole.

SDASCLK

SLAVE_ADDRESS : "1011100"

START BUSY

I2C_MASTER

8

16REG_2C

DATA_TO_I2C16

DATA_FROM_I2C (nc)

MODE

ERROR (nc)

CLK_FREQUENCY_MHZ : 25(paramètres génériques)


CTRL_CAM : I2C_MASTER, fonctionnement

---------------------------------------------------------- Capable de lire ou écrire des mots de 8 ou 16 bits-- 5 modes possibles-- 0 : envoi d'un octet de commande-- 1 : envoi d'un octet de commande + 1 octet de donnée-- 2 : envoi d'un octet de commande + 1 mot de 16 bits de donnée-- 3 : envoi d'un octet de commande + lecture de 1 octet de donnée-- 4 : envoi d'un octet de commande + lecture de 1 mot de 16 bits de donnée---- Démarre sur impulsion START-- L'octet de commande peut être en fait le numéro de registre I2C dans lequel-- serait alors écrite la donnée DATA_TO_I2C-- Met la sortie BUSY à 1 tant que l’opération lancée n’est pas terminée.--------------------------------------------------------


CTRL_CAM : Unités fonctionnelles (1)

WORD_I2C

C’est une mémoire contenant la séquence des commandes I2C à envoyer. Elle est formée de mots de 24 bits, concaténation de l’octet numéro de registre (REG_I2C) et de la donnée de 16 bits à y écrire (DATA_TO_I2C). Sa description peut correspondre au process suivant :

P_WORD_I2C : process(CW)begin case (CW) is

-- octet de poids fort : adresse registre à modifier-- octets suivants : donnée à écrirewhen 0 => WORD_I2C <= x"B3" & x"0000"; -- LVDS validationwhen 1 => WORD_I2C <= x"B1" & x"0000"; -- LVDS power upwhen 2 => -- mots suivants………………when others => WORD_I2C <= x"00" & x"0000"; -- mot de cloture

end case;end process P_WORD_I2C;


CTRL_CAM : Unités fonctionnelles(2)

REG_I2C et DATA_TO_I2C

CW

TIMER

C’est un compteur 4 bits (pour une séquence maximale de 15 pas) destiné à adresser la mémoire WORD_I2C.

Registres respectivement numéro de registre I2C et mot à écrire dans ce registre. Actualisés par WORD_I2C sous le contrôle du séquenceur.

Générateur d’intervalles de temps :RESET_TIME : délai pour le reset de la caméra (~ 500 ms)WARM_TIME : délai de démarrage du contrôleur I2C de la caméra (~ 20 périodes de CLK25)LOCK_TIME : délai pour obtenir le verrouillage du désérialiseursur un pattern envoyé par la caméra (~ 40 ms)


CTRL_CAM : séquencement

0 CS_TIMER CS_CW1

1 EN_TIMER CAM_RESETTIMER = RESET_TIME

2 CS_TIMER1

3 EN_TIMERTIMER = WARM_TIME

4 CS_TIMER

WORD_I2C /= 0

5 EN_REG_I2C EN_DATA_TO_I2C1

6 START EN_CW1

7

BUSY = '0'

8 EN_TIMER

Quand CW = pas de l’envoi du pattern de synchro + 1, on attendenviron 40ms (LOCK_TIME), sinon on continue.

9 CAM_READY

WORD_I2C = 0

0

Lexique des commandes :CS_CW et EN_CW : respectivement clear etvalidation synchrone du compteur CW .CS_TIMER et EN_TIMER : respectivement clear et validation synchrone du compteur TIMER.EN_REG_I2C et EN_DATA_TO_I2C : actualisations synchrones des registres désignés.START : ordre de lancement d’une commande I2C. CAM_READY : signalisation caméra prête

LOCK_N = '1'


CTRL_CAM : Séquence I2C

Rechercher dans la documentation du capteur les commandesI2C à faire successivement pour chaque valeur de CW :

0 : Valider le mode LVDS série

1 : Alimenter le port LVDS

2 : Activer « soft reset »

3 : Désactiver « soft reset »

4 : Activer la génération d’un motif de synchronisation (registre LVDS internal sync).

5 : Désactiver ce mode (le délai LOCK_TIME est géré dans le séquenceur)

6 : Mettre la production de LINE_VALID en mode continu (pas d’interruption pendant le blanking vertical).

7 : Ajuster le blanking horizontal de manière à ce que la durée d’une ligne soit égale à 32 µs, compte tenu de la fréquence pixel et du nombre de pixels visibles (752).


CTRL_CAM : Développement

Instancier CTRL_CAM dans le domaine CLK25 du top leveldu projet.

Coder la description du contrôleur, avec instanciation ducomponent I2C_MASTER.

En particulier, le process P_WORD_I2C intègrera tous lesmots I2C déterminés précédemment.

Tester

On pourra valider le test par observation du bon achèvement de la configuration par LED_CAM_READY, ainsi que par le verrouillage du désérialiseur (LED_DES_LOCK)

En sus, les signaux LV et FV pourront être contrôlés à l’oscilloscope.


Domaine RCLK (27 MHz) : visualisation brute

LV

H_SYNC

CTRL_WVGAFV

LV_PULSE

FV_PULSE V_SYNC

BLANKXY

RVBDATA

8 P_RVB3x4

Les pixels bruts peuvent être contrôlés par affichage sur écran VGA

Cette visualisation nécessite de produire à partir de la caméra les signaux de synchronisation H_SYNC et V_SYNC, ainsi que le blanking.

On importera pour cela un contrôleur CTRL_WVGA, lui-même contrôlépar les fronts montants de LV (LV_PULSE) et FV (FV_PULSE).


Contrôleur WVGA : architecture du component

Les compteurs X et Y sont remis à zéro de façon synchrone par LV_PULSE et FV_PULSE. Y est validé par LV_PULSE.

V_SYNC

DécodeurH_SYNC

DécodeurBLANK

H_SYNC

BLANK

DécodeurV_SYNC

XY

10

10

Leur état permet de produire par décodage asynchrone les signaux de synchronisation compatibles avec un écran VGA ainsi que le blanking.

Compteur X 10 bits

Compteur Y 10 bits

CSEN

FV_PULSE

CSLV_PULSE

RCLK

(27MHz)


Visualisation brute : développement

Importer et instancier CTRL_WVGA

Coder les process et instructions produisant les signaux FV_PULSE et LV_PULSE

Coder un process synchrone P_RVB utilisant directement les4 MSB du signal DATA issu du deserializer.

RVB <= DATA(7 downto 4) & DATA(7 downto 4) & DATA(7 downto 4);

On y utilisera simplement une triple concaténation telle que :

(ne pas oublier le conditionnement par le blanking)

Dans le top level du projet :


Visualisation brute : résultats

L’image a peu de niveaux de gris : on n'a pris que les 4 bits depoids fort pour la visualisation de contrôle.

L’image est matricée : on n’a pas tenu compte de la matrice de filtres colorés qui recouvre le capteur.

Il est impératif de réussir cette étape avant de passer à la suite du projet !

L’image est un peu comprimée dans le sens horizontal : normal, on affiche 752 pixels (WVGA) sur un écran VGA (au lieu de 640).


La couleur : matrice de Bayer

La restitution de la couleur réelle de chaque pixel passera par une interpolation sur un voisinage 3x3, dont le calcul varieraselon la parité de X et Y.

La partie sensible de la puce du capteur de la caméra est recouverte par une matrice de filtre colorés, dite matrice de Bayer

Chaque pixel est recouvert par unfiltre rouge, vert ou bleu selon ce modèle :

X(0)

Y(0)

0 1 0 1 0 1

0

1

0

1

0

1


Interpolateur de Bayer

Le flot DATA issu du désérialiseur va traverser un component BAYER dont voici la vue externe :

RVBBAYER

DATA

8

P_RVB 3x4

PIX_COL

3x8

XY

FV_PULSELV_PULSE

8

LUMINANCE

SW0 SW1

SW3 SW4

(ajustement)

(choix)


Interpolateur de Bayer: principe

Pour chaque pixel présenté à l’interpolateur, l’opérateur de calcul a besoin d’une matrice 3x3 MAT correspondant à un voisinage de 9 pixels pour calculer les composantes couleur :

DATA0

DATA1

DATA2

P_MATMAT

3x8

8

8

8

Opérateurde calcul

8

8

8

PARITE

R

V

B

DATA0 : pixel courant, d’abscisse X

DATA1 : pixel d’abscisse X retardé de 1 ligne

DATA2 : pixel d’abscisse X retardé de 2 lignes

Les retards ligne seront implémentés à l’aide des blocs RAM du FPGA

PIXEL_COLOR

3x8


Interpolateur : architecture interne

XY

pixel_color

Calculluminance

OPMAT3x3 (3x8)

luminance

BUF_SEL%3

FV_PULSELV_PULSE

CSEN

2 1 0

BUFF1

BUFF2

BUFF3

120

120

WE1

WE2

WE3

DATA

Une barrière synchrone sur le cheminde DATA à MAT est nécessaire pourcompenser la latence des buffers


Interpolateur : unités fonctionnelles (1)

BUFF_SEL : compteur synchrone modulo 3, validé sur LV_PULSE et mis à zéro sur FV_PULSE. Il sert à sélectionner de façon circulaire :

BUFF1, BUFF2 et BUFF3 : blocs mémoire adressés par l’abscisse X. A chaque nouvelle ligne, une mémoire est mise en écriture pendant que les deux autres alimentent la matrice 3x3 MAT. On prendra des blocs de 1 Ko.

MAT : matrice de 3x3 registres à décalage synchrones 8 bits, alimentée par les pixels directs et retardés. On utilisera letype integer pour faciliter les calculs ultérieurs.

Un bloc mémoire en écriture

Les blocs mémoire en lecture pour alimenter MAT



OP : opérateur d’interpolation calculant les composantes de PIXEL_COLOR avec le contenu de MAT en fonction de la parité courante. Sa description peut ressembler au process suivant :

P_COMP_RVB : process (RAZ,CLK)beginif CLK'EVENT and CLK = '1' then case PARITY is when "00" => R <= MAT(1)(1);

V <= (MAT(0)(1) + MAT(1)(0) + MAT(1)(2) + MAT(2)(1))/4;B <= (MAT(0)(0) + MAT(0)(2) + MAT(2)(0) + MAT(2)(2))/4;

when "01" => R <= (MAT(1)(0) + MAT(1)(2))/2;V <= MAT(1)(1);B <= (MAT(0)(1) + MAT(2)(1))/2;

when "10" => R <= (MAT(0)(1) + MAT(2)(1))/2;V <= MAT(1)(1);B <= (MAT(1)(0) + MAT(1)(2))/2;

when "11" => R <= (MAT(0)(0) + MAT(0)(2) + MAT(2)(0) + MAT(2)(2))/4;V <= (MAT(0)(1) + MAT(1)(0) + MAT(1)(2) + MAT(2)(1))/4;B <= MAT(1)(1);

end case;end if;end process P_COMP_RVB;



LUMINANCE : signal résultant de la moyenne des composantes RVB de PIXEL_COLOR.

MOYENNE_RVB := SOMME_RVB/4 + SOMME_RVB/16 + SOMME_RVB/64;

La division par 3 utilisera la construction suivante :

PIXEL_COLOR <= conv_std_logic_vector(R,8) & conv_std_logic_vector(V,8) & conv_std_logic_vector(B,8);

On aura au final :

LUMINANCE <= conv_std_logic_vector(MOYENNE_RVB ,8)


Interpolateur : ajustement manuel de la parité

La bonne correspondance entre la parité et le calcul de RVBdépendant d’un grand nombre de facteurs, on ajustera manuellement cette correspondance avec SW0 et SW1 :

PARITY <= (Y(0) xor SW1) & (X(0) xor SW0);

Par défaut la parité du pixel sera composée des LSB de Y et X :

PARITY <= Y(0) & X(0);


Interpolateur : component mémoire

Le component mémoire ram_1kx8 va être généré comme précédemment à l'aide du CORE GENERATOR :

Comme l’adressage sera unique, on choisira un modèle de RAM simple port (bloc).


Génération de ram_1kx8

Le paramétrage est simple :

Laisser passer les 3 pages suivantes de la configuration et demander « generate ».


Interpolateur : développement

Tester

Le test sera validé si l’affichage de PIXEL_COLOR et LUMINANCE est conforme aux attentes, sans effet visible de mosaïque.

Coder la description de l’interpolateur BAYER (bayer.vhd), avec triple instanciation du component ram_1kx8.

Instancier le component BAYER dans le niveau supérieur . Les signaux PIXEL_COLOR et LUMINANCE seront pris en compte par le process P_RVB moyennant une sélection par SW2 et SW3.

Importer dans le projet les fichiers ram_1kx8.vhd et ram_1kx8.edn.


GRADIENT : principe

L’image GRADIENT d’une image source traduit par ses niveaux de gris l’amplitude des variations locales du niveau de gris dans l’image source.


GRADIENT : calcul

Divers opérateurs peuvent être utilisés, variables selon la taille du voisinage pris en compte (2x2, 3x3) et les valeurs des coefficients des matrices de convolution.

On va tester un des plus connus, le Sobel, qui utilise deux matrices de convolution :

101

202

101

1M Pour lesens X

121

000

121

2M Pour lesens Y

Le gradient G associé à un pixel dans son voisinage V (3x3) se calculera de façon simplifiée :

VMVMG 21


Selon la progression on pourra ici continuer sur le SOBEL ou passer immédiatement à la binarisation adaptative.

Diapositive 63

On peut auparavant tester le SOBEL avec lefichier de configuaration sobel.bit


Sobel : construction

Faire une copie de BAYER, rebaptisée SOBEL (nom du fichier et celui de l’entity). Supprimer les signaux et parties inutiles. La sortiePIX_COL devient PIX_GRAD (8 bits). Le calcul devient :

La structure générale d’un opérateur 3x3 se trouve déjà dans le component Bayer : il suffit de changer le calcul effectué sur la matrice MAT.

P_PIX_GRAD : process (MAT)variable GRAD1,GRAD2,GRAD : integer;begin

GRAD1 := abs(MAT(0)(0) + 2*MAT(0)(1) + MAT(0)(2) - (MAT(2)(0) + 2*MAT(2)(1) + MAT(2)(2)));

GRAD2 := abs(MAT(0)(0) + 2*MAT(1)(0) + MAT(2)(0) - (MAT(0)(2) + 2*MAT(1)(2) + MAT(2)(2)));

GRAD := GRAD1 + GRAD2;if GRAD > 255 then GRAD := 255; end if;

PIX_GRAD <= conv_std_logic_vector(GRAD,8);

end process P_PIX_GRAD;


SOBEL : intégration

Tester

Le test sera validé si l’affichage de PIXEL_GRAD est conforme aux attentes.

Instancier le component SOBEL dans le top level (signal traité : LUMINANCE). Le signal PIXEL_GRAD sera pris en compte par le process P_RVB moyennant une sélection par SW4.

Importer dans le projet le source SOBEL.vhd.


Traitement final : rappel de l’objectif

Le but du prétraitement étant la détection des transitions horizontales, il reste à binariser l’image gradient par comparaison à un seuil et à détecter les fronts montants sous forme d’impulsions PIX_BIN_PULSE.

SEUIL

PIX_GRAD

L’amplitude du seuil fixe est délicate à choisir.

PIX_BIN

PIX_BIN_PULSE


Tester

Le test sera validé si les affichages de PIXEL_BIN et PIX_BIN_PULSE sont conformes aux attentes.

Ajouter également un process visant à détecter les fronts de PIX_BIN en produisant le signal PIX_BIN_PULSE.

Dans le niveau supérieur , ajouter un process P_PIX_BIN de binarisation : simple comparaison entre PIX_GRAD et une valeur de seuil fixée à 128. Ce process produit PIX_BIN (1 bit)

Traitement final : intégration

Le proces P_RVB prendra en compte les signaux PIX_BIN etPIX_BIN_PULSE sous conditions SW5 et SW6


Traitement final : résultats

PIX_GRAD PIX_BIN

PIX_BIN_PULSE

Tester la robustessedu traitement par

rapport à la nettetéde l’image.


Résultats obtenus : problème

L’éclairage ambiant

La netteté de l’image

La méthode utilisée (gradient Sobel + binarisation + détection de fronts sur X) manque de robustesse car l’amplitude du gradient peut varier selon

Pour ces raisons des transitions pertinentes peuvent être ignorées.


Autre méthode : binarisation suivie d’un pseudo-gradient

luminance

seuilfixe

luminancebinarisée

La binarisation consiste à réduire la luminance à 2 niveaux par comparaison à un seuil.

Ce cas de figure est idéal : le seuil est optimal par rapport au signalde luminance.

fronts


seuilfixe

luminancebinarisée

luminance

Binarisation réelle

seuil non adapté

Binarisation : inconvénient d’un seuil fixe

La binarisation à seuil fixe exige que la scène dont on a acquis l’image soit éclairéeuniformément et de façon constante, faute de quoi des éléments pertinentspeuvent être exclus du résultat.


luminanceBinarisation adaptative

luminancebinarisée

seuiladapté

Seuillage adaptatif

En prenant un seuil localement adapté, obtenu à partir d’un moyennage dela luminance sur un voisinage suffisamment étendu, la binarisation a plus de chances d’englober tous les détails pertinents.

Dans ce projet, on prendra un voisinage limité à une portion de ligne (32 pixels)centrée sur le pixel à binariser.


Binariseur adaptatif : vue externe

Le flot LUMINANCE va traverser le component BIN_ADAPT pour produire PIX_BIN et accessoirement PIX_MOY pour contrôle

RVB

P_RVB 3x4

PIX_COL

3x8

BIN_ADAPT

PIX_BIN

8

LUMINANCEPIX_MOY

8

SW3 SW4 SW5 SW6

(choix)


Binariseur adaptatif : principe

La moyenne sera calculée sur une portion de ligne de 32 pixels, en utilisant la somme des sorties d’un registre à décalage de 32 octets.

Moyenneursur 32 pixels

PIX_MOYLUMINANCE

PIX_BINComparateur

Ligne à retard16 pixels

PIX_DEL

PIX_BIN sera obtenu par comparaison de PIX_MOY avec PIX_DEL qui est la luminance retardée de la moitié de l’étendue du voisinage sur lequel a été calculée la moyenne.


La ligne retard DELAY_16 est redondante par rapport au registre TAB_PIX !

DELAY_16

COMP

PIX_DEL

PIX_BIN

Binariseur adaptatif : architecture optimisée

TAB_PIX

32x8

8

LUMINANCE

MOYENNE

8 PIX_MOY

COMP

PIX_DELPIX_BIN

PIX_DEL sera pris à la sortie du 16ème étage de TAB_PIX.


Binariseur adaptatif : unités fonctionnelles

COMP : a priori simple comparateur produisant le bit PIXEL_BIN à partir de la comparaison de PIX_DEL avec PIX_MOY.

MOYENNE : additionneur 32 octets. La somme divisée par 32 délivre la moyenne PIX_MOY.

TAB_PIX : registre à décalage 32 octets. Ne peut être réalisé avec un bloc RAM car il est nécessaire de disposer des 32 octets en parallèle pour en faire la somme.

AUX :=0;for I in 0 to 31 loop AUX := AUX + conv_integer(TAB_PIXEL(I));end loop;SOMME <= AUX;

A priori on pourra calculer la somme des 32 octets avec une boucle FOR :


Binariseur adaptatif : développement

Tester. Le test sera validé si :

Coder la description de BIN_ADAPT.

Instancier le component BIN_ADAPT dans le top level. Les signaux PIXEL_MOY et PIX_BIN seront pris en compte par leprocess P_RVB moyennant une sélection par SW4 et SW5.

La visualisation de PIX_MOY montre une image floutée horizontalement avec décalage de 32 pixels à droite

La visualisation de PIX_BIN montre une image à deux niveaux, décalée à droite avec effet « bruité » sur les zones à faible gradient.

RVB <= (others => PIX_BIN);Pour PIX_BIN on codera :

Désactiver le SOBEL dans le niveau supérieur.


Binariseur adaptatif : résultat

L’image binarisée présente des changements de niveau pertinents sur les transitions à gradients significatifs, tandis que les zones à faible gradient produisent du bruit.

LUMINANCE PIX_BIN


Binariseur adaptatif : amélioration

Origine du problème : la moyenne étant calculée sur un faiblevoisinage (32 pixels), celle-ci se confond avec la luminancedes zones à gradient voisin de zéro.

luminance (PIX_DEL)

moyenne

Zones à binarisation non pertinente

Remède : conditionner la pertinence de la binarisation à un critère calculé sur un petit voisinage, tel le moment de Hanningcalculé sur 8 pixels :

3

4

)(_8

1 nk

nk

npixtabmoyenneM Ici, n = 15


Binariseur adaptatif : conditionnement

Calcul du moment de Hanning sur 8 pixels :

Process de binarisation :

AUX := 0;for I in 11 to 18 loop

VAR1 := conv_integer(TAB_PIX(I));VAR2 := conv_integer(SEUIL);AUX := AUX + abs(VAR1 - VAR2);

end loop;MOMENT <= AUX;

P_PIX_BIN : process (CLK)beginif (CLK'EVENT and CLK='1') then if MOMENT > SOMME/32 then

if TAB_PIX(15) > SEUIL then PIX_BINi <= '1';else PIX_BINi <= '0';end if;

end if;end if;end process P_PIX_BIN;

(dans un process P_MOMENT)


Binariseur adaptatif conditionné : résultat

Les zones bruitées ont disparu

PIX_BIN


Pseudo-gradient

Tester la robustesse de ce traitement.

Il reste à créer dans le top level un process (s’il n’existe pas) qui fournira les impulsions PIX_BIN_PULSE par détection des fronts montants et descendantsde PIX_BIN.

PIX_BIN PIX_BIN_PULSE

Résultat attendu :


Contraintes de fréquence

Question : quelle est la fréquence maximale de chaque domaine synchrone ?(QUARTZ, CLK25 et RCLK). Ou plutôt, ces domaines tiennent-ils les fréquencesimposées ? Pour répondre à cette question le process « Implement design » a besoin de connaître les contraintes de fréquence.

Dans la fenêtre des processes, activer « Create Timing Constraints »

Si le fichier de contraintesrattaché au top level n’existe pasrépondre Yes.


Contraintes de fréquence : ajustement

Renseigner le champ Period des horloges QUARTZ, CLK25 et RCLK,puis sauvegarder. Un fichier de contraintes *.ucf est ajouté au projet.

Dans la fenêtre de l’éditeur de contraintes, sélectionner « Clock domains » dans « Timing Constraints ».

Relancer le process « Implement Design ».


Contraintes de fréquence : Timing Report

Dans la fenêtre des processes, activer « Design Summary/Reports »

Dans le Design Summary, sélectionner « Post-PAR Static Timing Report »


Contraintes de fréquence : Timing Report

==================================================================Timing constraint: TS_RCLK = PERIOD TIMEGRP "RCLK" 37 ns HIGH 50%;

Minimum period is 40.127ns.--------------------------------------------------------------------------------Slack: -3.127ns (requirement - (data path - clock path skew)) Source: Inst_BIN_ADAPT/TAB_PIX_1_0 (FF) Destination: Inst_BIN_ADAPT/SOMME_12 (FF) Requirement: 37.000ns Data Path Delay: 40.126ns (Levels of Logic = 26) Clock Path Skew: -0.001ns Source Clock: RCLK_BUFGP rising at 0.000ns Destination Clock: RCLK_BUFGP rising at 37.000ns Data Path: Inst_BIN_ADAPT/TAB_PIX_1_0 to Inst_BIN_ADAPT/SOMME_12

Exemple d’extrait, concernant le domaine RCLK :

Ici le chemin de TAB_PIX(1)(0) à SOMME(12) présente un temps de propagationtrop long par rapport à la contrainte de fréquence imposée au domaine RCLK.


Contraintes non respectées : recherche des origines

Lorsque un chemin est signalé comme trop long à parcourir, une méthode consisteà regarder ce que le synthétiseur a construit à partir du code correspondant à lacombinatoire installée sur ce chemin.

On dispose pour cela d’un utilitaire générateur de schéma RTL (Register Transfer Level)

Activer ce process et sélectionnerl’instance incluant le chemin concerné.On peut alors voir rapidement l’originedu problème sur le schéma affiché…


Contraintes non respectées : correction

A vous de jouer !

Documents

Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Février 20141 Logique programmable avancée Projet PTIPO ( P ré T raitement