FPGA VGA Buffer. ¿Cómo leer y escribir?

8

Tengo un tablero Altera DE2 y trato de dibujar sprites. Estoy teniendo algunos problemas para implementar un búfer de pantalla.

Tengo una entidad de visualización que a una velocidad de 25 MHZ genera píxeles para la visualización vga.

Tenía la esperanza de implementar un búfer en SDRAM. La idea original era cargar píxeles en el siguiente píxel a una velocidad de 25 MHZ desde la SDRAM. Esto funciona, pero no puedo escribir píxeles en la SDRAM a esta velocidad ni puedo borrar la pantalla lo suficientemente rápido para cada nuevo marco. Me toma 2 relojes para escribir datos y mi tablero funciona a 50 MHZ, así que tengo el tiempo suficiente para hacer una lectura completa.

Supongo que estoy haciendo algo terriblemente, terriblemente mal. ¿Cómo se implementa normalmente este lienzo de dibujo en VHDL?

Lo más cercano que pude encontrar es usar un esquema de color 2-3-3 (R-G-B) para recuperar cada píxel y escribir en el ram del lienzo durante el tiempo VGA del "porche" (blanco). Esto significa que en cada uno de los relojes de 25 mhz solo puedo actualizar el 15% de la pantalla y de alguna manera necesito que mi circuito esté al tanto de qué 15% se está actualizando.

No puedo descubrir cómo usar el búfer doble, porque no puedo escribir cómo escribir datos en la memoria mientras leo. ¿Hay una manera de evitar golpear el protocolo de bits? ¿Cómo lo hace este chico?

    
pregunta Mikhail

2 respuestas

3

Un par de enfoques que pueden ser útiles para algunos estilos de visualización es dividir el panel de visualización en mosaicos, y

  1. restringe cada mosaico a usar un pequeño conjunto de colores, lo que permite el uso de menos de 8 bits por píxel, o
  2. use un byte o dos de cada mosaico para seleccionar una ubicación desde la cual leer datos de mapa de bits.
El primer enfoque podría reducir la velocidad a la que los datos debían leerse desde la memoria de la pantalla. Por ejemplo, si uno usara mosaicos que fueran 16x16 y cada uno tuviera cuatro colores elegidos de un conjunto de 256, entonces, sin usar ninguna RAM adicional en el FPGA, uno podría reducir el número de lecturas de memoria por 16 píxeles a ocho (cuatro valores de color, más cuatro bytes para el mapa de bits). Si se agregaron 160 bytes de búfer / RAM (*) al FPGA, se podría reducir la cantidad de lecturas de memoria por 16 píxeles a cuatro, utilizando 160 lecturas adicionales cada 16 líneas de escaneo para leer el siguiente conjunto de colores de mosaico. Si uno quisiera 16 colores por mosaico, el segundo enfoque requeriría 640 bytes adicionales de RAM, a menos que uno pusiera algunas restricciones en el número de paletas diferentes que podrían existir en una línea.

El segundo enfoque probablemente aumentaría en lugar de reducir el ancho de banda total de memoria requerido para producir una pantalla, pero reduciría la cantidad de memoria que tendría que actualizarse para cambiar la pantalla; uno podría cambiar un byte o dos para actualizar Un área de 8x8 o 16x16 de la pantalla. Dependiendo de lo que intente mostrar, puede ser útil usar este tipo de enfoque para usar un dispositivo de memoria para mantener las formas de mosaico y otro para mantener la selección de mosaico. Uno podría, por ejemplo, usar una memoria RAM rápida de 32Kx8 para mantener un par de mapas de mosaicos de 80x60 con dos bytes por mosaico. Si el FPGA no tuviera ningún búfer, tendría que leer un byte cada cuatro píxeles; incluso con una memoria RAM estática de 40 ns, eso dejaría mucho tiempo para que la CPU actualice la pantalla (una pantalla completa solo tendría 9600 bytes). El ancho de banda de la memoria para leer las formas de mosaico no sería mejor de lo que es ahora, pero esa parte de la memoria no tendría que actualizarse.

Por cierto, si uno no deseara agregar una memoria RAM de 32Kx8 pero podría agregar 320 bytes de búfer / RAM (**) al FPGA, se podría usar un enfoque de mapa de mosaico pero tener la CPU o la fuente DMA 160 bytes a la pantalla cada 8 líneas de escaneo. Eso supondría una carga para el controlador incluso cuando no cambiara nada en la pantalla, pero podría simplificar los circuitos.

(*) El búfer podría implementarse como RAM, o como una secuencia de 32 registros de desplazamiento de 40 bits más una pequeña lógica de control.

(**) El búfer podría implementarse como dos RAM de 160 bytes, o como dos grupos de dieciséis registros de desplazamiento de 80 bits.

    
respondido por el supercat
5

Los Sprites normalmente no se hacen con un buffer de cuadro (como entiendo la palabra). En su lugar, comparas las coordenadas x e y con xmin, ymin y xmax, ymax del sprite. Si la posición de escaneo actual cae dentro del sprite, imprima el color relevante de la memoria del sprite.

Si está intentando mostrar un búfer de cuadros, confíe. Este fue mi primer gran proyecto de FPGA. SDRAM no debería ser un problema a 100MHz (lo hice por primera vez hace una década, y el silicio es más rápido ahora), así que multiplique su reloj de 50MHz. Escribir tu propio controlador será educativo :)

Eso te da bastante ancho de banda para jugar, luego puedes duplicar el búfer, no hay problema. 60 Hz VGA necesita un promedio de 18Mpixels / sec. Si tiene un dispositivo de 16 bits de ancho, tiene 200 MBytes / seg de ancho de banda máximo. Incluso si solo logras ser 50% eficiente (lo que debería ser factible) eso es 100Mpixels / sec @ 16 bits por pixel o 50Mpixels / sec @ 32bits por pixel.

Por ejemplo, puede ser que su RAM necesite 60 ns para configurar una lectura, pero después de eso puede repartir 8 palabras en 80 ns, es decir, 8 bytes en ~ 140ns. Si puede hacer que su RAM haga ráfagas más largas, eso ayudaría a amortizar el costo de configurar la lectura.

Según su comentario de que se trata de una memoria RAM de un byte, eso es un poco más de 50 MBytes / seg, solo 16Mpixels / seg @ 24 bits por píxel :( Usted simplemente no tiene suficiente ancho de banda para hacer una visualización de color verdadero, incluso en VGA. Podría hacer 8 bits por píxel con bastante facilidad, pero eso es solo 2 o 3 bits por color, lo que puede estar bien para su aplicación, no lo sé. O podría hacer una tabla de búsqueda de 256 colores como en el antiguo días: después de leer el búfer de cuadros, se usa el valor para buscar en un reloj RAM interno para obtener los 24 bits (o 18 bits, que cabrían bien en un BRAM) de color para enviarlos al monitor.

El búfer doble aún funciona:

Muestra un cuadro desde la dirección 0 (solo lee todos los píxeles, pausando las lecturas durante los intervalos de borrado).

Escriba su siguiente marco en otra ubicación. Para este búfer doble, su controlador DRAM tendrá que priorizar entre las demandas de los canales de lectura y escritura. Sugerencia, priorice las lecturas ya que son críticas en el tiempo :)

    
respondido por el Martin Thompson

Lea otras preguntas en las etiquetas

Comentarios Recientes

Leer el LED5CCW parecía estar bien. El tiempo de lectura de 1.008 ms fue ligeramente mayor que las pruebas de lectura allí. Establecer un 6 y realizar la calibración de fábrica con ProGate provocó las siguientes lecturas de temperatura: las anomalías vinculadas a los LED descritos aquí parecen bastante raras: se puede atribuir a que las mediciones realizadas en la fuente de alimentación de la PSU y los controladores anteriores no están en línea. ¡Un buen motor funcionó bien en el ProGate! Conclusión: puede... Lees verder