[Numérique] Choix de kit FPGA pour convertisseur RGB analog vers HDMI

[invite396f0d7e]

Bonjour à vous

Je créé ce sujet afin d'être aiguillé dans mon choix de kit FPGA qui me permettra de mener à bien mon projet.

En gros, j'aimerais développer un convertisseur de signaux vidéos analogiques (Composite, RGB, Peritel) vers une sortie HDMI.
Le but étant de pouvoir brancher nos vielles consoles sur des écran contemporains sans les désagréments liés à la mauvaise adaptation de l'image que mes amis gamers connaissent bien.

J'aurais donc besoin sur cette carte de :
- numériser les signaux analogiques (ou bien récupérer le signal numérique car j'ai cru comprendre qu'il est arrivé un temps où l'on a fait transiter sur ces câbles des données numériques plutôt qu'analogiques)
- les traiter via des algos de filtrage (pour ceux qui jouent sur émulateur les filtres du genre SuperEagle, 2xscale, ... puis de l'AA évidemment)
- Générer le signal HDMI

Durant mes études j'ai utilisé des FPGA (donc VHDL + C), mais aussi des DSP (C + LinearAssembly), j'ai fait du traitement du signal, théorie de l'information... bref normalement j'ai le background pour.

Le problème, c'est que j'ai du mal à cerner mes besoins en terme de puissance nécessaire, de la "grosseur" du FPGA nécessaire pour réaliser cela.

J'imagine bien que tout cela se précisera au fur et à mesure que j'avancerai. Je me suis déjà renseigné pas mal sur les signaux que je vais devoir récupérer et générer (fonctionnement, fréquences, gammes de tension, forme de la trame) mais voilà tout.

Y a-t-il des personnes plus expérimentées qui pourraient m'aiguiller vers un kit de dév (pas trop cher ? pour débutant) qui me permettrait de déjà pouvoir bien avancer sans me retrouver rapidement limité par le matériel ?

Je vous remercie d'avance pour votre précieuse aide.
-----

[albanxiii]

Bonjour,

Vous pouvez développer votre système sur un simulateur, et une fois que vous avez quelque chose qui vous semble correct passer à la synthèse + placement routage, qui vous donnera la taille utilisée.
Les logiciels qui permettent de faire cela sont gratuits, chez Xilinx ou Intel (ex Altera).
Pour la synthèse + placement / routage il faudra que vous spécifiez un modèle de fpga dans le logiciel, le jeu consiste ensuite à trouver celui qui répond aux mieux à vox contraintes de performances et de coût. Mais vous pouvez faire tout ça sans avoir un vrai fpga sous la main.

[jiherve]

Bonjour,
Le soucis est que le format HDMI est protégé pour empêcher la copie des oeuvres il faudra donc se fournir l'encodeur HDMI et au final ce genre de circuit existe tout fait ou presque voir chez AD par exemple.
Développer ce genre d'interface est un travail de romain compter sur une équipe d'une dizaine de personnes (pointues) pendant un an ou plus.
JR

[invite396f0d7e]

Bonjour,

Vous pouvez développer votre système sur un simulateur, et une fois que vous avez quelque chose qui vous semble correct passer à la synthèse + placement routage, qui vous donnera la taille utilisée.
Les logiciels qui permettent de faire cela sont gratuits, chez Xilinx ou Intel (ex Altera).
Pour la synthèse + placement / routage il faudra que vous spécifiez un modèle de fpga dans le logiciel, le jeu consiste ensuite à trouver celui qui répond aux mieux à vox contraintes de performances et de coût. Mais vous pouvez faire tout ça sans avoir un vrai fpga sous la main.

En effet pour débuter c'est carrément mieux, je ne sais pas pourquoi je n'y ai pas pensé alors qu'on a toujours fait comme ça en TP.
Après j'aimerai quand même avoir du matos à un moment donné pour me motiver en mesurant du concret, mais effectivement c'est pas pour tout de suite.

Bonjour,
Le soucis est que le format HDMI est protégé pour empêcher la copie des oeuvres il faudra donc se fournir l'encodeur HDMI et au final ce genre de circuit existe tout fait ou presque voir chez AD par exemple.
Développer ce genre d'interface est un travail de romain compter sur une équipe d'une dizaine de personnes (pointues) pendant un an ou plus.
JR

Oui j'avais justement entendu parlé de cette protection et je me demandais comme il était possible de passer outre. Il me faudra donc forcément un encodeur HDMI du marché ?
Et j'avais peur aussi que cela représente une trop grande quantité de travail. Mais à la limite je me dis que je peux découper le projet en petit morceau.

1) Numérisation des signaux analogiques (je peux commencer par une seule image)
2) Création d'une image à partir des données numérisées (je peux toujours récupérer les données sur mon PC pour les tracer)
3) (ou 4)) Filtrage de l'image
4) (ou 3)) Encodage de l'image en format HDMI

Puis après passer à la vidéo (plusieurs images quoi)

Vu comme ça, vous pensez que c'est réalisable petit à petit ?
Au pire si je ne le fini pas, j'aurais au moins fait des trucs concrets.

Et pour le filtrage, je me dit qu'un kit de dev FPGA avec DSP est plus adapté pour débuter, non ?

Désolé si je dis des énormités

[A voir en vidéo sur Futura]

[jiherve]

Bonsoir,
Le domaine du traitement vidéo suppose implicitement des fréquences très élevées ce qui rend toute réalisation délicate de part le simple fait du routage des liaisons intercomposants. Même moi qui ai fait çà pendant 40 ans de façon professionnelle (ma dernière contribution dans ce domaine chez mon ex employeur fut un rotateur d'image full HD monochrome temps réel donc hardware FPGA + DDR2 horloge à 260MHz) je ne m'y risquerais pas en tant que bricoleur à domicile.
Rien que la numérisation est complexe car il faut disposer d'ADC flash et d'une fonction genlock pour générer une horloge de numérisation synchrone de la vidéo d'entrée et passée cette difficulté il faudra mémoriser or aujourd'hui exit les VRAM ou grosses SRAM rapides qui étaient assez collaboratives il faut utiliser des DDRx, là c'est la cours des grands.
Donc s'orienter vers du hard tout fait, le logiciel sera déjà assez compliqué comme çà.
JR

[invite396f0d7e]

Bonsoir,
Le domaine du traitement vidéo suppose implicitement des fréquences très élevées ce qui rend toute réalisation délicate de part le simple fait du routage des liaisons intercomposants. Même moi qui ai fait çà pendant 40 ans de façon professionnelle (ma dernière contribution dans ce domaine chez mon ex employeur fut un rotateur d'image full HD monochrome temps réel donc hardware FPGA + DDR2 horloge à 260MHz) je ne m'y risquerais pas en tant que bricoleur à domicile.
Rien que la numérisation est complexe car il faut disposer d'ADC flash et d'une fonction genlock pour générer une horloge de numérisation synchrone de la vidéo d'entrée et passée cette difficulté il faudra mémoriser or aujourd'hui exit les VRAM ou grosses SRAM rapides qui étaient assez collaboratives il faut utiliser des DDRx, là c'est la cours des grands.
Donc s'orienter vers du hard tout fait, le logiciel sera déjà assez compliqué comme çà.
JR

Bonsoir

Merci pour ton avis. Mais du coup, en ce qui concerne les fréquences et bandes passantes des signaux analogiques, j'ai cru comprendre que la bande passante maximale était de 6MHz (BP de la luminance, la chrominance étant contenue dedans). A ces fréquences là, sachant qu'en général on conseille d'échantillonner à 5-10x la fréquence maximale, ça devrait aller ?
Et pour la fonction genlock, d'après ce que je lis c'est ce qui permet de synchroniser la sortie vidéo et le récepteur.
Mais pour la partie numérisation, à quoi cela servirait-il ?
J'ai vu que la forme du signal analogique était construite de sorte à facilement savoir quand une ligne est tracée et quand on passe à la suivante.

Normalement, cela devrait suffire (connaissant le nombre de pixel sur une ligne et la durée d'une trame ligne) non ?
Et du coup imaginons, je choisis de prendre un composant qui numérisera mon signal analogique afin que je le récupère près à être interprété.
Il vaut mieux prendre un DSP si je ne fais plus que du traitement d'image non ? Ou bien le faire sur un FPGA est intéressant ?

Merci d'avance pour votre aide.

[bobflux]

Tu peux acheter des converto SCART -> HDMI tout faits pour 20 boules.

Cependant il y a un autre problème dans ton problème : tes consoles de jeu rétro. Je suppose que tu vas vouloir jouer avec ! Pour ça il faut une latence à l'affichage faible, et de préférence nulle.

En analogique et tube cathodique, quand la console sort le signal, il est envoyé directement à l'écran. Donc il n'y a pas de latence. Par contre si tu essaies de jouer sur une TV HD écran plat moderne, tu remarqueras que c'est impossible: les traitements que la TV inflige à l'image obligent à mettre 1 ou 2 frames en tampon, ce qui induit une latence de 20-40ms. Cela rend tout jeu un peu rapide injouable (genre Super Meat Boy).

De même, tout traitement que tu programmerais dans ta FPGA devrait induire une latence faible, hors de question par exemple de travailler sur l'image entière, il faudrait au maximum conserver quelques lignes en tampon.

Le plus simple serait un adaptateur SCART vers VGA, et utiliser un écran de PC. Les moniteurs n'ont pas cette latence, car on s'attend à les utiliser pour jouer.

[jiherve]

Bonsoir,
Si l'on échantillonne un signal vidéo avec une horloge non synchrone on récupère du gloubiboulga surtout si le signal est composite et qui faudra démoduler le codage couleur donc le Genlock est incontournable.
Comme c'est compliqué à faire il faut passer soit par un circuit intégré dédié (difficile à se procurer pour un amateur) soit par un produit tout fait intégrant digitaliseur et interface 'user friendly".
Mais tu peux faire comme tu le sens, la chute sera dure.
JR

[bobflux]

Après quelques minutes de gougle...

http://www.analog.com/media/en/techn...ts/ADV7280.PDF
http://www.analog.com/media/en/techn...ts/ADV7403.pdf
http://www.analog.com/media/en/techn...ts/ADV7802.pdf
http://www.ti.com/product/TVP5146M2
http://www.ti.com/product/TVP5160

À priori ces trucs font beaucoup de choses... Extraction de l'horloge pixel, numérisation, genlock... Je ne suis pas assez calé dans le domaine pour savoir si ça ira. Reste à en trouver un qui sera compatible avec tous tes formats (y compris la péritel RGB).

C'est logique, car dans les TVHD et les amplis home cinéma il y a forcément une puce qui accepte en entrée du composite, SCART, SVHS et autre, et qui sort du numérique. Donc ces puces existent, et il est logique qu'elles gèrent toutes les fonctions chiantes, horloges, synchro, etc...

Par contre, vazy les packages, TQFP 200 broches avec sortie 36 bits en parallèle, fuuuuuuu.... un truc plus moderne qui sort en LVDS pour utiliser genre 4 broches de ta FPGA serait le bienvenu !

Aussi, vazy les manuels de 300 pages (on notera l'absence de description détaillée des registres I2C dans les datasheet)

Par contre, il y a le désentrelacement... que tu ne peux pas activer, car si tu le fais, tu auras une latence de 1 frame et tes jeux seront injouables. Mais sans désentrelacement ça aura un look bizarre. Ou pas, je sais pas.

[jiherve]

Bonjour,
Une petite précision tous ces circuits sont souvent sous NDA pour ce qui est de leur usage/description fine aussi bon courage pour un amateur.
Si on ne desentrelace pas on divise la résolution verticale par 2 et si on desentrelace il y a un risque de cisaillement sur des images mobiles si celles ci ayant une cohérence sur deux trames ne sont pas synchronisées correctement, la latence passe alors à 40/33ms au minimum.
Ces circuits s'attendent aussi à recevoir des vidéo proches de la perfection aucun jitter ni imprecision n'est toléré sur les signaux de synchro j'ai bien donné avec certains.
JR

[bobflux]

> tous ces circuits sont souvent sous NDA

Ah bha oui, il faut signer avec son sang...

Quand à trouver de l'aide sur les forums quand à leur utilisation, bonne chance. Et puis en plus, t'as signé un NDA, donc t'as même pas le droit de poser une question !

[jiherve]

Bonsoir,
Oui c'est du vécu mais j'avais alors la puissance de frappe de mon employeur donc étude sous NDA et série en obsolète!
JR