Si vous consultez des projets hdmi sur un site comme hackaday , vous constaterez que chacun d'entre eux implique un FPGA. Je ne pense pas avoir vu de projet DIY avec sortie HDMI qui n'ait pas utilisé de FPGA.
Mais pourquoi? Pour autant que je sache, les FPGA sont chers, environ 70 $ - 100 $. Comparez cela à un Raspberry Pi pour 35 $, qui peut faire des choses beaucoup plus complexes et produire une sortie HDMI. Pourquoi un ARM n'est-il pas utilisé? Ou un microcontrôleur encore moins cher?
Dans le cas de la mise à niveau de la vidéo sur d'anciens systèmes de jeu, la logique ne devrait pas être plus compliquée qu'un microcontrôleur bon marché peut gérer , mais je continue à voir HDMI comme un obstacle impossible uniquement abordé par les FPGA.
Réponses:
Fondamentalement, aucun microcontrôleur, même le raspberry pi, n'est assez rapide. Le raspberry pi possède un GPU intégré qui génère la sortie HDMI. Et à part cela, la capacité d'E / S du raspberry pi est incroyablement limitée - l'interface à bande passante la plus élevée en dehors de HDMI est l'USB. De nombreux projets de conversion HDMI impliquent de prendre un autre flux vidéo dans un format étrange et de le retravailler en quelque chose qui peut être envoyé à un téléviseur HD standard via HDMI. Cela nécessite une logique d'interface personnalisée pour lire le signal vidéo, une logique de traitement du signal pour le reformater, une logique de codage HDMI TMDS, puis des sérialiseurs à haute vitesse pour réellement piloter le port HDMI.
Travailler avec du streaming, de la vidéo haute définition non compressée nécessite de traiter une énorme quantité de données, ce qui n'est pas possible sur un processeur général. Un signal vidéo 1080p à 30 images par seconde a environ 62 millions de pixels par seconde. Le raspberry pi fonctionne à 700 MHz, vous avez donc, oh, 11 instructions par pixel. Et c'est 11 instructions pour lire au format vidéo bizarre en temps réel, le redimensionner, etc., etc. Pas possible. Période.
Sur un FPGA, il est possible de générer un long pipeline de traitement qui peut traiter un ou plusieurs pixels par cycle d'horloge et le faire de manière très déterministe (pas d'interruptions ou de changement de tâche!) Afin que les données de pixels soient prêtes pour la transmission via HDMI exactement au bon moment. Si vous avez beaucoup travaillé avec des processeurs à usage général exécutant tout type de système d'exploitation, vous saurez qu'il est plus ou moins possible d'obtenir un chronométrage précis au niveau de la milliseconde, mais au niveau de la microseconde. Pour HDMI, vous avez besoin d'une précision à l'échelle nanoseconde. Non réalisable sur un CPU à usage général. Jetez également un œil au projet audio / vidéo HDMI pour le néo-géo. Celui-ci doit non seulement redimensionner la vidéo, il doit également rééchantillonner l'audio et l'insérer dans le flux vidéo HDMI.
Et cela ne tient toujours pas compte de la logique personnalisée requise pour lire dans le format de données d'entrée que vous avez. Vous aurez besoin d'un matériel personnalisé pour interpréter cela. Le logiciel n'est pas assez rapide ou suffisamment déterministe. Vous pourriez peut-être, par exemple, le reformater en une sorte de flux basé sur USB, mais cela nécessitera de toute façon une logique numérique personnalisée, de sorte que vous pourriez tout aussi bien sortir directement HDMI.
Pour implémenter tout cela, la logique numérique est vraiment la seule solution possible. Et si vous faites de la logique numérique, les FPGA sont la seule solution possible, car ils sont trop rapides et trop complexes pour la logique 7400 discrète et les ASIC sont, bien, plusieurs ordres de grandeur plus chers.
Un autre composant requis sont les sérialiseurs à haute vitesse et les pilotes différentiels réels pour générer les flux de données série parallèles qui sont envoyés sur le câble. Il n'est pas possible de bit-bang des données série de l'ordre d'un gigabit par seconde à partir d'un CPU à usage général, cela nécessite un matériel spécialisé. Le Raspberry Pi dispose d'un GPU intégré qui le fait, mais il est limité en termes de capacité du GPU, sans parler de ce qui est documenté. La plupart des FPGA contiennent au moins les pilotes différentiels et les bascules DDR nécessaires pour prendre en charge la vidéo à basse résolution et il y a pas mal de FPGA qui contiennent également les sérialiseurs nécessaires (par exemple, les blocs Xilinx OSERDES) pour générer des flux Full HD. N'oubliez pas que le flux série n'est pas «bande de base» comme un port série normal où les données réelles sont envoyées textuellement avec des informations de cadrage, mais les données sont en fait encodées avec TMDS (signalisation différentielle à transition minimisée) pour donner au signal certaines caractéristiques électriques. Un peu de logique est nécessaire pour implémenter cela en plus des sérialiseurs à grande vitesse réels. Tout cela est relativement simple à faire en logique numérique pure (enfin, le codage de toute façon - les sérialiseurs sont sans doute des signaux analogiques ou au moins mixtes) sur un ASIC ou un FPGA.
C'est en fait une partie très importante du processus global de conception de système numérique / embarqué de déterminer quelles parties d'un système peuvent être implémentées dans le logiciel et lesquelles nécessitent du matériel, soit sous la forme de puces spécialisées, FPGA, personnalisées ASIC, IP hard ou soft (HDL, netlists, GDSII), etc. Dans ce cas, c'est clair: la génération de signal vidéo nécessite un matériel spécialisé, qu'il s'agisse d'un GPU couplé à un CPU à usage général, d'un FPGA avec un hard ou noyau CPU souple ou couplé avec un processeur externe, ou quelque chose de plus spécialisé.
Edit: Je viens de réaliser que le site fpga4fun et le projet vidéo neo geo fonctionnent tous les deux en 640x480 au lieu de la full HD. Cependant, cela ne rend pas vraiment cela plus simple. L'horloge de pixels minimale est de 25 MHz, avec une horloge de bits de 250 MHz. Cela signifie que le FPGA n'a en fait pas besoin de sérialiseurs pour transmettre HDMI, uniquement des bascules DDR. Cela ne résout cependant pas le problème de la lecture des données vidéo. Si vous voulez le faire sur le raspberry pi sans assistance matérielle, vous devrez lire en continu depuis GPIO à 25 MHz. C'est-à-dire une lecture toutes les 175 instructions. Entrer dans le domaine des possibilités, mais la seule façon de faire fonctionner ce système est sur du métal nu (pas Linux) avec un assemblage codé à la main.
la source