(Pré Traitement d’Image de POteau)

Présentation au sujet: "(Pré Traitement d’Image de POteau)"— Transcription de la présentation:

1 (Pré Traitement d’Image de POteau)
Logique programmable avancé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 : Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Février 2014

3 Thème : traitement d’image temps réel
Le flot de pixels délivré par un capteur d’image va être traité à travers une cascade d’unités fonctionnelles visant à fournir successivement : Une image couleur L’information de luminance 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 traitement en chaque point de la chaîne. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

4 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) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

5 Exemple d’objet à détecter : piquet codé
Anneaux périodiques alternativement noirs et blancs (4 anneaux noirs au minimum) Anneau rouge Code barre d’identification sur 4 bits (ici 1001, soit poteau n° 9). La périodicité des bits du code barre est la même que celle des anneaux qui le précèdent. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

6 Détection d’un piquet codé
X Sens de scrutation Y Lorsque l’analyseur détecte sur une ligne de l’image des transitions périodiques en nombre suffisant avec une plage rouge, on présumera de la présence d’un piquet codé, dont le code à 4 bits peut être lu après mesure de la période spatiale des transitions lors de la détection. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

7 Valeur ajoutée : Configuration d’une PLL pour synthèse de fréquence
Configuration d’un capteur d’image par bus I2C 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 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

8 Structure générale du système
Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

9 Architecture globale du système
Carte SPARTAN3 Liaison série LVDS Bus I2C 2 Interface Désérialiseur + visualisation CAMERA Capteur Ecran de contrôle switches de configuration Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

10 Montage du système Caméra série Ecran VGA de contrôle
Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

11 La caméra Câble RJ45 (à ne pas connecter au réseau Ethernet !)
Capteur CMOS Support de lentille pour objectif à monture C Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

12 La caméra, caractéristiques
La caméra est équipée d’un capteur couleur CMOS MT9V032L12STC conçu par Micron, dont les principales caractéristiques sont : Format Wide VGA à pleine résolution : 480 (V) x 752 (H) Taille des pixels : 6 µm x 6 µm Matrice de filtres colorés de Bayer Sortie parallèle 12 bits Sérialiseur intégré : sortie LVDS série 10 bits Configurable par bus I2C Seule la sortie série est utilisée. La caméra est cadencée à 27 MHz, ce qui permet un débit de l’ordre de 60 trames par seconde à pleine résolution. Elle est alimentée en 3.3 V. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

13 La caméra, composant I2C esclave
La caméra est matériellement configurée pour être reconnue sur le bus I2C avec l’adresse esclave " " Le débit du bus I2C peut atteindre 400 kbits/s. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

14 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 Voltage Differential 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 local 27 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). Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

15 Le désérialiseur 8 LVDS_POS DATA [7:0] LVDS_NEG FV SN65LV1212 LV
REFCLK RCLK LOCK_N Désérialiseur RF_N Liaisons avec la caméra Liaisons avec la carte Spartan 3 Configuration locale (0 ou 1) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

16 La PLL du désérialiseur
REFCLK RCLK Désérialiseur LOCK_N Le circuit possède en interne une PLL qui va se verrouiller sur l’horloge de transmission TCLK incluse dans les signaux LVDS. Elle a besoin pour cela 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

17 Désérialiseur : les horloges
REFCLK RCLK RF_N Comme la caméra est cadencée à 27 MHz, la carte Spartan 3 devra produire 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 à cadencer tout le domaine synchrone propre au traitement des pixels. L’entrée RF_N permet de choisir le front de RCLK (rising or falling) qui servira à échantillonner les pixels. 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 strap RCLK (RF_N=1) RCLK (RF_N=0) Par défaut, on utilisera le mode RF_N = 1. Cependant, en cas de dysfonctionnement, on pourra toujours tester le mode RF_N=0. Groupe ESEO – D.Genet – R. Perdriau – G. Savaton - Logique programmable avancée – Avril 2009

19 Les signaux de synchronisation FV et LV
8 LVDS_POS DATA [7:0] Désérialiseur LVDS_NEG FV LV Par défaut, FV (Frame Valid) et LF (Line Valid) auront les formes suivantes : FV Blanking trame 16,66 ms (60Hz) Blanking ligne LV 32 µs Ligne 478 Ligne 479 Ligne 0 Ligne 1 Ligne 2 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

20 Architecture du système de traitement : vue externe
QUARTZ RAZ REFCLK SDA SCLK CAM_RESET_N LOCK_N RCLK FV LV DATA 8 LED_PLL_LOCK LED_CAM_READY LED_DES_LOCK H_SYNC V_SYNC RVB 3x4 SW 8 Signaux internes à la carte S3 Signaux d’échange avec l’interface (connecteur d’extension A2) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

21 Architecture interne : domaines synchrones
Le système doit pouvoir initialiser ou modifier la configuration de la caméra par son bus I2C, indépendamment du verrouillage du désérialiseur. Domaine synchrone de CLK25, horloge 25 MHz obtenue par prédivision par 2 de QUARTZ (50 MHz). Le système doit traiter les pixels délivrés par la caméra en synchronisme avec l’horloge de celle-ci. Domaine synchrone de RCLK, horloge caméra 27 MHz restaurée par 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 Caméra Traitement
QUARTZ 50MHz CLK25 25 MHz REFCLK 27 MHz RCLK 27 MHz /2 DCM Caméra Traitement d’image Config. I2C Le domaine « traitement d’image » doit être cadencé uniquement par RCLK, y compris la visualisation. ! Groupe ESEO – D.Genet – R. Perdriau – G. Savaton - Logique programmable avancée – Avril 2009

23 Architecture interne : domaine CLK25 (25 MHz)
QUARTZ CLK25 REFCLK LED_PLL_LOCK PLL PREDIV RAZ CTRL_CAM SDA SCLK CAM_RESET LED_CAM_READY LOCK_N LED_DES_LOCK Signaux internes à la carte S3 Signaux d’échange avec l’interface (connecteur d’extension A2) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

24 Architecture interne : domaine RCLK (27 MHz)
LV H_SYNC CTRL_WVGA FV LV_PULSE FV_PULSE V_SYNC BLANK X Y RVB BAYER DATA 8 P_RVB 3x4 PIX_COL X Y LUMINANCE GRADIENT PIX_GRAD SW[2..6] SW0 SW1 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

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

26 Etapes du développement
Après avoir créé un projet PTIPO incluant le source canevas PTIPO.vhd : Construction d’une PLL 27 MHz Construction du contrôleur CTRL_CAM (utilise le bus I2C) Construction du filtre inverse de BAYER 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

27 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 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

28 ressource à configurer
Génération de la PLL 27 MHz Désignation de la cible : Sélection de la ressource à configurer Dans la fenêtre de droite demander « Customize and Generate » Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

29 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

30 Accepter les buffers pour les sorties sélectionnées.
Dernière étape : configuration de la fréquence de sortie (27 MHz). Valeur des modulos M & D ? Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

31 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érieur du projet, conformément à l’architecture prévue pour le domaine CLK25. Test : La led LED_PLL_LOCK doit s’allumer. Une mesure de la fréquence de REFCLK à l’oscilloscope doit donner 27 MHz. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

32 Contrôleur caméra CTRL_CAM
Ce contrôleur intervient au démarrage du système et doit produire une séquence d’initialisation assurant successivement : Le reset de la caméra par CAM_RESET L’envoi des commandes par le bus I2C La signalisation par LED_CAM_READY du succés de l’opération. 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 signaux SDA et SCL, conformément au protocole du bus I2C. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

33 CTRL_CAM : vue externe SDA (inout) LOCK_N SCLK (inout) CTRL_CAM
CAM_RESET RAZ CLK CAM_READY Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

34 CTRL_CAM : architecture interne
MODE : 2 SLAVE_ADDRESS : " " WORD_I2C 24 SDA SCLK I2C_ MASTER CW 4 REG_I2C 8 ETAT DATA_ TO_I2C 16 BUSY LOCK_N TIMER START SEQUENCEUR CAM_RESET CAM_READY Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

35 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. SLAVE_ADDRESS : " " (paramètres génériques) CLK_FREQUENCY_MHZ : 25 MODE I2C_ MASTER SDA SCLK 8 16 REG_2C DATA_TO_I2C DATA_FROM_I2C (nc) START BUSY ERROR (nc) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

36 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

37 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 à écrire when 0 => WORD_I2C <= x"B3" & x"0000"; -- LVDS validation when 1 => WORD_I2C <= x"B1" & x"0000"; -- LVDS power up when 2 => -- mots suivants ……………… when others => WORD_I2C <= x"00" & x"0000"; -- mot de cloture end case; end process P_WORD_I2C; Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

38 CTRL_CAM : Unités fonctionnelles(2)
CW C’est un compteur 4 bits (pour une séquence maximale de 15 pas) destiné à adresser la mémoire WORD_I2C. REG_I2C et DATA_TO_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. TIMER 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érialiseur sur un pattern envoyé par la caméra (~ 40 ms) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

39 CTRL_CAM : séquencement
LOCK_N = '1' CTRL_CAM : séquencement CS_TIMER CS_CW 1 EN_TIMER CAM_RESET TIMER = RESET_TIME 2 3 TIMER = WARM_TIME 4 WORD_I2C /= 0 5 EN_REG_I2C EN_DATA_TO_I2C 6 START EN_CW 7 BUSY = '0' 8 Quand CW = pas de l’envoi du pattern de synchro + 1, on attend environ 40ms (LOCK_TIME), sinon on continue. 9 CAM_READY WORD_I2C = 0 Lexique des commandes : CS_CW et EN_CW : respectivement clear et validation 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 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

40 CTRL_CAM : Séquence I2C Rechercher dans la documentation du capteur les commandes I2C à 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). Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

41 CTRL_CAM : Développement
Coder la description du contrôleur, avec instanciation du component I2C_MASTER. En particulier, le process P_WORD_I2C intègrera tous les mots I2C déterminés précédemment. Instancier CTRL_CAM dans le domaine CLK25 du top level du projet. 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

42 Domaine RCLK (27 MHz) : visualisation brute
Les pixels bruts peuvent être contrôlés par affichage sur écran VGA LV H_SYNC CTRL_WVGA FV LV_PULSE FV_PULSE V_SYNC BLANK X Y RVB DATA 8 P_RVB 3x4 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). Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

43 Contrôleur WVGA : architecture du component
V_SYNC Décodeur H_SYNC BLANK X Y 10 Compteur X 10 bits Compteur Y CS EN FV_PULSE LV_PULSE RCLK (27MHz) 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. Leur état permet de produire par décodage asynchrone les signaux de synchronisation compatibles avec un écran VGA ainsi que le blanking. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

44 Visualisation brute : développement
Dans le top level du projet : Coder les process et instructions produisant les signaux FV_PULSE et LV_PULSE Importer et instancier CTRL_WVGA Coder un process synchrone P_RVB utilisant directement les 4 MSB du signal DATA issu du deserializer. On y utilisera simplement une triple concaténation telle que : RVB <= DATA(7 downto 4) & DATA(7 downto 4) & DATA(7 downto 4); (ne pas oublier le conditionnement par le blanking) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

45 Visualisation brute : résultats
L’image est matricée : on n’a pas tenu compte de la matrice de filtres colorés qui recouvre le capteur. L’image a peu de niveaux de gris : on n'a pris que les 4 bits de poids fort pour la visualisation de contrôle. 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). Il est impératif de réussir cette étape avant de passer à la suite du projet ! Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

46 La couleur : matrice de Bayer
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 X(0) Y(0) 1 Chaque pixel est recouvert par un filtre rouge, vert ou bleu selon ce modèle : La restitution de la couleur réelle de chaque pixel passera par une interpolation sur un voisinage 3x3, dont le calcul variera selon la parité de X et Y. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

47 Interpolateur de Bayer
Le flot DATA issu du désérialiseur va traverser un component BAYER dont voici la vue externe : RVB BAYER DATA 8 P_RVB 3x4 PIX_COL 3x8 X Y FV_PULSE LV_PULSE 8 LUMINANCE SW0 SW1 SW3 SW4 (choix) (ajustement) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

48 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_MAT MAT 3x8 8 Opérateur de calcul 8 PARITE R V B PIXEL_COLOR 3x8 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 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

49 Interpolateur : architecture interne
X Y pixel_color Calcul luminance OP MAT 3x3 (3x8) BUFF1 BUFF2 BUFF3 1 2 WE1 WE2 WE3 DATA BUF_SEL %3 FV_PULSE LV_PULSE CS EN 2 1 0 Une barrière synchrone sur le chemin de DATA à MAT est nécessaire pour compenser la latence des buffers Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

50 Interpolateur : unités fonctionnelles (1)
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. 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 : Un bloc mémoire en écriture Les blocs mémoire en lecture pour alimenter MAT MAT : matrice de 3x3 registres à décalage synchrones 8 bits, alimentée par les pixels directs et retardés. On utilisera le type integer pour faciliter les calculs ultérieurs. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

51 Interpolateur : unités fonctionnelles (2)
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) begin if 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; B <= (MAT(1)(0) + MAT(1)(2))/2; when "11" => R <= (MAT(0)(0) + MAT(0)(2) + MAT(2)(0) + MAT(2)(2))/4; B <= MAT(1)(1); end case; end if; end process P_COMP_RVB; Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

52 Interpolateur : unités fonctionnelles (3)
LUMINANCE : signal résultant de la moyenne des composantes RVB de PIXEL_COLOR. La division par 3 utilisera la construction suivante : MOYENNE_RVB := SOMME_RVB/4 + SOMME_RVB/16 + SOMME_RVB/64; On aura au final : PIXEL_COLOR <= conv_std_logic_vector(R,8) & conv_std_logic_vector(V,8) & conv_std_logic_vector(B,8); LUMINANCE <= conv_std_logic_vector(MOYENNE_RVB ,8) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

53 Interpolateur : ajustement manuel de la parité
Par défaut la parité du pixel sera composée des LSB de Y et X : PARITY <= Y(0) & X(0); La bonne correspondance entre la parité et le calcul de RVB dé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); Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

54 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). Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

55 Génération de ram_1kx8 Le paramétrage est simple :
Laisser passer les 3 pages suivantes de la configuration et demander « generate ». Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

56 Interpolateur : développement
Importer dans le projet les fichiers ram_1kx8.vhd et ram_1kx8.edn. 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. Tester Le test sera validé si l’affichage de PIXEL_COLOR et LUMINANCE est conforme aux attentes, sans effet visible de mosaïque. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

57 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

58 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 : Pour le sens X Pour le sens Y Le gradient G associé à un pixel dans son voisinage V (3x3) se calculera de façon simplifiée : Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

59 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 le fichier de configuaration sobel.bit Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

60 Sobel : construction 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. Faire une copie de BAYER, rebaptisée SOBEL (nom du fichier et celui de l’entity). Supprimer les signaux et parties inutiles. La sortie PIX_COL devient PIX_GRAD (8 bits). Le calcul devient : 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; Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

61 SOBEL : intégration Importer dans le projet le source SOBEL.vhd.
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. Tester Le test sera validé si l’affichage de PIXEL_GRAD est conforme aux attentes. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

62 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. PIX_GRAD SEUIL PIX_BIN PIX_BIN_PULSE L’amplitude du seuil fixe est délicate à choisir. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

63 Traitement final : intégration
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) Ajouter également un process visant à détecter les fronts de PIX_BIN en produisant le signal PIX_BIN_PULSE. Le proces P_RVB prendra en compte les signaux PIX_BIN et PIX_BIN_PULSE sous conditions SW5 et SW6 Tester Le test sera validé si les affichages de PIXEL_BIN et PIX_BIN_PULSE sont conformes aux attentes. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

64 Traitement final : résultats
PIX_GRAD PIX_BIN PIX_BIN_PULSE Tester la robustesse du traitement par rapport à la netteté de l’image. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

65 Résultats obtenus : problème
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 La netteté de l’image L’éclairage ambiant Pour ces raisons des transitions pertinentes peuvent être ignorées. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

66 Autre méthode : binarisation suivie d’un pseudo-gradient
La binarisation consiste à réduire la luminance à 2 niveaux par comparaison à un seuil. luminance luminance binarisée seuil fixe fronts Ce cas de figure est idéal : le seuil est optimal par rapport au signal de luminance. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

67 Binarisation : inconvénient d’un seuil fixe
La binarisation à seuil fixe exige que la scène dont on a acquis l’image soit éclairée uniformément et de façon constante, faute de quoi des éléments pertinents peuvent être exclus du résultat. Binarisation réelle luminance seuil non adapté seuil fixe luminance binarisée Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

68 Binarisation adaptative
Seuillage adaptatif En prenant un seuil localement adapté, obtenu à partir d’un moyennage de la luminance sur un voisinage suffisamment étendu, la binarisation a plus de chances d’englober tous les détails pertinents. Binarisation adaptative luminance seuil adapté luminance binarisée Dans ce projet, on prendra un voisinage limité à une portion de ligne (32 pixels) centrée sur le pixel à binariser. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

69 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 LUMINANCE PIX_MOY SW3 SW4 SW5 SW6 (choix) Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

70 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. 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. Moyenneur sur 32 pixels PIX_MOY LUMINANCE PIX_BIN Comparateur Ligne à retard 16 pixels PIX_DEL Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

71 Binariseur adaptatif : architecture optimisée
LUMINANCE COMP PIX_DEL PIX_BIN TAB_PIX DELAY_16 COMP PIX_DEL PIX_BIN 8 32x8 PIX_MOY 8 MOYENNE PIX_DEL sera pris à la sortie du 16ème étage de TAB_PIX. La ligne retard DELAY_16 est redondante par rapport au registre TAB_PIX ! Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

72 Binariseur adaptatif : unités fonctionnelles
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. MOYENNE : additionneur 32 octets. La somme divisée par 32 délivre la moyenne PIX_MOY. A priori on pourra calculer la somme des 32 octets avec une boucle FOR : AUX :=0; for I in 0 to 31 loop AUX := AUX + conv_integer(TAB_PIXEL(I)); end loop; SOMME <= AUX; COMP : a priori simple comparateur produisant le bit PIXEL_BIN à partir de la comparaison de PIX_DEL avec PIX_MOY. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

73 Binariseur adaptatif : développement
Coder la description de BIN_ADAPT. Désactiver le SOBEL dans le niveau supérieur. Instancier le component BIN_ADAPT dans le top level. Les signaux PIXEL_MOY et PIX_BIN seront pris en compte par le process P_RVB moyennant une sélection par SW4 et SW5. RVB <= (others => PIX_BIN); Pour PIX_BIN on codera : Tester. Le test sera validé si : 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

74 Binariseur adaptatif : résultat
LUMINANCE PIX_BIN 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. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

75 Binariseur adaptatif : amélioration
Origine du problème : la moyenne étant calculée sur un faible voisinage (32 pixels), celle-ci se confond avec la luminance des 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 Hanning calculé sur 8 pixels : Ici, n = 15 Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

76 Binariseur adaptatif : conditionnement
Calcul du moment de Hanning sur 8 pixels : 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; (dans un process P_MOMENT) P_PIX_BIN : process (CLK) begin if (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 process P_PIX_BIN; Process de binarisation : Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

77 Binariseur adaptatif conditionné : résultat
PIX_BIN Les zones bruitées ont disparu Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

78 Pseudo-gradient 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 descendants de PIX_BIN. PIX_BIN PIX_BIN_PULSE Résultat attendu : Tester la robustesse de ce traitement. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

79 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équences imposé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 contraintes rattaché au top level n’existe pas répondre Yes. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

80 Contraintes de fréquence : ajustement
Dans la fenêtre de l’éditeur de contraintes, sélectionner « Clock domains » dans « Timing Constraints ». Renseigner le champ Period des horloges QUARTZ, CLK25 et RCLK, puis sauvegarder. Un fichier de contraintes *.ucf est ajouté au projet. Relancer le process « Implement Design ». Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

81 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 » Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

82 Contraintes de fréquence : Timing Report
Exemple d’extrait, concernant le domaine RCLK : ================================================================== Timing constraint: TS_RCLK = PERIOD TIMEGRP "RCLK" 37 ns HIGH 50%; Minimum period is ns. Slack: ns (requirement - (data path - clock path skew)) Source: Inst_BIN_ADAPT/TAB_PIX_1_0 (FF) Destination: Inst_BIN_ADAPT/SOMME_12 (FF) Requirement: ns Data Path Delay: ns (Levels of Logic = 26) Clock Path Skew: ns Source Clock: RCLK_BUFGP rising at 0.000ns Destination Clock: RCLK_BUFGP rising at ns Data Path: Inst_BIN_ADAPT/TAB_PIX_1_0 to Inst_BIN_ADAPT/SOMME_12 Ici le chemin de TAB_PIX(1)(0) à SOMME(12) présente un temps de propagation trop long par rapport à la contrainte de fréquence imposée au domaine RCLK. Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

83 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 à la combinatoire 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électionner l’instance incluant le chemin concerné. On peut alors voir rapidement l’origine du problème sur le schéma affiché… Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009

84 Contraintes non respectées : correction
A vous de jouer ! Groupe ESEO – D.Genet - R. Perdriau - G. Savaton - Logique programmable avancée – Avril 2009