[Ipxs tiny pong] (frontón)

[Sergio Cuenca]

Hola a todos,

aprovecho que ya lo he compartido con @Juanmard para compartirlo también con el grupo.

Una mini-versión de pong resuelta con la librería IPXS para Alhambra. 

PD: ya sé que hay que subirlo al Github pero no puedo con mi vida

[Juanma Rico]

Buenas a todos/as,

¡Gracias de nuevo, Sergio!

Lo mismo digo, el día no me da... Ojalá uno pudiera estar haciendo "cositas" con las FPGAs todo el día y te pagaran por ello... pero no es mi caso... (por favor, que nadie se dedique a dar envidia, que os veo venir...jajajajaja).

Os pongo en antecedentes... La cuestión es que estaba adaptando el screen-pong con las bibliotecas de la colección iPXs de Sergio, se ha enterado (me ha subido el SAV... no sé para qué hablo por Twitter ... jajajajajaja) y muy gentilmente ha compartido su trabajo previo de un frontón conmigo y ahora con el grupo.

Iba a subir al github al menos el esquema de bloques en icestudio y la colección que estoy creando con los bloques, pero ahora lo voy a posponer hasta estudiar la info que ha proporcionado Sergio, por si veo que tengo que cambiar algún esquema mental...

Para los que tengan curiosidad... me he planteado la colección del juego del Pong por bloques (Display, Control, Sound y Dynamic), la biblioteca iPxs de Sergio está en la parte de visualización (Display). El aspecto del fichero principal es el siguiente:



El bloque del Pong (llamado PxsPong) es de tipo "Videogen" según la blioteca iPxs, es decir, toma un stream de las señales VGA obtenidas mediante el reloj del sistema y genera un stream de tipo RGB según las señales de control de entrada a dicho bloque (además de generar interernamente las señales de sonido y obtener una salida de buzzer) luego, este stream RGB, se descompone mediante otro bloque (representado en la imagen con un prisma y su arcoiris) en las señales RGB y sincronismos necesarios para conectar el monitor VGA.

Este gran bloque general lo he ido descomponiendo en otros bloques que serán los que finalmente (junto a ejemplos más sencillos) acaben siendo los bloques que queden en la colección del juego (ya con código Verilog incluido en un fichero aparte).

Por ejemplo, el interior del bloque PxsPong tiene el siguiente aspecto:



Como se ve, la imagen se forma con un fondo estático de tipo "Vidoegen" (PxsCourt) que dibuja el campo... y una cascada de bloques tipo "Overlay" (PxsScoreboard, PxsVerticalPlayers, PxsBall) que se ven modificados por las posiciones y parámetros calculados en el bloque de la dinámica del juego (el bloque del dibujo de engranajes).

Centrándonos en los bloques Pxs de tipo "Overlay", los he dividido aún más para que puedan ser utilizados y modificados desde icestudio sin tener que cambiar el código Verilog. Así por ejemplo, el bloque PxsScoreboard tiene este aspecto:



Que forma el marcador mediante otros dos bloques "Overlay" cascadeados y que representan un dígito en pantalla (bloque PxsNumber).
De esta forma, estableciendo su posición en pantalla, con este bloque se podría generar un número independiente del juego (lo incluiré como un ejemplo en la colección).

O en el caso del bloque PxsVerticalPlayers, que genera los jugadores en pantalla, no son más que dos jugadores superpuestos y tiene un aspecto como este:




Donde el tipo de jugador (la barrita desplazable según una posición de entrada) se puede definir mediante una constante conectada al bloque (PxsPlayer). De esta forma se podrían definir hasta cuatro tipos de jugadores (una por cada borde de pantalla: Left, Right, Top y Bottom), lo que da pie a hacer distintas pruebas y poder generar un "Pong extraño" de cuatro jugadores independientes que se pasaran la pelota de uno a otro sin más que cascadear los bloques básicos e incluir la dinámica y los controles correspondientes.... (¡Qué locura! Igual lo incluyo como ejemplo si entra en la FPGA... :-D). Cada bloque básico de la colección sí tiene ya su correspondiente fichero Verilog incluido y aparte. Por ejemplo en el caso del PxsPlayer tiene esta pinta:



Para que sea más fácil la comprensión y el funcionamiento de los bloques (y por tanto os animéis a modificarlos y a jugar con ellos) estoy haciendo ejemplos sencillos de prueba que incluiré en la colección, como muestra un par de ejemplos:





Bueno, eso es todo de momento... como digo dejad esto en "stand-by" hasta que me estudie el código del frontón de Sergio que igual me hace reinterpretar el esquema un poco (aún no estoy pensando en los recursos necesarios para todo esto e igual hay que "recortar" por algún lado porque no entre en la FPGA). Sea como fuere, si consigo que todo funcione o ya sea que encuentre limitaciones en el proyecto os lo digo... :))

Saludos
Juan Manuel Rico

[Juan Gonzalez Gomez]

Gracias Sergio!  Lo acabo de probar ahora y funciona muy bien!!  Es muy inspirador, para aprender a hacer este tipo de retro-juegos con sólo electrónica digital

Ahora subo un vídeo a twitter

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d64a5db0-7309-4699-8a69-d36ef8c56ca5%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Juanma Rico]

¡Gracias Juan!

He visto el vídeo y está genial.... el éxito del juego está en ese supiro que se te oye al perder el único punto que habías conseguido... jejejejejjeje ;)
¡Cuidado que engancha! ;)

Saludos
Juan Manuel Rico

[Juanma Rico]

Buenas a todas/os,

pues después de estudiar el código del frontón de Sergio, veo que seguimos más o menos la misma estrategia al utilizar los bloques de la colección iPxs, así que no he tenido que cambiar demasiado la mentalidad; de hecho casi no he tenido que cambiar la estructura de bloques en icestudio, así que perfecto, tiempo de desarrollo rentabilizado. :))

Ayer y esta mañana le he podido dedicar unas horas y la verdad es que es muy cómodo trabajar con los bloques Overlay sobre el stream RGB como hace Sergio, esto permite hacer muchas pruebas separando los bloques y luego cascadearlos y ver el resultado en pantalla. Además mi intención es dejar las pruebas como ejemplos de la colección para que os animéis a hacer variaciones del mismo... :)))

Si tenéis curiosidad por ver como van los progresos os dejo el último vídeo que he puesto en Twiter.

https://twitter.com/juanmard/status/975355216999649282https://twitter.com/juanmard/status/975373145141055488

Como véis la parte gráfica está prácticamente terminada y solo queda establecer claramente la parte de la dinámica (lo que véis moverse es una chapucilla rápida a base de relojes preescalados para poner a prueba la gráfica), el bloque del sonido (que siempre termina siendo lo último y no debería...) e intentar hacer un ADC para los controles con los potenciómetros de momento tendrá que ser con botones, estoy sintetizando en la pequeña TinyFPGA-B2 y por ahora (exceptuando el "problema" de que tengo que usar GNU/Linux) va bastante bien. Os dejo otro enlace para que veáis como le he adaptado el conector VGA... directamente sobre las resistencias... No necesita más... :))

https://twitter.com/juanmard/status/975005606959513600

Bueno, cuando lo tenga todo encapsulado en una colección (ejemplos y bloques nuevos que he creado para la colección iPxs) aviso y lo publico en github, pero si tenéis mucho SAV y no podéis aguantar a que lo encapsule, me avisáis que os mando un par de pruebas,... que yo sé lo que es el SAV en casa de suegra un domingo... jejejejejeje :))

Saludos
Juan Manuel Rico

[Juanma Rico]

¡Gracias Unai!

Ha pasado algo curioso... he recibido el correo en mi móvil y cuando he ido a contestarte en el grupo desde el PC... veo que tu mensaje está borrado (o por lo menos a mi me sale así).

Sea como fuere... me constesto a mí mismo con una copia de tu mensaje debajo para que no se pierdan para el grupo los enlaces que pusiste.
Espero te llegue mi contestación... :))

Empecemos... ¡Gracias por la parte que me toca!  :))

La verdad es que la biblioteca de Sergio está siendo muy inspiradora para mi, como igual de inspirador fue el primer acercamiento a la VGA con el MosterLED de Obijuan y el Space Invaders de Roland (otra cosa que tengo en el TODO para probar... discúlpame Roland, termino el Pong y lo hago... :)) )

Además... cuanto más investigo el código de Sergio más me doy cuenta del mérito que tiene... no tuvo que ser fácil integrar mi chapuza de código VGA para hacerlo funcionar en su estructura de bloques... jejejejeje (también te pido disculpas a ti Sergio por esa put... :)) )

La cuestión es que estoy empezando a adaptar el Pong a su estructura de bloques y no tiene fin... se me ocurren un montón de cosas por probar y todas funcionan sin problemas, tan bien funciona toda la biblioteca que no sé cuando parar de dar funcionalidad y generalidad a un bloque... tanto es así que terminaré haciendo una colección solo para el juego, eso seguro... jajajaja

Lo que me falla ahora son los bloques de la dinámica, mis escasos conocimientos en Verilog y la falta de pensamiento en síntesis de hardware, (vengo con tara en exceso de pensamiento secuencial...)  hacen que contadores y demás no se comporte como quiero que se comporte... y ahí estoy, pegándome contra las paredes... hasta que sale algo parecido y sigo... pero la cuestión es que superado, sí que se te va la cabeza a las antiguas "arcades" y te dan ganas de ponerle más color a la cosa. ;)

De momento voy a dejar el Pong un poco más en condiciones y apago el SAV de la VGA, a ver si después puedo investigar todos esos enlaces interesantes que pones. Ahora que dispongo de más LUTs tengo pendiente probar una versión más potente del Lattuino de Salvador (me quedé con las ganas) y el mini RISCV que nos enlazaste... lo de icestudio lo tengo un poco abandonado, pero en algún momento lo tendré que retomar.

Simplemente agradecerte que te pases por aquí de vez en cuando.
Saludos
Juan Manuel Rico


>El mar., 20 mar. 2018 18:26, 1138-4EB <umarti...@ikasle.ehu.es> escribió:

Muchas felicidades Juanma y Sergio. ¡Tiene un aspecto impresionante!

Me ha recordado a estas charlas sobre "preservación" de videojuegos arcade (recreativas). Como estaban hechos en hardware, tenían sistemas de protección y efectos que hoy resultan muy curiosos.

 https://www.youtube.com/watch?v=vg7LPcFUxg8
 https://www.youtube.com/watch?v=LiRIc0LDlu4

[Jose Pico]

A mi también me aparece el mensaje de Unai como borrado.

Saludos y ánimo a todos, seguid así.

Gracias

[Unai Martinez]

Hola Juanma y Jose!

Efectivamente, hay algún problema con este grupo y es que hay mensajes que aparecen como borrados sin razón evidente. Me ha pasado anteriormente tanto con mensajes que he enviado yo, como al visitar hilos y ver que en una conversación de 10-15 mensajes faltaban 2-3. Supongo que hay algún filtro que actúa después de que el email se haya reenviado a la lista pero antes de visualizarlo en la web. Y es especialmente curioso, porque el mensaje lo escribí desde groups.google.com (no desde gmail, ni desde un cliente de correo), lo cual quiere decir que el mismo sistema que aceptó enviarlo después decide ocultarlo/borrarlo. Estaría bien saber/conocer si hay algún tipo de filtro de spam que podamos estar haciendo saltar de alguna manera.

Sobre la VGA en si, por no desviar el hilo más de la cuenta, yo en su día implemente un módulo en VHDL para graficar las entradas/salidas de un PID y para dibujar "patrones de ajuste":

https://a.fsdn.com/con/app/proj/ohkis/screenshots/anie_infografia.png (pare superior derecha)
https://vimeo.com/64035600 (min 0:20 y 2:24, respectivamente)
http://sourceforge.net/projects/ohkis/files/anie/doc/Karrera%20Amaierako%20Proiektua.pdf/download (Figuras 1.33 en la página 1-61 (78/259) y 1.35 en la página 1-63 (80/259)).

La cuestión es que utilicé un reloj de 25 MHz para generar una resolución de 640x480 y todos los "cálculos" para decidir el color se hacían al vuelo. Puedes ver en la Figura 1.35 que hay varios bloques de comparación y puertas lógicas entre los registros y la salida, que es la señal "v" de la parte inferior. Esto provocaba que a veces las líneas aparecieran "corridas" en la pantalla, fruto de la latencia/retardo de la señal a través de esas puertas y la consiguiente descompensación con respecto a las señales de sincronía. Hoy en día sé que eso se resolvería simplemente registrando "v" a la salida. Pero me sirve como excusa para plantearte las siguientes dudas:

- ¿Qué resolución estáis generando y qué reloj estáis utilizando para ello? ¿Qué otras resoluciones tenéis pensado utilizar (si es que lo habéis planteado)?
- ¿Generáis las señales de "color" directamente a partir de los contadores de fila/columna o utilizáis algún buffer intermedio? En la Figura 1.35 puedes ver que utilicé un buffer (un bloque RAM) para separar funcionalmente la parte del circuito que generaba qué había que dibujar, y por otro lado la parte que se encargaba de generar las señales de color VGA. Pero en lugar de hacer un buffer de 640x480, lo hice de 640x6 (una fila por cada línea a dibujar), porque en la FPGA que utilicé no había BRAM sufficiente para mantener un buffer de toda la pantalla. Supongo que las ICE estarán justitas también en este sentido.
- ¿Habéis tenido problemas con algún monitor quisquilloso al que no le gusten las señales de sincronía que estáis generando o las resistencias que estáis utilizando para convertir las señales digitales en "analógicas"?

Como bonus, me quedó por probar la generación de más de ocho colores. Utilizando una señal de reloj de 50MHz se podría generar una paleta de 8*8=64 colores. Pero para eso es necesario que el circuito sintetizado sea capaz de ejecutarse a esa frecuencia. ¿Qué frecuencia máxima de ejecución estás obteniendo en la síntesis de vuestros circuitos?

Sobre los contadores y la dificultad para plasmar en hardware algunos algoritmos "secuenciales", si te atascas mucho con algún caso, déjate un mensaje por aquí y vemos si podemos repensarlo de manera más "hardware-friendly".

Con respecto al SAV y las otras fieras, a partir del ejemplo InBit con Vue.js y golang que estuvimos comentando, tengo en el cajón el experimento adjunto. Básicamente, el objetivo de excusa es poder leer un VCD/GHW/FST/CSV y convertirlo a WaveJSON o tikz-timing, para generar SVGs o PDFs, respectivamente. Es una librería con los algoritmos de conversión, una aplicación CLI que utiliza la librería, y un app+backend que utiliza la misma librería. Por el momento en lo que respecta a la GUI, es como el editor de WaveDrom (basado en nodejs), pero en versión cliente-servidor siendo el backend golang, y permitiendo la edición de múltiples waveforms al mismo tiempo (como se ve en el GIF dtd). De hecho, el experimento principal es proveer una "experiencia de escritorio" en la web. Por "experiencia de escritorio" me refiero a tener múltiples "ventanas" y poder moverlas/redimensionarlas como ventanas (ver GIF dtd_windows); o mostrarlas como pestañas (mostrado en el GIF dtd); o usar una librería de "tiling". Y hacerlo recursivo (escritorio "virtual" dentro de una ventana, dentro de otra ventana... hasta que casque). Después añadir la librería xterm (como filemanager) y poder: editar verilog con codemirror (una ventana), ejecutar yosys e iverilog (en otra ventana), y ver el resultado de la simulación en SVG (en una tercera ventana). Idealmente, icestudio podría ser una ventana más, de forma que arrancando una sola imagen docker en segundo plano y accediendo a través de una web (sea de forma local o remota) se tenga acceso a las últimas versiones actualizadas y probadas de icestudio, apio, terminales, visualización de las simulaciones, etc. Algún día ;). Espero que te sea inspirador, mientras tanto.

Un saludo y muchos ánimos con ese Pong!

[Juanma Rico]

Buenas Unai, te respondo entre líneas,

El viernes, 23 de marzo de 2018, 3:48:37 (UTC+1), 1138-4EB escribió:

Hola Juanma y Jose!

Efectivamente, hay algún problema con este grupo y es que hay mensajes que aparecen como borrados sin razón evidente. Me ha pasado anteriormente tanto con mensajes que he enviado yo, como al visitar hilos y ver que en una conversación de 10-15 mensajes faltaban 2-3. Supongo que hay algún filtro que actúa después de que el email se haya reenviado a la lista pero antes de visualizarlo en la web. Y es especialmente curioso, porque el mensaje lo escribí desde groups.google.com (no desde gmail, ni desde un cliente de correo), lo cual quiere decir que el mismo sistema que aceptó enviarlo después decide ocultarlo/borrarlo. Estaría bien saber/conocer si hay algún tipo de filtro de spam que podamos estar haciendo saltar de alguna manera.

Sobre la VGA en si, por no desviar el hilo más de la cuenta, yo en su día implemente un módulo en VHDL para graficar las entradas/salidas de un PID y para dibujar "patrones de ajuste":

https://a.fsdn.com/con/app/proj/ohkis/screenshots/anie_infografia.png (pare superior derecha)
https://vimeo.com/64035600 (min 0:20 y 2:24, respectivamente)
http://sourceforge.net/projects/ohkis/files/anie/doc/Karrera%20Amaierako%20Proiektua.pdf/download (Figuras 1.33 en la página 1-61 (78/259) y 1.35 en la página 1-63 (80/259)).

La cuestión es que utilicé un reloj de 25 MHz para generar una resolución de 640x480 y todos los "cálculos" para decidir el color se hacían al vuelo. Puedes ver en la Figura 1.35 que hay varios bloques de comparación y puertas lógicas entre los registros y la salida, que es la señal "v" de la parte inferior. Esto provocaba que a veces las líneas aparecieran "corridas" en la pantalla, fruto de la latencia/retardo de la señal a través de esas puertas y la consiguiente descompensación con respecto a las señales de sincronía. Hoy en día sé que eso se resolvería simplemente registrando "v" a la salida. Pero me sirve como excusa para plantearte las siguientes dudas:

Vamos allá, a ver si puedo responderte... Que sean fáciles... :)
 

- ¿Qué resolución estáis generando y qué reloj estáis utilizando para ello?

Esa me la sé... :))
A ver,... el primer controlador VGA que hice fue basándome en el de Roland. Me lo tuve que trabajar (no fue un simple copy-paste sin entender) porque Roland usaba una frecuencia de 85Hz de cuadro, pero mi monitor cutre de pruebas no daba para esa frecuencia, así que tuve que modificar y modificar hasta que di con una frecuencia apropiada (la resolución siempre ha sido 640x480). Los parámetros de las frecuencias que encontraba por Internet eran basándose en, precisamente, un reloj de 25Mhz, pero la icezum Alhambra dispone de un reloj del sistema de 12Mhz, con estos 12Mhz al introducirlos en el PLL para obtener una frecuencia de reloj más alta para los sincronismos, unas veces no daba una frecuencia exacta y otras veces no era la estándar que "entendía" mi monitor, hasta que descubrí que los 72Hz de cuadro también estaban dentro del estándar, con 12Mhz se obtenía la frecuencia de pixel exacta (31.5Mhz) para esa resolución y mi monitor se los comía con papas y funcionaba (y parece que en muchos más monitores por las pruebas que se han estado haciendo, con lo que realmente era un estándar, perdido y desconocido por la mayoría pero un estándar).

El problema me surge con la TinyFPGA, usa un reloj de 16Mhz pero afortunadamente el PLL de la  iCE40 también da una frecuencia exacta de pixel para este reloj, con lo que únicamente se necesita cambiar un parámetro en la definición del módulo del PLL... no sé como lo haré con el Pong porque me gustaría que al menos funcionara en ambas placas con distintos relojes... aún estoy pensando.

Bueno me enrollo.. se me está pegando de ti... eso es que cada vez sé más de estos temas... jajajajajaja

La respuesta simple y concreta es: Una controladora VGA de 640x480@72Hz con 3 bits de profundidad de color, usando el PLL a 12Mhz y 16Mhz para ambas placas. :))
 

¿Qué otras resoluciones tenéis pensado utilizar (si es que lo habéis planteado)?

Pues me dio tanta batalla encontrar una resolución y una frecuencia que funcionara en mi monitor que no me he planteado volver a esa guerra, para mis pruebas, que es lo que más me gusta, me vale con esta resolución, además, aumentar la resolución es aumentar los recursos necesarios... y de LUTs andamos excasos. Lo que sí me he planteado es aumentar la profundidad de color (unas cuantas resistencias más en el conector VGA o un DAC en condiciones), pero por ahora no lo veo esencial (el Pong usa dos colores).
 

- ¿Generáis las señales de "color" directamente a partir de los contadores de fila/columna o utilizáis algún buffer intermedio? En la Figura 1.35 puedes ver que utilicé un buffer (un bloque RAM) para separar funcionalmente la parte del circuito que generaba qué había que dibujar, y por otro lado la parte que se encargaba de generar las señales de color VGA. Pero en lugar de hacer un buffer de 640x480, lo hice de 640x6 (una fila por cada línea a dibujar), porque en la FPGA que utilicé no había BRAM sufficiente para mantener un buffer de toda la pantalla. Supongo que las ICE estarán justitas también en este sentido.

Directamente, nada de buffer. Mi planteamiento original era un bloque monolítico de controladora, entregaba una posición x, y del pixel actual que estaba escaneando en pantalla y según esta posición del punto, otro bloque se encargaba de "realimentar" el color en la propia controladora para que, finalmente, lo mostrara por el conector VGA y así se "hiciera realidad" en forma de color.

La estructura de Sergio Cuenca (a la que me estoy adaptando ahora) es distinta, usa un stream de señales VGA (VGAStr), un registro donde está la posición del pixel y las señales de sincronismo, este stream pasa por un bloque que genera el vídeo, éste se encarga de añadirle, según la posición marcada en el stream ,el color RGB (RGBStr) y es este stream RGB modificado el que se inyecta a otro bloque para generar las señales de salida al conector. Esta estructura es más lineal, más fácil de entender y sincronizar y permite cosas muy interesantes como multiplexar y superponer señales de vídeo (espero el concepto se vea claro en los ejemplos que estoy haciendo para la colección del Pong).

Sea como fuere la estructura que se utilice, actualmente no existe ningún tipo de buffer. Yo me lo planteé en su momento porque tenía problemas en los tiempos de realimentación, pero en la nueva estructura de Sergio no estoy teniendo estos tipos de problemas y por ahora funciona a las mil maravillas. :)

- ¿Habéis tenido problemas con algún monitor quisquilloso al que no le gusten las señales de sincronía que estáis generando o las resistencias que estáis utilizando para convertir las señales digitales en "analógicas"?

Por lo que yo sé ninguno... yo uso siempre el mismo, pero hay pruebas que ha hecho Obijuan y Sergio por ahí en sus charlas y por ahora ha funcionado siempre... no me ha llegado feedback negativo en ese sentido (si alguien tiene algo que declarar, que lo haga ahora o calle para siempre...). De hecho yo uso unas resistencias mayores de las que propuso Obijuan en su MosterLED y los colores parecen iguales... imagino que no seguirá el estándar Pantone de la colorimetría... pero bueno, para pruebas en plan "maker" sirven. :))
 

Como bonus, me quedó por probar la generación de más de ocho colores. Utilizando una señal de reloj de 50MHz se podría generar una paleta de 8*8=64 colores. Pero para eso es necesario que el circuito sintetizado sea capaz de ejecutarse a esa frecuencia. ¿Qué frecuencia máxima de ejecución estás obteniendo en la síntesis de vuestros circuitos?

Aquí no te llego a entender... Si no estoy equivocado y me extrañaría que tú lo estuvieras (imagino ha sido un lapsus) el número de colores no depende de la frecuencia de reloj, solo depende de la tensión de entrada a cada pin RGB, con tres resistencias consigues dos tensiones fijas según le pongas un uno o un cero en el pin de salida de la FPGA, por lo tanto son 2^3 = 8 colores distintos. Si necesitas más colores únicamente necesitas más bits de salida, realmente lo ideal es un convertidor digital-analógico que te de un rango de tensiones en los distintos pines, pero esto mismo se puede hacer con un divisor de tensión y una escalera de resistencias... no tiene nada que ver con la frecuencia ni con los sincronismos, que yo sepa... Con lo que no tienes que aumentar al doble la señal de reloj para obtener una paleta mayor.

Por otra parte la frecuencia máxima de ejecución no la he calculado... sé que se puede hacer con el icetime del proyecto icestorm pero no lo he hecho, la verdad.

Sobre los contadores y la dificultad para plasmar en hardware algunos algoritmos "secuenciales", si te atascas mucho con algún caso, déjate un mensaje por aquí y vemos si podemos repensarlo de manera más "hardware-friendly".

Perfecto, lo pensé... pero el SAV a veces hace que no pueda esperar la respuesta. Tengo un tiempo muy limitado y a rachas para dedicarle a las FPGA.
Pero me lo apunto pra una próxima vez... al tercer cabezazo lo hago. :))
 

Con respecto al SAV y las otras fieras, a partir del ejemplo InBit con Vue.js y golang que estuvimos comentando, tengo en el cajón el experimento adjunto. Básicamente, el objetivo de excusa es poder leer un VCD/GHW/FST/CSV y convertirlo a WaveJSON o tikz-timing, para generar SVGs o PDFs, respectivamente. Es una librería con los algoritmos de conversión, una aplicación CLI que utiliza la librería, y un app+backend que utiliza la misma librería. Por el momento en lo que respecta a la GUI, es como el editor de WaveDrom (basado en nodejs), pero en versión cliente-servidor siendo el backend golang, y permitiendo la edición de múltiples waveforms al mismo tiempo (como se ve en el GIF dtd). De hecho, el experimento principal es proveer una "experiencia de escritorio" en la web. Por "experiencia de escritorio" me refiero a tener múltiples "ventanas" y poder moverlas/redimensionarlas como ventanas (ver GIF dtd_windows); o mostrarlas como pestañas (mostrado en el GIF dtd); o usar una librería de "tiling". Y hacerlo recursivo (escritorio "virtual" dentro de una ventana, dentro de otra ventana... hasta que casque). Después añadir la librería xterm (como filemanager) y poder: editar verilog con codemirror (una ventana), ejecutar yosys e iverilog (en otra ventana), y ver el resultado de la simulación en SVG (en una tercera ventana). Idealmente, icestudio podría ser una ventana más, de forma que arrancando una sola imagen docker en segundo plano y accediendo a través de una web (sea de forma local o remota) se tenga acceso a las últimas versiones actualizadas y probadas de icestudio, apio, terminales, visualización de las simulaciones, etc. Algún día ;). Espero que te sea inspirador, mientras tanto.

jajajajajajajaja, un mes necesito para entender mínimamente lo que me dices... por ahora "paso" un poco de pelearme más con el icestudio, lo uso y punto (al final se consigue lo que creo que se pretende con esta forma de organizar el proyecto) , de vez en cuando me vuelve el SAV para añadir funcionalidad o corregir algún error que veo pudiera ser fácil de corregir,... me pongo con el Node.js y en seguida lo tengo que dejar, casi que entonces es cuando me dan ganas de programarlo desde cero en C/C++... pero no es a lo que quiero dedicar el poco tiempo del que dispongo (he programado muchos proyectos en C/C++ y casi que aborrezco empezar un proyecto nuevo desde cero), así que nada... ahí se queda, sin poder aportar nada en ese sentido.

Pena me da porque me gusta la herramienta en sí, pero es imposible abarcarla en tan poco tiempo disponible con una curva de aprendizaje tan pronunciada. Pero bueno... motivos habrá para que así sea. Espero estar equivocado, no sea un error de planteamiento y tengamos icestudio por muchos años.

Un saludo y muchos ánimos con ese Pong!

¡Gracias!

Saludos
Juan Manuel Rico

[Juanma Rico]

Buenas a todos/as,

Ya está la adaptación del screen-pong a las bibliotecas iPxs de la colección de Sergio. Quedan algunos detalles, pero ya es jugable con botones y suena.
Aquí tenéis un vídeo (el sonido deja mucho que desear... imagino que es cosa de mi móvil al grabar, os aseguro que en directo no suena tan mal).

https://twitter.com/juanmard/status/977478560549097472

Queda por sustituir el control de botones por unos potenciómetros para los mandos, en la TinyFPGA no es tan fácil como en la icezum Alhambra porque no tenemos un ADC integrado, con lo que hay que poner componentes externos. También quiero poner ejemplos y los bloques utilizados en una colección para que os sea más fácil utilizarlo desde icestudio y quién sabe, igual utilizando los bloques del Pong podéis generar vuestro propio tipo de juego. :)

Finalmente la tarjeta de sonido la he dejado en lo más básico, son tres tonos distintos (ping, pong y goal) generados con tres bloques de preescalado y unas puertas. He utilizado como amplificador de sonido los propios altavoces del monitor, con lo que los componentes externos que he tenido que añadir son mínimos.
Aquí tenéis unos twitts con los bloques nuevos.

https://twitter.com/juanmrd/status/977489743725424640https://twitter.com/juanmard/status/977489743725424640

Espero tener tiempo para ordenarlo todo y dejarlo a vuestra disposición en github.

Saludos
Juan Manuel Rico

[Jose Pico]

Una curiosidad.

Si utilizas un adaptador vga-dvi se supone que se podrá ver en un monitor mas moderno?

Saludos

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/DOEzwX4x5aY/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/da56349e-8f88-4eb5-aea1-799ca7269e49%40googlegroups.com.

[Juanma Rico]

Pues debería,... las señales de sincronismo están ahí, las de RGB también, todas parecen ser un estándar (640x480@72Hz), no es nada especial... no hay ningún motivo para que un adaptador no funcione.

Me surge la duda en la impedancia de entrada de dicho adaptador, pero imagino que a poco que sea un adaptador decente debe funcionar porque las impedancias deben ser las acordes con un monitor VGA estándar. :))

Si tienes el adaptador prueba y nos cuentas... :))

Saludos.
Juan Manuel Rico

[Juanma Rico]

Buenas a todos/as,

Como sé que el SAV puede ser fuerte en fin de semana (la suegra es difícil de sobrellevar, todos lo hemos sufrido...), os adjunto el ejemplo siete de la colección del Pong que estoy preparando. En este ejemplo se pone a prueba el juego completo con todos sus bloques.
Está preparado para la TinyFPGA que va a 16Mhz, para la icezum Alhambra que va a 12Mhz hay que modificar el fichero de texto escrito en Verilog de la definición del módulo PLL (VgaSyncGen.v). En la línea 67 tenéis los parámetros del módulo:

    SB_PLL40_CORE #(.FEEDBACK_PATH("SIMPLE"),
                    .PLLOUT_SELECT("GENCLK"),
                    .DIVR(4'b0000),
                    .DIVF(7'b0111110), //16Mhz
//                    .DIVF(7'b1010011),   //12Mhz
                    .DIVQ(3'b101),
                    .FILTER_RANGE(3'b001)

Comentar la de 16Mhz y descomentar la otra. Esto es simplemente para calmar el SAV, posiblemente este cambio lo deje en un parámetro del bloque desde el propio icestudio, así que no os preocupéis demasiado... será más fácil en el futuro.

Por otra parte no sé si en la 1K entrará todo el juego completo (creo que no), probad y me contáis, pero también en los ejemplos mi intención es hacer el juego compatible con la icezum Alhambra (es posible que tenga que quitar el marcador de dos dígitos y dejarlo en uno solo, o quitar el sonido... veremos qué se puede hacer).

El que disponga de una 4K no creo que tenga problemas para probarlo, por supuesto tendrá que cambiar los pines de salida del control, sonido y VGA... no creo que coincidan con los de la TinyFPGA. :)) (Además creo que se borran en icestudio al convertir el proyecto de placa).

Es un ejemplo a medio construir... así que seguramente sufrirá cambios cuando lo termine subiendo a github, pero por lo menos, si queréis, se puede calmar el SAV con él. Siempre, aunque no podáis sintetizarlo podéis ver la estructura del iPxs-Pong y estudiarla. :))

Cualquier duda me la podéis preguntar... :))

Saludos
Juan Manuel Rico

[1138-4EB]

Hola de nuevo Juanma!

Un apunte sobre el PLL y la configuración para diferentes relojes de entrada. Parece ser que las constantes DIVR y DIVF son eso, constantes; por lo que no puedes cambiarlas sin cargar otro bitstream. Lo que puedes hacer es utilizar dos PLL, una detrás de la otra, ya que éstas tienen la opción de BYPASS. Así, si estás en la Alhambra, activas la primera y desactivas la segunda, y viceversa en la TinyFPGA. Esto permite cambiar la frecuencia "en tiempo real", es decir, mediante una señal GPIO; sin necesidad de cargar un bitstream diferente.

Un saludo

[Juanma Rico]

¡Hola Unai!

El lunes, 26 de marzo de 2018, 7:53:30 (UTC+2), 1138-4EB escribió:

Hola Juanma!

Vamos allá, a ver si puedo responderte... Que sean fáciles... :)

Sólo es comentar qué has hecho y qué no. No puede ser difícil :P

No, no era difícil... me la sabía, me la sabía... :)

 

Esa me la sé... :))
A ver,... el primer controlador VGA que hice fue basándome en el de Roland. Me lo tuve que trabajar (no fue un simple copy-paste sin entender) porque Roland usaba una frecuencia de 85Hz de cuadro, pero mi monitor cutre de pruebas no daba para esa frecuencia, así que tuve que modificar y modificar hasta que di con una frecuencia apropiada (la resolución siempre ha sido 640x480). Los parámetros de las frecuencias que encontraba por Internet eran basándose en, precisamente, un reloj de 25Mhz, pero la icezum Alhambra dispone de un reloj del sistema de 12Mhz, con estos 12Mhz al introducirlos en el PLL para obtener una frecuencia de reloj más alta para los sincronismos, unas veces no daba una frecuencia exacta y otras veces no era la estándar que "entendía" mi monitor, hasta que descubrí que los 72Hz de cuadro también estaban dentro del estándar, con 12Mhz se obtenía la frecuencia de pixel exacta (31.5Mhz) para esa resolución y mi monitor se los comía con papas y funcionaba (y parece que en muchos más monitores por las pruebas que se han estado haciendo, con lo que realmente era un estándar, perdido y desconocido por la mayoría pero un estándar).

Supongo que en algún momento habrás dado con ello, pero por si acaso:

http://martin.hinner.info/vga/timing.html
http://tinyvga.com/vga-timing/640x480@73Hz

¿Son esos lo valores de porche que estás utilizando? Pregunto porque como has indicado que te pegaste con ello, igual al final lo dejaste "a mano".

Sí, recuerdo haber visitado ambas páginas, pero no recuerdo en qué momento, posiblemente estaba lo suficientemente perdido como para no saber qué buscaba... :))

Al final encontré una página que te daba los valores correspondientes calculándolos según un formulario de parámetros. No recuerdo ahora mismo qué página era pero la dejé como comentario en el mismo código Verilog del controlador VGA.
 

 

El problema me surge con la TinyFPGA, usa un reloj de 16Mhz pero afortunadamente el PLL de la  iCE40 también da una frecuencia exacta de pixel para este reloj, con lo que únicamente se necesita cambiar un parámetro en la definición del módulo del PLL... no sé como lo haré con el Pong porque me gustaría que al menos funcionara en ambas placas con distintos relojes... aún estoy pensando.

¿Un pin externo que seleccione un multiplexor, que a su vez escoja dos (o más) constantes, que sean entradas al IP de configuración del PLL?

Lo he resulto un poco "a lo bruto", en el PLL la única diferencia para conseguir los 31.5Mhz según sea el reloj del sistema de 12Mhz o 16Mhz, está en el parámetro llamado divisor de realimentación (DIVF - feedback divider - FDivider) creo que es un 83 en un caso y un 62 en el otro. Lo he dejado como parámetro constante del bloque para que se pueda cambiar desde icestudio.
Estoy terminando de poner en orden los ejemplos y bloques para publicarlos y estén a disposición de todos... pero para que te hagas una idea de a lo que me refiero, en el fichero principal sería algo como esto:

Y la estructura interna del bloque es la siguiente...

Quizás lo ideal sería que este parámetro se modificara automáticamente al seleccionar la placa... pero no sé como hacerlo, así que habrá que hacerlo a mano de momento. Por lo menos no hay que editar el fichero en Verilog (que es la otra opción que se me ocurrió). Si alguien supiera responder a la pregunta de Sergio respecto a las las variables globales sería otra opción, de momento hay que avanzar y así se va a quedar. :))

 

Bueno me enrollo.. se me está pegando de ti... eso es que cada vez sé más de estos temas... jajajajajaja

Y yo agradecido. Es el detalle lo que quería :D

Idem... :D

 

La respuesta simple y concreta es: Una controladora VGA de 640x480@72Hz con 3 bits de profundidad de color, usando el PLL a 12Mhz y 16Mhz para ambas placas. :))

Me intriga lo de los bits de profundidad de color. Más abajo lo comento.
 

¿Qué otras resoluciones tenéis pensado utilizar (si es que lo habéis planteado)?

Pues me dio tanta batalla encontrar una resolución y una frecuencia que funcionara en mi monitor que no me he planteado volver a esa guerra, para mis pruebas, que es lo que más me gusta, me vale con esta resolución, además, aumentar la resolución es aumentar los recursos necesarios... y de LUTs andamos excasos. Lo que sí me he planteado es aumentar la profundidad de color (unas cuantas resistencias más en el conector VGA o un DAC en condiciones), pero por ahora no lo veo esencial (el Pong usa dos colores).

En realidad el consumo de LUTs no es muy diferente. Contar hasta 800 o 1024 requiere tantos bits como contar hasta 640. De 480 a 600 o 768 hay un bit. Pero entiendo que. habiéndote peleado con una, no te interese mirar esa parte y prefieras otras más creativas :D.

 

jajajajajajaja, efectivamente, me has pillado... es eso mismo, prefiero algo más creativo... lo de los LUTs era una excusa... muy mala por lo que veo. :)))

 

En las referencias anteriores, se indica que son necesarios relojes de entre 40 y 50 MHz para 800x600, y entre 65 y 75 MHz para 1024x768. ¿Cuánto es lo máximo a lo que has configurado un PLL? Entiendo que, de alguna forma estás haciendo la siguiente operación 12 * 84/32 = 31'5 y 16 * 63/32 = 31'5. ¿Has probado 16*84/32=42MHz? Aunque la VGA no funcionara, me interesa saber si tuviste algún problema de alimentación/potencia. Si no, ¡16*80/32=40MHz merece una prueba!

Pues no he mirado el máximo del PLL porque mi "cutre monitor" de pruebas ya se quedaba en los 85Hz... y al encontrar la establidad en los 31.5Mhz del reloj de pixel ahí me quedé, no seguí probando... pero para los cálculos los hice con la herramienta que el propio proyecto icestorm te da (icepll). Los parámetros en la llamada al programa y los resultados de ambos relojes los puedes encontrar en el mismo código del fichero VGASyncGen.v (por si tienes curiosidad).

 

Directamente, nada de buffer. Mi planteamiento original era un bloque monolítico de controladora, entregaba una posición x, y del pixel actual que estaba escaneando en pantalla y según esta posición del punto, otro bloque se encargaba de "realimentar" el color en la propia controladora para que, finalmente, lo mostrara por el conector VGA y así se "hiciera realidad" en forma de color.

Así es como funcionaba mi implementación.

Es lo más intuitivo desde luego... ;)
 

 

La estructura de Sergio Cuenca (a la que me estoy adaptando ahora) es distinta, usa un stream de señales VGA (VGAStr), un registro donde está la posición del pixel y las señales de sincronismo, este stream pasa por un bloque que genera el vídeo, éste se encarga de añadirle, según la posición marcada en el stream ,el color RGB (RGBStr) y es este stream RGB modificado el que se inyecta a otro bloque para generar las señales de salida al conector. Esta estructura es más lineal, más fácil de entender y sincronizar y permite cosas muy interesantes como multiplexar y superponer señales de vídeo (espero el concepto se vea claro en los ejemplos que estoy haciendo para la colección del Pong).

Sea como fuere la estructura que se utilice, actualmente no existe ningún tipo de buffer. Yo me lo planteé en su momento porque tenía problemas en los tiempos de realimentación, pero en la nueva estructura de Sergio no estoy teniendo estos tipos de problemas y por ahora funciona a las mil maravillas. :)

Entiendo, por lo tanto, que sí hay una especie de buffer. Es decir hay un registro de desplazamiento (el stream) de longitud n, donde se almacena la información que va a ser mostrada a continuación. El último componente lee el stream como si fuera una FIFO, decidiendo cuándo parar (porches) y cuándo leer. Pero el buffer no almacena toda la pantalla, ni por asomo.

Debe funcionar bien porque la salida del stream está registrada y prácticamente no hay ninguna lógica entre ésta y el conector VGA. Que es el error que mencioné en mi implementación.
 
Tengo la duda sobre "el ritmo" al que se trabaja. ¿El stream se va rellenando a un ritmo independiente del de consumo? ¿O el stream entero se para cuando hay porches y todo vuelve a moverse en cuanto llega el primer pixel de la siguiente línea?

En estos detalles igual te puede ayudar mejor Sergio, yo simplemente utilizo el "stream RGB" para decidir qué color paso al stream de salida cuando lo recibo, es decir, en el "stream RGB" de entrada (RGBStr_i) tienes mucha información: la señal de vídeo activo, la de las posiciones x e y del pixel, sincronismos vertical y horizontal y por último, la información de color en formato RGB(1:1:1). Fundamentalmente yo comparo la posición del pixel que aparece en el registro "stream RGB" de entrada y según esa posición del pixel y lo que quiero representar, cambio o dejo igual el color que trae el "stream RGB". Con esto puedes crear como "capas" de imágenes (estáticas o en movimiento) que se superponen (de ahí que sean bloques de tipo "Overlay", según las denominó Sergio en su colección iPxs).

Como dices, tiene una muy muy buena pinta de cara a poder hacer "efectos" más complejos y versátiles.

Sí, al no haber "realimentación del pixel de color" como yo hacía en mis proyectos "screen", es más fácil de seguir el flujo, de ampliar las opciones (multiplexar y demás), de reutilizar bloques y de crear efectos dinámicos independientes de la visualización (espero que con mi colección quede claro esto último).
 

Por lo que yo sé ninguno... yo uso siempre el mismo, pero hay pruebas que ha hecho Obijuan y Sergio por ahí en sus charlas y por ahora ha funcionado siempre... no me ha llegado feedback negativo en ese sentido (si alguien tiene algo que declarar, que lo haga ahora o calle para siempre...). De hecho yo uso unas resistencias mayores de las que propuso Obijuan en su MosterLED y los colores parecen iguales... imagino que no seguirá el estándar Pantone de la colorimetría... pero bueno, para pruebas en plan "maker" sirven. :))

Estandar Pantoqué? XD Todavía vamos a necesitar un Macbook Air Exclusive Pro...

Ya mismo, ya mismo, todo se andará... :)

 

 

Aquí no te llego a entender... Si no estoy equivocado y me extrañaría que tú lo estuvieras (imagino ha sido un lapsus) el número de colores no depende de la frecuencia de reloj, solo depende de la tensión de entrada a cada pin RGB, con tres resistencias consigues dos tensiones fijas según le pongas un uno o un cero en el pin de salida de la FPGA, por lo tanto son 2^3 = 8 colores distintos. Si necesitas más colores únicamente necesitas más bits de salida, realmente lo ideal es un convertidor digital-analógico que te de un rango de tensiones en los distintos pines, pero esto mismo se puede hacer con un divisor de tensión y una escalera de resistencias... no tiene nada que ver con la frecuencia ni con los sincronismos, que yo sepa... Con lo que no tienes que aumentar al doble la señal de reloj para obtener una paleta mayor.

Como dices, el color depende de la tensión de entrada a cada pin, es una señal analógica. Así, con una escalera de resistencias y 3 pines, tenemos 8 colores. Con una escalera y 6 pines, 64 colores. Con una escalera y 9 pines, 512, etc. Pero, puedes aplicar los principios del Pulse-Width-Modulation. Si utilizando un reloj dado a cada pixel le corresponden 20ns, con un reloj el doble de rápido podrás introducir dos bits (10ns cada uno). Es una PWM de 3 niveles: 0%, 50%, 100%. Si el reloj es cuatro veces más rápido, hay 5 niveles.

Curioso, que yo estaba pensando en multiplexar los bits en el tiempo (PWM), para no modificar el hardware. Por lo que ni se me había ocurrido utilizar varios pines de salida para cada color. Por contra, tú estás pensando en una conversión DAC paralela, y no se te ha ocurrido utilizar PWM. Es gracioso XD

No es tan curioso, no te creas... es que yo no tenía ni idea que se pudiera hacer con PWM... así que mis opciones en este sentido estaban limitadas por mi ignorancia... :))

Un saludo

Otro para ti.

[Juanma Rico]

El lunes, 26 de marzo de 2018, 8:05:04 (UTC+2), 1138-4EB escribió:

Hola de nuevo Juanma!

¡Hola otra vez! :)
 

Un apunte sobre el PLL y la configuración para diferentes relojes de entrada. Parece ser que las constantes DIVR y DIVF son eso, constantes; por lo que no puedes cambiarlas sin cargar otro bitstream. Lo que puedes hacer es utilizar dos PLL, una detrás de la otra, ya que éstas tienen la opción de BYPASS. Así, si estás en la Alhambra, activas la primera y desactivas la segunda, y viceversa en la TinyFPGA. Esto permite cambiar la frecuencia "en tiempo real", es decir, mediante una señal GPIO; sin necesidad de cargar un bitstream diferente.

Sí, así lo he dejado en icestudio, como un bloque constante del parámetro DIVF como ya habrás leído... :)
El problema de lo que propones (si no entiendo mal es activar y desactivar dos PLL en cascada) es que solo hay una PLL en la 1K (que yo sepa), así que lo puedes hacer quizás con la TinyFPGA (tendría que confirmar que tiene más de un PLL) pero no con la icezum Alhambra... así que estamos en la misma historia... si quieres que funcione para ambas, hay que cargar un bitstream distinto, quieras o no... :(((
 Y ya que lo cargas... lo cargas con la constante cambiada. :)))
 

Un saludo

Otro para ti. :)))

[1138-4EB]

26 de marzo de 2018, Juanma:

El problema de lo que propones (si no entiendo mal es activar y desactivar dos PLL en cascada) es que solo hay una PLL en la 1K (que yo sepa), así que lo puedes hacer quizás con la TinyFPGA (tendría que confirmar que tiene más de un PLL) pero no con la icezum Alhambra... así que estamos en la misma historia... si quieres que funcione para ambas, hay que cargar un bitstream distinto, quieras o no... :(((

 Y ya que lo cargas... lo cargas con la constante cambiada. :)))

Lo has entendido bien y, efectivamente, no se puede hacer en las 1K porque sólo hay una PLL. Mi gozo en un pozo.

[Juanma Rico]

Buenas a todos/as,

¡Ya está! ¡Ya está!... :))
Ya está terminada la adaptación del juego del Pong en el formato iPxs de Sergio. Además está como una colección de icestudio, para que sea fácil integrarlo y podáis juguetear con los distintos bloques.

Por otro lado, al final he tenido que duplicar los ejemplos para las dos placas por separado, no sólo por el parámetro del PLL, sino por los pines de entrada/salida.

Los de salida de la VGA en la iceZum Alhambra son los mismos que los que estableció Obijuan desde su MonsterLED, así que si tenéis el conector soldado espero que no tengáis que cambiar nada en el fichero. Por otra parte, aún hay cosas en el "aire" y Sergio seguramente me tendrá que corregir otras, así que la colección seguro que cambiará... pero para eso está github... ¿No? :))

Para instalar la colección solo tenéis que descargaros desde el propio github el código en formato comprimido (zip) y añadirlo (sin necesidad de descomprimir) como colección desde icestudio. Mirar los ejemplos que son muchos y he intentado que vayan de menos a más, si hay dudas o alguien cree que falta o sobra algún ejemplo que me lo diga y lo corrijo.

Aquí os dejo el enlace: https://github.com/juanmard/collection-Pong

Estoy loco por ver si, con esos sencillos bloques, a alguien se le ocurre algún otro juego... jejejejejeje

Saludos
Juan Manuel Rico

[Jose Pico]

Genial Juanma!

Seguro que saldrán muchas aplicaciones de la colección, bien para realizar otros juegos o bien para otras muchas cosas que no sean juegos.

Tengo muchas ganas de estudiarlo con detalle para seguro que usarlo en muchas aplicaciones.

Saludos y mil gracias 

[Sergio Cuenca]

Hola Juanma y Unai,

acabo de ver vuestro correo, la verdad es que paso poco por el grupo así es que ahora que estoy aprovecho para contestaros. La mayoría de las preguntas están contestadas en el wiki de iPXS. Inserto algunos comentarios a continuación.

El viernes, 23 de marzo de 2018, 3:51:23 (UTC+1), 1138-4EB escribió:

Hola Juanma y Jose!

Efectivamente, hay algún problema con este grupo y es que hay mensajes que aparecen como borrados sin razón evidente. Me ha pasado anteriormente tanto con mensajes que he enviado yo, como al visitar hilos y ver que en una conversación de 10-15 mensajes faltaban 2-3. Supongo que hay algún filtro que actúa después de que el email se haya reenviado a la lista pero antes de visualizarlo en la web. Y es especialmente curioso, porque el mensaje lo escribí desde groups.google.com (no desde gmail, ni desde un cliente de correo), lo cual quiere decir que el mismo sistema que aceptó enviarlo después decide ocultarlo/borrarlo. Estaría bien saber/conocer si hay algún tipo de filtro de spam que podamos estar haciendo saltar de alguna manera.

Sobre la VGA en si, por no desviar el hilo más de la cuenta, yo en su día implemente un módulo en VHDL para graficar las entradas/salidas de un PID y para dibujar "patrones de ajuste":

https://a.fsdn.com/con/app/proj/ohkis/screenshots/anie_infografia.png (pare superior derecha)
https://vimeo.com/64035600 (min 0:20 y 2:24, respectivamente)
http://sourceforge.net/projects/ohkis/files/anie/doc/Karrera%20Amaierako%20Proiektua.pdf/download (Figuras 1.33 en la página 1-61 (78/259) y 1.35 en la página 1-63 (80/259)).

La cuestión es que utilicé un reloj de 25 MHz para generar una resolución de 640x480 y todos los "cálculos" para decidir el color se hacían al vuelo. Puedes ver en la Figura 1.35 que hay varios bloques de comparación y puertas lógicas entre los registros y la salida, que es la señal "v" de la parte inferior. Esto provocaba que a veces las líneas aparecieran "corridas" en la pantalla, fruto de la latencia/retardo de la señal a través de esas puertas y la consiguiente descompensación con respecto a las señales de sincronía. Hoy en día sé que eso se resolvería simplemente registrando "v" a la salida. Pero me sirve como excusa para plantearte las siguientes dudas:

- ¿Qué resolución estáis generando y qué reloj estáis utilizando para ello? ¿Qué otras resoluciones tenéis pensado utilizar (si es que lo habéis planteado)?

iPXS está pensado para trabajar con cualquier resolución, ya que los bloques procesan las señales "al vuelo"  1pixel/ciclo y se encadenan formando un pipeline. La única restricción es que la fmáx del diseño sea suficiente para trabajar con el pixel_clock correspondiente a la resolución.

Para trabajar con una resolución distinta es necesario un nuevo bloque SyncGen (o parametrizar el que ya hay) ¿voluntarios?  

 

- ¿Generáis las señales de "color" directamente a partir de los contadores de fila/columna o utilizáis algún buffer intermedio? En la Figura 1.35 puedes ver que utilicé un buffer (un bloque RAM) para separar funcionalmente la parte del circuito que generaba qué había que dibujar, y por otro lado la parte que se encargaba de generar las señales de color VGA. Pero en lugar de hacer un buffer de 640x480, lo hice de 640x6 (una fila por cada línea a dibujar), porque en la FPGA que utilicé no había BRAM sufficiente para mantener un buffer de toda la pantalla. Supongo que las ICE estarán justitas también en este sentido.

Si, el color se genera a partir de las coordenadas del pixel (contadores fila/columna). Por el momento no hay buffers intermedios ya que se trata de diseños relativamente sencillos y no es necesario parar el stream. Efectivamente, dadas las restricciones de las ICE no me complique la vida en ese sentido. Cuando icestorm soporte las Xilinx ya ampliaremos iPXS.

 

- ¿Habéis tenido problemas con algún monitor quisquilloso al que no le gusten las señales de sincronía que estáis generando o las resistencias que estáis utilizando para convertir las señales digitales en "analógicas"?

No, me ha funcionado en varios monitores distintos (más modernos, más antiguos y varios tipos de cañones de proyección)

 

Como bonus, me quedó por probar la generación de más de ocho colores. Utilizando una señal de reloj de 50MHz se podría generar una paleta de 8*8=64 colores. Pero para eso es necesario que el circuito sintetizado sea capaz de ejecutarse a esa frecuencia. ¿Qué frecuencia máxima de ejecución estás obteniendo en la síntesis de vuestros circuitos?

Los cores iPXS pueden trabajar con cualquier profundidad de color, manteniendo el throughput 1pixel/c (no entiendo porque necesitas subir la frecuencia para generar más colores). Pero dada la baja capacidad de las ICE y que icestudio no permite parametrizar las entradas/salidas de los bloques opté por las solución más fácil RGB111

 Saludos