Prueba de cómo quedaría una ULA implementada en una FPGA

[mcleod_ideafix]

Hace poco que estuve en Madrid recibiendo un curso sobre diseño de hardware para procesado de imagen usando FPGA. En el curso, en lugar de usar VHDL o Verilog, como lenguajes de descripción de hardware, se usó una especie de C con extensiones, llamado "Handel-C". Las extensiones son para manejar el paralelismo inherente a los diseños hardware.

Este fin de semana tenía que preparar una charla a mis compañeros de departamento sobre cómo nos había ido en el curso, y para prepararla, he cogido una de las plaquitas FPGA que usamos en las clases de Informática Industrial, en la Escuela Politécnica Superior de la Universidad de Sevilla, una Basys de Digilent, y he conseguido que el compilador de Handel-C cree descripciones compatibles con la misma.

Así, he podido usar la salida VGA de esta plaquita y he escrito un generador simple de sincronismos para el modo 640x480 de la VGA, y un contador de píxeles. Con eso como base, he escrito un módulo que remeda (en parte) el comportamiento de la ULA del Spectrum, en las tareas de lectura de la RAM de video y generación de la imagen.

La temporización no es la misma que en el Spectrum por la sencilla razón de que el reloj de la FPGA va a 25MHz, en lugar de los 14MHz de la ULA original. Además, la temporización está ligada a las señales VGA, que ocurren a una velocidad bastante distinta que la señal de TV.

El resultado lo he subido a Youtube, aquí:
http://www.youtube.com/watch?v=ronoUVZ3LRo

La FPGA tiene varias máquinas de estado funcionando. La principal es la que genera el video como señal VGA. En paralelo con ésta, hay otra, más simple, que primero inicializa la zona de atributos con la combinación paper 7, ink 0, y luego se mete en un bucle que rellena toda la memoria de pantalla con valores correlativos. Para que el relleno no aparezca como instantáneo he metido en cada vuelta del bucle, un retardo de 32768 ciclos de reloj. Si no lo hiciera, cada byte de la memoria de pantalla se escribiría en cada ciclo de reloj del reloj de 25MHz, lo que supone que la pantalla completa se llenaría en 276 microsegundos (ya quisiéramos que el Z80 fuera capaz de rellenar memoria a este ritmo!! )

Para comparar el comportamiento, y sobre todo los resultados, he ejecutado un pequeño programa en BASIC que hace el mismo relleno. He usado Spectaculator, y para que se viera a una velocidad "decente", aquí he tenido que hacer lo contrario: acelerar la CPU del Z80 emulado en Spectaculator hasta los 50MHz, para que no tarde demasiado en el relleno.

[radastan]

Un buen paso adelante, pero la pregunta es... imaginemos que se consigue una implementación completa de la ULA, ¿cuánto cuesta la FPGA?

[Z80user]

Mas que cuanto cuesta la FPGA, es cuanto cuesta una placa que permita meterla dentro, tu tienes un T-REX, que es algo similar, si no lo mismo, que emula un Amstrad

25/14.3818 = 1.75, si hicieramos un reloj apartir de esa señal, serian 3 medios ciclos a nivel alto y 4 a nivel bajo, para tener una frecuencia acorde.
Contando los flancos, o niveles 50/14,31838 = 3.5 mas o menos, o de forma mas comun 1.5 ciclos a un nivel y 2 ciclos al otro

Para simular mas perfectamente, habria que habilitar un buffer de la linea que esta escribiendo en pantalla, pues en pantalla se dibujaria la linea al doble de la velocidad real, al menos para que al pintar la 2 parte de la linea, al tener el doble de resolucion, fuese a la velocidad correspondiente.
Y ya para rizar el rizo, que leyese lo que habria en el otro scan que requeriria mas memoria para manejar esto.

Usar una pantalla de 640*480@100 Hz, aunque hay que duplicarlo TODO frecuencia de refresco, y resolucion del Spectrum *2, no se si se veria un 640*480@50 Hz que creo que seria el caso ideal. Mire en una pagina velocidades de refresco estandard para las distintas resoluciones.

La frecuencia del cristal o generador de frecuencia acoplado a la FPGA determina mucho, tambien la forma y tipo de la memoria que tenga a manejar
ya hay FPGA con DDR y DDR2 medianamente baratitas, pero creo que requeririan un cambio de cristal, para funcionar perfectamente para esto.
Vi una con DDR2 que tiene un cristal a 133MHz y otro a 50MHz, aunque no se si el de 133 se puede utilizar, o solo el de 50, o si necesitaria de un generador externo, para obtener dicha frecuencia, por lo que aun no tengo decidido que coger.
Lo que no se esactamente es como hay que leer una memoria, ya que los memorias, necesitan varios ciclos, para poder acceder a una direccion de memoria en concreto CAS + CAS2RAS + RAS + precharge ...

[mcleod_ideafix]

Un buen paso adelante, pero la pregunta es... imaginemos que se consigue una implementación completa de la ULA, ¿cuánto cuesta la FPGA?

Cara (para lo que nos interesa). La FPGA aquí me sirve como banco de pruebas, lo mismo que el lenguaje usado (por eso es un PoC: prueba de concepto). La ULA es menester implementarla en una CPLD, no en una FPGA, ya que las primeras son más baratas, y además no se pierde la configuración cuando quitas la alimentación (las FPGA's son volátiles y necesitan una pequeña ROM de la que cargar su configuración cuando se les da alimentación).

[radastan]

OK, entonces FPGA para pruebas y CPLD para resultado.

Es que me tengo que poner al día en estos temas, se mucho de microcontroladores y microprocesadores pero poco de FPGA y CPLD.

[mcleod_ideafix]

OK, entonces FPGA para pruebas y CPLD para resultado.

Para la ULA, sí, ya que es un circuito muy sencillo, y usar toda una FPGA sólo para la ULA sería poco menos que matar moscas a cañonazos. Chris Smith la tiene implementada en una 95144 de Xilinx, que es una CPLD más bien pequeñita.

En la industria, el ciclo de desarollo es: FPGA "tocha" para pruebas (Virtex), y ASIC o FPGA quizás menos "tocha" para resultados.

[radastan]

¿Algún modelo de FPGA o kit que sea baratito para empezar a hacer experimentos? no pretendo hacer nada serio de momento, eso sólo para trastear y ver como va el tema, cuanto más barato mejor.

[mcleod_ideafix]

¿Algún modelo de FPGA o kit que sea baratito para empezar a hacer experimentos? no pretendo hacer nada serio de momento, eso sólo para trastear y ver como va el tema, cuanto más barato mejor.

La Basys esta que estoy usando es lo más barato que conozco.
http://shop.trenz-electronic.de/catalog ... cts_id=598

Anda! Mira, ¿qué te parece esto? Encapsulado de 40 pines, tolerante a 5V,... ¿estamos viendo un sistema de prototipado rápido para la ULA Plus?
http://shop.trenz-electronic.de/catalog ... cts_id=634

[mcleod_ideafix]

He modificado un poquito la configuración de la FPGA para que la RAM de video sea en realidad una ROM con una imagen ya grabada. De esa forma, precargando archivos SCR durante la síntesis del circuito, puedo ver cómo queda una pantalla.

He probado con estas imágenes.Son fotos directas al monitor LCD. La verdad es que creo que ha quedado bien

[radastan]

Mc Leod, lo has bordado.

Se me ocurre que usando una CPLD pequeñita se puede hacer un controlador de vídeo sencillo, algo que soporte 256x256 de resolución sin color y que cargue los bits desde una RAM de 8K. ¿Lo ves factible o crees que no hace falta una CPLD? Al fin y al cabo es sólo cargar secuencialmente los bytes de la VRAM e irlos transmitiendo bit a bit por vídeo compuesto, al ser en blanco y negro la señal es muy simple.

Es que es lo único que me falta para hacerme mi 8 bits personalizado y comenzar a ensamblarlo todo.

[mcleod_ideafix]

Mc Leod, lo has bordado.

Se me ocurre que usando una CPLD pequeñita se puede hacer un controlador de vídeo sencillo, algo que soporte 256x256 de resolución sin color y que cargue los bits desde una RAM de 8K. ¿Lo ves factible o crees que no hace falta una CPLD? Al fin y al cabo es sólo cargar secuencialmente los bytes de la VRAM e irlos transmitiendo bit a bit por vídeo compuesto, al ser en blanco y negro la señal es muy simple.

Claro que es factible. Sólo hay que ver cuán "pequelita" quieres que sea esa CPLD y qué prestaciones quieres que tenga tu controlador. Con una XC95144 se puede hacer una ULA, así que a partir de ahí... Las CPLD's más pequeñas que conozco son las XC9536. La serie XC95 de Xilinx es la más usada, y puede manejar 5V sin problemas. Es la serie que se usa por ejemplo en la lógica del Spectranet, la de la ZXMMC, la interfaz de ratón Kempston, y la que usa Chris Smith para su reemplazo de ULA. El número que viene detrás de XC95 indica cuántos biestables puedes usar en esa CPLD. XC9536 es, por ejemplo, una CPLD con 36 biestables.

256x256 te permite construir la dirección de pixel de forma muy sencilla, por lo que no necesitarás ni mucha lógica ni muchos biestables. Lo suyo es hacer el diseño en el ISE de Xilinx, y a la hora de sintetizar, ir probando a ver en qué CPLD te cabría el diseño: usas una grande para las pruebas (o una FPGA) y luego, para "producción", escoges la más pequeña que pueda contener el diseño...

[radastan]

¿Y usar un microcontrolador en vez de una PLD? lo digo porque los Atmel de 8 bits valen cuatro duros, y hay un modelo que permite acceder a SRAM externa (el ATMEGA8515):

http://www.atmel.com/dyn/products/product_card.asp?part_id=2006

Aunque sea una barbaridad se puede programar por software y leer los 8KB de VRAM de forma externa, incluso nos podemos permitir que el microcontrolador haga algunas vilguerías más adelante como tener otros modos de vídeo o hacer scroll sin intervención de la CPU. ¿Qué te parece? ¿mejor esta solución o la ves más complicada para empezar por algo sencillo?

[jzx]

No es tan barbaridad.

Un día buscando este tipo de cosas vi esto, precisamente con un avr:
http://tinyvga.com/avr-sdram-vga

El problema es que no creo que sea fácil de adaptar al z80, ya que el truco consiste en que la propia memoria larga los datos, no creo que sea fácil de hacer la contención (para usarlo como sustituto de la ula). En lo que se muestra en la página, es el propio avr el que crea la imagen, o se le manda por puerto serie.

Otra cosa que alguna vez he pensado, con un avr, que son rápidos, es que aunque no tenga acceso a memoria exterior, controlando los puertos (si da la velocidad claro) se podría simular. Poner dirección-activar /CS-leer dato-quitar dirección.... Parece lento,pero creo que los avr con acceso a memoria exterior meten ciclos de espera, y en todo caso las intrucciones de lectura en sram interna ya son más lentas que las normales (3 ciclos creo)

También hay por ahí alguien que ha hecho todo un ordenador de 8 bits con un avr, con modo texto (más dificil, pero le cabe en la memoria interna) e incluso intérprete de basic. http://www.jcwolfram.de/projekte/avr/ch ... 2/main.php

[mcleod_ideafix]

¿Y usar un microcontrolador en vez de una PLD?

Factible. Yo mismo he usado un pequeño microcontrolador de 8 bits para hacer un controlador VGA, y además os lo enseñé:
viewtopic.php?f=8&t=777&start=1

Lo que pasa es que creo que el software que tendrías que meterle al micro sería más complejo de hacer que el que se le mete a una CPLD. Para que te hagas una idea: el generador de video "estilo ULA" que he enseñado lo he escrito en una tarde. El controlador VGA que hay en el otro post, me llevó varias semanas.

La principal dificultad es que en el caso de la versión "por microcontrolador", tienes que programar en ensamblador, y afinando temporizaciones al ciclo, pero afinando me refiero a que, si en tu programa hay una bifurcación, y una de las ramas consume N ciclos, la otra rama de la bifurcación también debe consumir N ciclos. Si no se cumple a rajatabla esto, el resultado es una imagen distorsionada.

La programación de un microcontrolador es esencialmente, secuencial. La de una CPLD es esencialmente paralela. Complicar el modo de video, o el número de colores, no merma la velocidad de operación de la CPLD, ya que todo se "ejecuta" en paralelo. Sin embargo, la misma complicación en un microcontrolador puede suponer rediseñar de nuevo la parte de generación de video, o tener que irte a un microcontrolador más rápido, o sencillamente, ser inviable por las restricciones temporales.

[mcleod_ideafix]

El problema es que no creo que sea fácil de adaptar al z80, ya que el truco consiste en que la propia memoria larga los datos, no creo que sea fácil de hacer la contención (para usarlo como sustituto de la ula).

No creo que él esté interesado en usar un microcontrolador como sustituto de la ULA. Necesitaría seguramente un microcontrolador más caro que la CPLD que puede albergar esa ULA. Por otra parte, para lo que él quiere hacer, necesita usar memoria externa para poderla compartir con el procesador principal, a menos que implemente un sistema de acceso indirecto, por puertos, como hace el TMS9929 del MSX, en el cual la memoria no es directamente accesible por la CPU. En el diseño de controlador VGA que he puesto, la memoria que usa dicho controlador es interna al microcontrolador, por lo que el acceso exterior a la misma se hace desde un puerto SPI del propio microcontrolador.

Para implementar contención, lo más sencillo es enviar a la CPU una señal de WAIT justo antes de que el procesador de video lea la VRAM, y quitarla cuando haya terminado de realizar el acceso. El microcontrolador, mientras no esté accediendo a la memoria externa, deberá configurar los pines que use para la misma en modo de alta impedancia.