FPGA VGA Buffer. Comment lire et écrire?

J'ai une carte Altera DE2 et j'essaie de dessiner des sprites. J'ai du mal à implémenter un tampon d'écran.

J'ai une entité d'affichage qui à un taux de 25 MHz émet des pixels pour l'affichage VGA.

J'espérais implémenter un tampon dans SDRAM. L'idée originale était de charger les pixels du pixel suivant à un taux de 25 MHz à partir de la SDRAM. Cela fonctionne, mais je ne peux pas écrire de pixels dans la SDRAM à ce rythme, ni effacer l'écran assez rapidement pour chaque nouvelle image. Il me faut 2 horloges pour écrire des données et ma carte fonctionne à 50 MHz, j'ai donc juste assez de temps pour faire une lecture complète.

Je suppose que je fais quelque chose de terriblement, terriblement mal. Comment un tel canevas de dessin est-il normalement implémenté en VHDL?

La chose la plus proche que j'ai pu trouver est d'utiliser un jeu de couleurs 2-3-3 (RVB) pour récupérer chaque pixel et écrire sur le bélier de la toile pendant le temps VGA "porche" (suppression). Cela signifie que sur chacune des horloges de 25 MHz, je ne peux mettre à jour que 15% de l'écran et j'ai en quelque sorte besoin que mon circuit sache de quels 15% il met à jour?

Je ne peux pas comprendre comment utiliser la double mise en mémoire tampon car je ne peux pas comprendre comment écrire des données dans la mémoire pendant la lecture. Existe-t-il un moyen d'éviter de frapper le protocole en bits Comment fait ce gars?

Un couple d'approches qui peuvent être utiles pour certains styles d'affichage consiste à diviser le panneau d'affichage en tuiles, et

1. restreindre chaque mosaïque à l'utilisation d'un petit ensemble de couleurs, permettant l'utilisation de moins de 8 bits par pixel, ou
2. utilisez un ou deux octets de chaque mosaïque pour sélectionner un emplacement à partir duquel lire les données bitmap.

La première approche pourrait réduire la vitesse à laquelle les données devaient être lues dans la mémoire d'affichage. Par exemple, si l'on utilise des tuiles de 16 x 16 et pouvant avoir chacune quatre couleurs choisies parmi un ensemble de 256, alors sans utiliser de RAM supplémentaire dans le FPGA, on peut réduire le nombre de lectures en mémoire par 16 pixels à huit (quatre valeurs de couleur, plus quatre octets pour le bitmap). Si l'on ajoutait 160 octets de mémoire tampon / RAM (*) au FPGA, on pourrait réduire le nombre de lectures en mémoire par 16 pixels à quatre, en utilisant 160 lectures supplémentaires toutes les 16 lignes de numérisation pour lire l'ensemble de couleurs de mosaïque suivant. Si l'on voulait 16 couleurs par tuile, la deuxième approche nécessiterait 640 octets de RAM supplémentaires, à moins que l'on place des restrictions sur le nombre de palettes différentes qui pourraient exister sur une ligne.

La deuxième approche augmenterait probablement plutôt que de réduire la bande passante mémoire totale requise pour produire un affichage, mais réduirait la quantité de mémoire qui devrait être mise à jour pour changer l'affichage - on pourrait changer un octet ou deux pour mettre à jour un 8x8 ou Zone 16x16 de l'écran. Selon ce que vous essayez d'afficher, il peut être utile lorsque vous utilisez ce style d'approche d'utiliser un périphérique de mémoire pour contenir les formes de tuiles et un autre pour conserver la sélection de tuiles. On pourrait, par exemple, utiliser une RAM rapide de 32Kx8 pour contenir quelques cartes de tuiles 80x60 avec deux octets par tuile. Si le FPGA n'avait pas de tampon, il devrait lire un octet tous les quatre pixels; même avec une RAM statique de 40ns, cela laisserait beaucoup de temps au CPU pour mettre à jour l'affichage (un écran entier ne ferait que 9600 octets).

Soit dit en passant, si l'on ne voulait pas ajouter une RAM 32Kx8 mais pourrait ajouter ajouter 320 octets de mise en mémoire tampon / RAM (**) au FPGA, on pourrait utiliser une approche de tuile-carte mais avoir le CPU ou le DMA alimenter 160 octets au afficher toutes les 8 lignes de balayage. Cela alourdirait quelque peu le contrôleur même lorsque rien sur l'écran ne changerait, mais pourrait simplifier les circuits.

(*) Le tampon peut être implémenté sous forme de RAM, ou sous la forme d'une séquence de 32 registres à décalage de 40 bits plus une petite logique de commande.

(**) Le tampon peut être implémenté comme deux RAM de 160 octets ou comme deux groupes de seize registres à décalage de 80 bits.

Les sprites ne sont normalement pas effectués avec un tampon de trame (si je comprends bien le mot). Au lieu de cela, vous comparez les coordonnées x et y avec les xmin, ymin et xmax, ymax du sprite. Si la position de numérisation actuelle se trouve à l'intérieur du sprite, sortez la couleur appropriée de la mémoire du sprite.

Si vous essayez d'afficher un tampon de trame, prenez courage. C'était mon premier grand projet FPGA. La SDRAM ne devrait pas être un problème à 100 MHz (je l'ai fait pour la première fois il y a une dizaine d'années, et le silicium est désormais plus rapide), alors multipliez votre horloge à 50 MHz. Écrire votre propre contrôleur sera éducatif :)

Cela vous donne beaucoup de bande passante pour jouer, vous pouvez ensuite doubler le tampon, pas de problème. Le VGA 60 Hz a besoin d'une moyenne de 18 Mpixels / sec. Si vous disposez d'un périphérique de 16 bits de large, vous disposez d'une bande passante maximale de 200 Mo / s. Même si vous parvenez seulement à être efficace à 50% (ce qui devrait être faisable), c'est 100Mpixels / sec @ 16 bits par pixel ou 50Mpixels / sec @ 32bits par pixel.

Par exemple, il se peut que votre RAM ait besoin de 60 ns pour configurer une lecture, mais peut ensuite éclater 8 mots en 80 ns - soit 8 octets en ~ 140 ns. SI vous pouvez faire en sorte que votre RAM fasse des rafales plus longues, cela aiderait à amortir le coût de la configuration de la lecture.

Sur la base de votre commentaire selon lequel il s'agit d'une RAM octet, c'est un peu plus de 50 Mo / s, seulement 16 Mo / s @ 24 bits par pixel :( Vous n'avez tout simplement pas assez de bande passante pour faire un affichage en vraies couleurs, même en VGA. pourrait faire 8 bits par pixel assez facilement, mais ce n'est que 2 ou 3 bits par couleur - ce qui peut être OK pour votre application, je ne sais pas. Ou vous pouvez faire une table de recherche de 256 couleurs comme autrefois - après en lisant le tampon de trame, vous utilisez ensuite la valeur pour rechercher dans une horloge RAM interne pour obtenir les 24 bits (ou 18 bits, qui conviendraient bien dans un BRAM) de couleur à sortir sur le moniteur.

Le double tampon fonctionne toujours:

Afficher une image à partir de l'adresse 0 (il suffit de lire tous les pixels à tour de rôle, en interrompant les lectures pendant les intervalles de suppression).

Écrivez votre prochain cadre dans un autre emplacement. Pour cette double mise en mémoire tampon, votre contrôleur DRAM devra établir une priorité entre les demandes concurrentes des canaux de lecture et d'écriture. Astuce, donnez la priorité aux lectures car elles sont critiques en temps :)