[VGA][apio] Proyecto screen-logo.

[Juanma Rico]

Buenas chicos/as,

En espera de los integrados de memoria RAM con protocolo SPI para el proyecto del "Cold/Warm boot" en el que estoy embarcado, he estado jugueteando este fin de semana con la controladora VGA y otros varios conceptos de desarrollo por bloques que me han llevado a un nuevo proyecto: el proyecto screen-logo. :)

Se trata de hacer un simple "salvapantallas" haciendo rebotar un logo por el monitor (por supuesto el de "FPGAWars").
Para ello me he basado en los proyectos de Roland y de Obijuan, la primera idea la plasmé en un papel como diagrama de bloques:

Básicamente son tres bloques, un controlador de vídeo que trabaja a 640x480@60Hz (vga_controller.v), uno de sonido (sound_controller.v, aún sin desarrollar) y un bloque que hace las veces de imagen en pantalla (logo.v). Este logo a su vez tiene una parte gráfica (graphics.v) y una dinámica (dinamic.v).

La parte gráfica toma la posición actual del pixel que se está representando en pantalla y que le entrega la controladora (x_px y y_px) y la posición actual del logo (x_logo y y_logo), según estas posiciones (y su relación entre ellas) envía de vuelta a la controladora el color del pixel que debe representar (color_px), en este caso blanco o verde. La "forma" del logo a su vez lo toma de otro módulo (image.v) que lo obtiene según la posición relativa dada por x_img e y_img.

Realmente suena más complejo de lo que es, el dibujo del diagrama de bloques ayuda en estos casos, como véis con muchos tachones a lo largo del desarrollo, pero tras traducir sin muchos problemas a bloques de Verilog y descubrir algunas peculiaridades del funcionamiento de la FPGA, creo que el proyecto está lo suficientemente avanzado como para compartir.

Os dejo un vídeo del aspecto que tiene actualmente el proyecto funcionando. Cuando conectas la iceZum Alhambra a un monitor VGA aparece esto en pantalla:

Aún queda por desarrollar el módulo de sonido (sound_controller.v) para que suene un buzzer o similar al rebotar, pero me pareció una buena idea que si alguien en alguna charla lo lleva, crea el público asistente que moviendo el ratón va a encontrar un Windows, Linux o algo así por debajo... y se quede con la boca abierta cuando sepa que no son más que unas puertas lógicas bien dispuestas y ordenadas en una FPGA dentro de una placa como la iceZum Alhambra... :))     ¡¡Y todo con herramientas libres!! jejejejeje

Como os digo el proyecto aún necesita de un módulo de sonido, pero lo básico ya lo podéis encontrar aquí, en mi cuenta de github. Si queréis cambiar el logo que rebota os he descrito con detalle como generarlo con GIMP y Matlab (he buscado como obtener el texto desde la imagen con algún plugin o alguna herramienta libre, pero no lo he encontrado... si alguien averigua como, que lo diga... ;D)

Para los que no se manejen con github y quieran probarlo calmando el SAV lo antes posible, os adjunto un comprimido con los ficheros necesarios.
Simplemente descomprimir en una carpeta y escribir apio upload. Si aparecen "warnings" del módulo de sonido es normal, está a medio construir.

Ya me contáis, cualquier duda...  en este hilo.  :))

Saludos.
Juan Manuel Rico

Pdta: Yo he adaptado el controlador VGA a mi monitor de frecuencia fija de 60Hz, si disponéis de un monitor que admita los 85Hz podéis usar los parámetros del PLL del proyecto de Roland, que debe funcionar sin problemas (aunque yo con mi "cutre monitor" no puedo probarlo).

Pdta2: Para los que no les gusten los ficheros de código he intentado pasar los bloques de Verilog a bloques de código en icestudio, pero me he quedado atascado a la primera al intentar utilizar el PLL desde icestudio. Desgraciadamente sin controladora VGA no podemos hacer ninguna prueba real. Si alguien sabe cómo integrar el PLL en icestudio le estaría agradecido me dijera y así puedo seguir con ello, de hecho si tiene mucho, mucho interés y se anima le paso lo que yo he hecho hasta ahora en icestudio para que continúe el trabajo.  :))

[Juanma Rico]

No sé porqué pero el vídeo no se ha incrustado bien (una vez publicado no lo veo). De todas formas está en el proyecto de github.
Os dejo un enlace directo.

https://raw.githubusercontent.com/juanmard/screen-logo/master/gallery/FPGAWars.mp4

Saludos.
Juan Manuel Rico

[Juan José Luna Espinosa]

Muy bueno, Juanma!

--
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/d199dfd8-4c64-4b70-9d21-a34e791bda4b%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Juanma Rico]

 
¡¡Gracias Juan José!!

Esto de controlar un monitor VGA da mucho juego y es muy satisfactorio... ya los siete leds de la placa te saben a poco... :)
¡tienes que probarlo! jejejejeje ;)

Saludos
Juan Manuel Rico

[Juan Gonzalez Gomez]

Lo he probado y mola un montón!!!! Gracias Juanma!  :-)

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/ab8c3010-c75b-4b77-a3fb-c8578694dece%40googlegroups.com.

[Juanma Rico]

¿Cómo que gracias? :)))
¡¡Gracias a ti por probarlo!!

¿Lo has probado tal y como está el controlador de VGA, o le has cambiado la frecuencia a 85Hz?

Saludos
Juan Manuel Rico

[Obijuan]

El martes, 26 de septiembre de 2017, 21:02:59 (UTC+2), Juanma Rico escribió:

¿Cómo que gracias? :)))
¡¡Gracias a ti por probarlo!!

¿Lo has probado tal y como está el controlador de VGA, o le has cambiado la frecuencia a 85Hz?

Lo he probado tal cual :-)

 

Saludos
Juan Manuel Rico

[Jose Pico]

Increíble!

Enhorabuena!

En poder lo estudio, voy saturado de SAV.

Saludos

[Juanma Rico]

Buenas,

Tenía que probarlo.
Tras la buena estabilidad demostrada por la nueva controladora VGA de 640x480@72Hz (al menos en mi monitor) en el proyecto "screen-leds",  he cambiado la controladora de este proyecto y.... ¡¡¡La diferencia es brutal!!! :)))

El logo se ve prefecto, aún a máxima velocidad.
Ahora sí que daría el pego de ser un salvapantallas de un sistema operativo cualquiera... ;)))

He mejorado también el incremento y decremento de velocidad del logo por pantalla (botón 1 disminuye velocidad y el botón 2 la aumenta).
Os daréis cuenta de lo rápido de una FPGA cuando veáis ante vuestros ojos como el logo prácticamente se desintegra de tan rápido que va. :)))

Todos los cambios hechos los podéis encontrar en github. (https://github.com/juanmard/screen-logo). ¡¡Actualizad!!

Ya me diréis que tal lo véis en vuestros monitores. ;)))

Saludos.
Juan Manuel Rico

[Juan Gonzalez Gomez]

Hola Juanma!!

Actualizado y .... joder... va super bien!!!!  Ahora se ve muchísimo mejor!!!!  Este proyecto es candidato a llevarlo a la OSHWDem para ponerlo en el stand, con un monitor VGA, y que la gente lo vea  :-)

Grande Juanma!!!!  Gracias!!!! 

Saluidos, Obijuan

PD.-  En cuanto pueda mando un vídeo para que la gente lo vea

--
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/b256517d-2311-4d62-9785-0c7beea9c133%40googlegroups.com.

[Obijuan]

He hecho un vídeo del logo en acción para que lo veais y he puesto un tweet :

https://twitter.com/Obijuan_cube/status/914384572242104321

mola mil!!!!!  :-D

¡Gracias Juanma!

Saludos, Obijuan

[Juanma Rico]

jajajajajajaja, mira, ya que yo no puedo ir... que vaya el logo. :)))

Gracias Juan. :))

[Juanma Rico]

Muchísimo mejor... tus vídeos son estupendos. :)))
Me alegra ver que otros monitores son capaces de mostrarlo...  seguiremos con esta controladora de 640x480@72Hz para las pruebas.

Veo en el vídeo que al github no subí los últimos cambios, los botones los veo muy sensibles.
Al introducir el px_clk en el módulo del logo como reloj y así mejorar la calidad de la imagen, todo aumenta de velocidad, incluido el "pooling" de chequeo en la pulsación de botones y con ello su "sensibilidad".

Para la sensibilidad hay que modificar el bit de chequeo del contador, es decir, este cambio:

@@ -45,15 +45,15 @@ module dinamic (
     
     // Velocity increment in both direction.
     wire pixel;
     reg [9:0] incx = 1;              // Increment in a x direction.
     reg [9:0] incy = 2;              // Increment in a y direction.
-    reg [5:0] delay = 15;            // Delay for animation.
+    reg [5:0] delay = 16;            // Delay for animation.
     reg [31:0] counter = 0;          // Counter for delay.
   
     // Increment and decrement animation.
-    always @(posedge counter[20])
+    always @(posedge counter[22])
     begin
         if (inc_vel) delay = delay + 1;
         if (dec_vel) delay = delay - 1;
     end
     

Simplemente cambiar un 15 por un 16 para que la velocidad inicial baje un poco y un 20 por un 22 para que la sensibilidad de los botones se ajuste al nuevo reloj.

Subiré el commit al github.

Saludos.
Juan Manuel Rico

[Juanma Rico]

Buenas a todos/as,

Por si finalmente Obijuan se anima a llevar mi proyecto de screen-logo a la OSHWDem17 junto a su MonsterLED (jejejejeje, sí, qué le voy a hacer,... me hace ilusión... ;)), estoy intentando "icestudiorizar" el código del programa por bloques hasta su mínima expresión para luego conectarlos uno a uno y por niveles (esto quedaría "más chulo" para enseñar en el stand que el código puro y duro). Estoy usando su método de incluir el fichero original e instanciar mediante un bloque de código desde icestudio, para luego ir hacia arriba enlazando bloques (probarlo en placa ya quedará para el fin de semana).

La cuestión es que tengo que empezar por el bloque más profundo y eliminar todos los errores antes de subir (al inscrustarse y hacer una copia interna en el proyecto de icestudio, si se modifica el bloque, no se actualiza el bloque incrustado, hay que borrarlo, volver a incluirlo como bloque y reconectar). En este caso, el bloque más profundo, es el fichero que accede a la imagen (image.v).
A la vez estoy aprovechando esta icestudiorización para ir limando errores que dá en el "verify" (aunque todo funciona, tanto error no queda bonito... :(( ).

Con "apio verify" no tengo problemas con el módulo (me da los warnings y errores correspondientes del fichero image.v), pero con icestudio me da el siguiente error de inclusión y ya no me avanza en la verificación.

Aún así he intentado seguir, pero por mucho que suba por los módulos del proyecto, el error permanece, por ejemplo, al verificar desde el módulo creado para (Graphics.v) obtenemos el mismo error.

El error parece que lo da "scons" al no encontrar el fichero de imagen "logo.list". He intentado incluirlo en la cabecera como los ficheros de verilog, pero nada, ni caso.
También he actualizado a la versión 0.31-dev de git por si fuera que estoy desfasado con icestudio, pero sigue dando el mismo error.

Algo similar (que no igual) me ocurrió hace tiempo con apio al modificar el fichero de ROM .list para el Simplez-F... esa extensión no estaba en la lista de ficheros que comprobaba scons y no volvia a generar el proyecto con los cambios. Me he animado a buscar entre los scripts de scons por si encontraba donde incluir la extensión para permitir los includes, pero no lo he encontrado.

Pregunto a los expertos... ¿es fácil solucionar el problema o mejor abandono el intento de icestudiorizar por bloques el proyecto?

Saludos
Juan Manuel Rico

[Jesús Arroyo]

Buenas:

Parece que debes incluir el fichero logo.list en el proyecto de Icestudio. Si adjuntas en un zip todos los ficheros (v, list, ice) que utilizas le podemos echar un vistazo.

Un saludo.

[Juanma Rico]

Gracias Jesús por tu pronta respuesta.

Te adjunto los ficheros relacionados con el image.v que es donde comienzan los problemas.
Imagino que si se soluciona en estos, el error dejará de propagarse por el resto de los módulos.

Un saludo
Juan Manuel Rico

[Juan Gonzalez Gomez]

Eso me pasó y lo solucioné. Las malas noticias es que me he dejado el portatil en la uni y no te la puedo enviar hasta mañana.

El problema es que icestudio no está incluyendo el fichero .list como parte del proyecto. La solución temporal es declarar una constante con el nombre del fichero (igual que está hecho en las memorias rom). De esta forma icestudio incluye el fichero y sintetiza ok.

Vamos, que se arregla con una línea que te mando mañana :-)

Por supuesto que llevaré tus proyectos a la oshwdem! Son la caña!

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/e911742c-3eef-44c0-8b03-3522133b3114%40googlegroups.com.

[Juanma Rico]

¡¡Gracias Juan!!
Espero esa línea... :)))

Saludos
Juan Manuel Rico

[Juan Gonzalez Gomez]

Hola Juanma!

Ya lo he estado revisando. La solución está incluida en el pull-request que te envié el finde en el repositiorio screen-logo. Lo puedes mirar ahí, en el fichero screen-logo.ice

https://github.com/juanmard/screen-logo

Justo debajo de los includes, añades esta línea:

localparam LOGO = "logo.list";

Con ella, icestudio incluirá logo.list como un fichero de proyecto interno

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/b1a68fcd-5430-4170-afd3-178edafe981b%40googlegroups.com.

[Jesús Arroyo]

Buenas:

Efectivamente esa es una solución tal todo como está ahora. El documento que se parsea para incluir ficheros es el generado por icestudio y hasta ahora como incluimos siempre el "foo.list" en el código lo utilizaba sin problemas. 

Pero en este caso donde está el "foo.list" es en uno de los ficheros verilog que se incluyen, por lo tanto:

- Puedo hacer que se puedan incluir .list files de la forma que se incluyen los .v y .vh. De esta manera queda centralizado en el ice al mismo nivel qué documentos se incluyen con el proyecto.

- También se podría hacer una búsqueda por los ficheros verilog incluidos de "foo.list" y posteriormente incluirlos. Esta solución es menos eficiente ya que implica cargar los ficheros verilog incluidos cada vez y también es menos explícita.

Qué os parecen las dos aproximaciones? 

El 04/10/2017 08:46, "Juan Gonzalez Gomez" <obijua...@gmail.com> escribió:

Hola Juanma!

Ya lo he estado revisando. La solución está incluida en el pull-request que te envié el finde en el repositiorio screen-logo. Lo puedes mirar ahí, en el fichero screen-logo.ice

https://github.com/juanmard/screen-logo

Justo debajo de los includes, añades esta línea:

localparam LOGO = "logo.list";

Con ella, icestudio incluirá logo.list como un fichero de proyecto interno

Saludos, Obijuan

El 3 de octubre de 2017, 21:03, Juanma Rico <juan...@gmail.com> escribió:

¡¡Gracias Juan!!
Espero esa línea... :)))

Saludos
Juan Manuel Rico

--
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-lib...@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/b1a68fcd-5430-4170-afd3-178edafe981b%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
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/CABqu7xqH19efUJf24%3DLva_7Y-DAkvx90O0RojmUrqqdrz%2BBp2g%40mail.gmail.com.

[Juan Gonzalez Gomez]

Hola!

  A mí me gusta la primera aproximación. Hacer que los .list se incluyan en el proyecto explícitamente, como si fuesen .v o .vh. Así además queda claro exactamente qué ficheros forman el proyecto. Y lo tenemos todo centralizado en el top design

Saludos, Obijuan

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CABqu7xqH19efUJf24%3DLva_7Y-DAkvx90O0RojmUrqqdrz%2BBp2g%40mail.gmail.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
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/CAOPL7BmpifBTjwnxdroxCn0yGc3D2sha_Q%2Bb6X8ddDQ2DR-2Jg%40mail.gmail.com.

[Juanma Rico]

¡¡Gracias Juan!!

Lo voy a probar ahora mismo. :))

Saludos.
Juan Manuel Rico

[Juanma Rico]

Buenas,

Estoy con Juan, es más intuitivo.
De hecho, sin saber que no se podía, es lo primero que se me ocurrió y es lo que intentaba hacer al buscar entre los scripts de "scons".

Saludos.
Juan Manuel Rico

[Juanma Rico]

¡¡Perfecto!!

Primera prueba superada... ;))



Saludos
Juan Manuel Rico

[Juan Gonzalez Gomez]

Genial!!!!  Vamos!!!!!  :-)

Saludos
Juan Manuel Rico

--
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/e050715d-d73d-416f-9a27-16cd3b0cdffd%40googlegroups.com.

[Juanma Rico]

Buenaaasssss.... :))

¡¡Ya está listo!! En un ratillo antes de comer lo he preparado... :)
No he podido probarlo (no dispongo de la iceZum Alhambra) pero corrigiendo los errores ha pasado la verificación desde el fichero principal (screen-logo.ice)

Debería funcionar.. pero he hecho muchos cambios y no estoy seguro. Por si lo queréis probar (o por lo menos ver como lo he construído por bloques) os adjunto un comprimido. Ya me contáis.

Saludos.

Juan Manuel Rico

[Juan Gonzalez Gomez]

Hola Juanma!

Tiene una pinta increible!! 😊

Lo he estado probando, pero no me ha funcionado. Sale la pantalla blanca. Mirando los recursos que ocupa, he visto que sólo consume 28 PLBs, mientras que la versión que sí funciona requiere 150 PLBs. Es mucha diferencia. Tengo la sensación de que hay algo que no está conectado y Yosys por tanto lo elimina

Si encuentro un hueco luego, lo miro

Saludos, Obijuan

Juan Manuel Rico

--
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/d15dcfba-08cc-486f-a2e6-d398607850ef%40googlegroups.com.

[Juan Gonzalez Gomez]

Espera... me está dando un error al verificar.... y a tí no te lo da... lo voy a comprobar bien y te digo...

Saludos, Obijuan

El 4 de octubre de 2017, 13:24, Juan Gonzalez Gomez <obijua...@gmail.com> escribió:

Hola Juanma!

Tiene una pinta increible!! 😊

Lo he estado probando, pero no me ha funcionado. Sale la pantalla blanca. Mirando los recursos que ocupa, he visto que sólo consume 28 PLBs, mientras que la versión que sí funciona requiere 150 PLBs. Es mucha diferencia. Tengo la sensación de que hay algo que no está conectado y Yosys por tanto lo elimina

Si encuentro un hueco luego, lo miro

Saludos, Obijuan

El 4 de octubre de 2017, 13:05, Juanma Rico <juan...@gmail.com> escribió:

Buenaaasssss.... :))

¡¡Ya está listo!! En un ratillo antes de comer lo he preparado... :)
No he podido probarlo (no dispongo de la iceZum Alhambra) pero corrigiendo los errores ha pasado la verificación desde el fichero principal (screen-logo.ice)

Debería funcionar.. pero he hecho muchos cambios y no estoy seguro. Por si lo queréis probar (o por lo menos ver como lo he construído por bloques) os adjunto un comprimido. Ya me contáis.

Saludos.

Juan Manuel Rico

--
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-lib...@googlegroups.com.

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

[Juanma Rico]

Gracias Juan,

He encontrado un error... pero no sé si será ese el problema (es lo malo de no poder probarlo, que voy a ciegas).
Se me quedó el módulo de imagen con la señal del reloj del sistema,... justo el módulo más profundo, he tenido que reconectar todos los módulos que dependían de él hasta el principal. En teoría debería funcionar con el reloj del sistema, aunque la calidad de la imagen no fuera muy buena... pero como también cambié la controladora por una asignación directa y no la he podido probar... pues voy doblemente a ciegas.

Sea como fuere te adjunto los nuevos módulos, prueba estos a ver si ese fuera el problema.

Saludos.
Juan Manuel Rico

[Juan Gonzalez Gomez]

Este no da error al verificar. Ocupa 106 PLBs. Aparece el logo en la esquina superior izquierda, pero sin moverse (aunque se aprieten los botones)

Todavía la diferencia entre los 106 PLBs de esta  y  los 150 de la que funciona es alta

Si quieres trabaja en la verión de apio hasta que no de ningún error y funcione, y cuando esté funcionando la incorporamos a los bloques. Esto último lo puedo hacer yo, si quieres

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/eabf8d4c-8028-4a4b-8893-55c47d6b69dc%40googlegroups.com.

[Juanma Rico]

Gracias Juan,

La falta de visualización entonces era por la descoordinación entre ambos relojes, el del sistema y el del pixel... ¡¡bien!! :)))

Si ahora no se mueve está claro, es el bloque de la dinámica... :)))

No se están actualizando los registros de x_logo e y_logo, es una de las cosas que he modificado, antes estaban en la definición del fichero logo.v, pero ahora los registros los puse en el interior del módulo de la dinámica... además cambié la asignación bloqueante por otra no-bloqueante... (otra laguna que tengo que no sé muy bien como funciona).

Lo he modificado por si la asignación no-bloqueante fuera el problema, te la adjunto (le he pasado el verify y no me da error), prueba si quieres a ver si el logo toma "dinamismo"... :)

Pero ya es todo un acierto saber que la controladora funciona como un bloque en icestudio. :)))

Mis pruebas tendrán que esperar ya hasta el fin de semana. Muchas gracias por las tuyas. ;))

Saludos.
Juan Manuel Rico

[Juan Gonzalez Gomez]

Hola Juanma!

Ya casi está. Ahora, tal cual estaba seguía ocupando 104 PLBs y no funcionaba. Luego he visto que la señal de entrada clr estaba sin conectar. Si no se está usando, como es una entrada conviene fijarlas a un valor. Viendo el código lo he puesto a 1.  Con esto ocupa 158PLBs y el logo se mueve.

Lo que no funciona ahora son los botones, que no hacen nada. Pero esto ya casi está :-)

¡Gracias!

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/1694c0ab-f424-4e20-98df-0ecd6e0d4efb%40googlegroups.com.

[Juanma Rico]

¡¡Claro, el "clear"!!

Recuerdo que me dio muchos problemas... finalmente lo anulé en código. ¡¡Me has dado la pista definitiva!!.
Resulta que no sé cómo pero se ha colado una versión antigua del dynamics.v en mi Windows (alguna historia con el github... seguro) y como ahora estoy trabajando desde él... pues se lo he contagiado a la versión de icestudio. :)))

Lo bueno de la técnica de instanciar el fichero en icestudio es que, si el error está en el fichero, mientras no cambie la interfase del bloque de icestudio no hay que modificar los bloques y reconectarlos... así que he modificado directamente el fichero contagiado y ahora sí me da 158...  :)))

Te lo adjunto a ver si te funciona ahora. :)))

Saludos.
Juan Manuel Rico

[Juanma Rico]

Bueno... da 152, no 158... seguro que hemos ahorrado algún registro al quitar los errores de "verify".... :)))

Saludos
Juan Manuel Rico

[Juan Gonzalez Gomez]

Touche!!!!!! 😀😀😀  Ya funciona perfectamente. A mí también me salen ahora 152 PLBs

¡¡Gracias!! 

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/fd07d4ec-f2b3-46d5-a3fe-fab22a2980c6%40googlegroups.com.

[Juanma Rico]

¡¡Bieeennnn!!! ¡¡Hemos ahorrado bloques lógicos!! jejejejejeje
¡¡Ganas de probarlo, oye!! jajajajajajajaja

Ya lo he subido al github. https://github.com/juanmard/screen-logo
Los ficheros originales se han modificado un poco, luego los he puesto todos (con copia incluída) en una única carpteta llamada "icestudio". Mi idea en un futuro es que no haya duplicidades de ficheros y que los módulos de icestudio "beban" de los originales cuando sea posible.

Como estos ya han pasado la verificación, haré lo contrario... adaptaré los ficheros originales a estos que usa icestudio.

¡¡Genial!! ¡¡Gracias Juan por guiarme!! :)))

Saludos y SAV.
Juan Manuel Rico

[Jesús Arroyo]

Perfecto. Entonces implementaré la posibilidad de incluir ficheros list en los bloques código. 

Un saludo.

--
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/b7821562-8190-45e8-9475-714f40801d55%40googlegroups.com.

[Jesús Arroyo]

Enhorabuena!!

Qué desarrollo más emocionante! Jaja

Esos bloques son una contribución brutal! 

Muchas gracias! 

--
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/2a96a6fc-6a34-454f-876f-5c1d7f163d10%40googlegroups.com.

[Juanma Rico]

Tras las pruebas de Obijuan y aunque evidentemente no hacía falta, he confirmado que el screen-logo funciona correctamente estando "icestudiorizado"... :))

He actualizado el proyecto en github por si os queréis actualizar: https://github.com/juanmard/screen-logo.git

Todos los ficheros necesarios los encontraréis en la carpeta icestudio, he intentado separar los ficheros de los módulos que usa icestudio pero no he podido hacerlo, ya que la función include no acepta más que el fichero del path actual, es decir, icestudio no permite hacer cosas como esta:

//@include "..\logo.v"

Así que no queda más que duplicar código en el mismo proyecto... un peligro y...
Una pena... :((

Saludos
Juan Manuel Rico

[scue...@gmail.com]

Hola Juanma,

he cambiado un poco el fichero dynamic.v para que la actualización de la posición y velocidad del logo se realice durante el período de Vblanking, de esta forma el movimiento del logo es fluido y sin saltos. 

Si me dices como, te lo envío para que lo añadas a tu proyecto (si te parece bien).

Saludos

[scue...@gmail.com]

Aquí os dejo mi aportación a screen-logo

https://www.dropbox.com/s/yif4tlig2d9n87y/20171025_SC_screen-logo.rar?dl=0

Saludos

El sábado, 7 de octubre de 2017, 17:57:25 (UTC+2), Juanma Rico escribió:

[Xoan Sampaiño]

Hola Sergio,

Tienes la excusa perfecta para aprender a contribuir en un repositorio
de GitHub :)

Obijuan tiene unos tutoriales donde, aunque utiliza como ejemplo
modelos en 3D hechos con FreeCAD, puedes aplicarlo igualmente si se
trata de código (es incluso más sencillo).

* http://www.iearobotics.com/wiki/index.php?title=Tutorial:_Github_y_Freecad

En tu caso, el repositorio de partida es el del proyecto screen-logo
de Juanma: https://github.com/juanmard/screen-logo

> --
> 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...@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/b44bf159-7179-415e-826b-29e72b17b8ae%40googlegroups.com.

>
> Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Xoan Sampaiño | https://about.me/xoan

[Juanma Rico]

Buenas a todas/os,

¡¡Geniaaaaal!! ¡¡Gracias por la contribución Sergio!!...  y Gracias a Xoan que me "ha quitado las letras del teclado" porque justo eso le iba a proponer a Sergio... :))
Hay movimiento en el grupo gracias a los cursos de Obijuan y hay que aprovechar para aprender al máximo... :))

Sergio, solo tienes que clonar el proyecto desde mi cuenta a una tuya, copiar los cambios a tu proyecto clonado y pedirme un "pull-request" desde la propia web de github, con esto ya se integran tus cambios en el histórico del proyecto screen-logo.

No tengas miedo, al principio github da un poco de miedo por aquello de "meter la pata" y estropear algo, lo hemos sufrido todos... pero no hay razón ninguna para temer nada, en github siempre se puede volver atrás... y si no se pudiera se empieza de nuevo, por eso no hay problema. :)))

Así aprendes a quitarte el miedo con github y además los cambios que has hecho también quedan reflejados con tu nombre en el proyecto (no hay que menospreciar el alimentar al Ego, que nunca viene mal para animarse y seguir...).

Yo estoy ocupado con otros temas estos meses y no le puedo dedicar el tiempo que me gustaría a las FPGA, pero estaré pendiente a mi cuenta de github por si me llegara tu pull-request para poder integrarlo cuanto antes.... :)))

Saludos
Juan Manuel Rico

[Juanma Rico]

Buenas Sergio,

Ya me has picado la curiosidad y he tenido que echar un vistazo a tus modificaciones. :))
Veo que lo que has hecho es incluir código para comprobar cuando se están dibujando píxeles en pantalla y solo actualizar la dinámica en ese caso... es una idea genial... Haz el pull-request que lo vamos a incluir en el proyecto, sí o sí...  :)))

Pero si te fijas, para que lo tengas en cuenta para futuros proyectos y aproveches mejor los recursos de la FPGA, el bloque de la controladora (vga_controller.v) ya tiene ese código hecho internamente. Te da la señal de salida "activevideo" para indicarte que está dibujando los píxeles por pantalla (luego el negado te da el Vblanking que tú usas). Esta modificación en la controladora la hice para el proyecto screen-leds donde la sincronización era más crítica que en el proyecto del logo.
Y te preguntarás... ¿Por qué no lo usas en el bloque del screen-logo si la mejora es evidente?  Pues desgraciadamente la respuesta es simple, por pura desídea... :)))

El screen-logo es el primer proyecto que hice para la serie "screen" y usé una controladora "cutre" y poco estable, sin esta señal "activevideo" de salida, además lo hice en código puro y duro (sin icestudio). Luego el proyecto completo lo "icestudioricé" y ya incluí esta nueva controladora con dicha señal, pero el bloque "logo" se quedó sin tocar y sin la señal de entrada para el "activevideo".  Como funcionaba, así lo dejé... :((

Te propongo... (a ver qué te parece)...

• Lo primero juguetear con github (eso no lo debes dejar, es importante)... y hacer tu pull-request al proyecto, yo lo aceptaré y así queda registrada la mejora.
  
  
• Luego, si aún te quedan fuerzas... :)), hacer lo que yo no hice por vagancia y desídea... incluir una señal de entrada en el bloque del logo, conectarla a la señal "activevideo" de salida de la controladora y usar dicha señal en el módulo dynamic.v como has hecho con tus modificaciones.
  
  
• Después, una vez hecho, ver si el comportamiento ha mejorado y si es igual o parecido al que has conseguido tú con el código extra... si es así, otro pull-request y que quede registrada la mejora final,...  :)))
  Yo no puedo dártelos, pero seguro que si se lo pedimos con insistencia a Obijuan, te dá algunos BitPoints extra de esos que da él... luego ya insistimos en una segunda fase para que nos cambie los BitPoints por alguna cerveza fría en alguna quedada de esas que hagamos... jejejejeje  :))

¿Qué te parece? :)))

Ya me cuentas.

Saludos.

Juan Manuel Rico

[Juanma Rico]

Buenas Sergio,

Ya en casa con más tranquilidad he vuelto a revisar los cambios de tu código y a compararlos con el mio... veo que no solo has creado la señal "endframe" en dynamic.v (la señal que yo asocio con el "activevideo" de la controladora), sino que has modificado más cosas, casi todo el código de hecho está modificado,... y la verdad, cuanto más lo miro e intento comprenderlo, más me gusta como lo has resuelto tú, veo que tengo que hacer un hueco para investigar tu código porque me parece mucho más eficiente y simple, así que estoy loco porque lo integres en el proyecto... (y si ya te animas y se puede aprovechar la señal de la controladora sería la caña... :))).

Hay cosas que aún no comprendo del todo, sigo estudiándolo... pero si no consigo comprenderlas espero que no te moleste que te pregunte... :)))

Saludos
Juan Manuel Rico

Pdta: Es "desidia", no "desídea" (que creo es un grupo de rock)... un día de estos mi profe de literatura me va a colgar del cuello... jejejejeje

[Juan Gonzalez Gomez]

Yo solo se que casqué el screen-logo en el proyector de la librecon de Santiago de Compostela y funcionó. Y para mí fue algo épico! 😂😂😂

¡Gracias! 

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/aa77535e-c0b9-4fd6-8cec-2522c5481cb4%40googlegroups.com.

[Juanma Rico]

jajajajajaja ¡¡Qué grandeeee eres Juan!! jajajajja
¡¡Para mí también fue épico escuchar y verte con el logo de fondo!! :)))

Por cierto,.... he estado buscando la charla completa de la Librecon y no la he encontrado... ¿Alguien sabe si está publicada y dónde?

Saludos.
Juan Manuel Rico

[scue...@gmail.com]

Gracias Xoan, 

lo tengo en el TODO, pero aún soy un poco torpe con github. Voy a mirarme el tutorial

Saludos desde el lado oscuro

> 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.

[scue...@gmail.com]

Hola Juanma,

voy con github esta noche.

En cuanto al código pregunta sin problema.

Saludos desde el lado oscuro

[Juanma Rico]

Perfecto... pues te pregunto... :)))

En las comparaciones para cambiar de sentido la velocidad hay dos opciones que no termino de entender...(para la x y la y)

if (x_logo>=x_logo_max  || x_logo>=(VISIBLECOLS-SPEED-border) || x_logo<border || x_logo<SPEED)

....

if (y_logo>=y_logo_max  || y_logo>=(VISIBLEROWS-SPEED-border) || y_logo<border || y_logo<SPEED)

¿Por qué esas comparaciones lógicas en rojo? ¿Qué evitan si ya están las de límites de borde? ¿Por qué no usas x_logo_min? Además, "dimensionalmente" no me cuadran... estamos comparando una posición con el resultado de una operación que contiene una velocidad con otras posiciones y dimensiones... e incluso directamente al final se compara una posición como x_logo (metros) con una velocidad como SPEED (metros/segundo) ¿qué sentido tienen?¿Por qué son necesarias?

Por otra parte, en la actualización de las coordenadas....

                // update the X coordinate
                if (dx==0)
                    x_logo = x_logo+SPEED;
                else
                    x_logo = x_logo-SPEED;

Comparas con cero (en rojo), en lugar de lo lógico que es comparar como positivo o negativo... ya que dx es una dirección (positiva o negativa)... ¿Comparar con cero es mucho mejor que con "mayor" o "menor"?¿Se obtiene un mejor sintetizado?¿Más eficiente?¿En qué afecta que se defina "signed" la señal y se compare con mayor o menor?

Aprovecho este mismo trozo de código que he pegado... este mismo código está dentro de un bloque "always @(posedge clk)".
No sé mucho de Verilog, pero no paro de leer por todos sitios (sin dar una explicación única... sino como una receta) que en un bloque sincronizado con el reloj (síncrono) no se deben poner asignaciones no-bloqueantes (=), sino bloqueantes (<=). ¿Por qué las utilizas aquí?¿Qué ventajas/desventajas tienen?¿Por qué son necesarias?¿Podrían ser no-bloqueantes?¿A qué se debe esta "receta" que no paro de leer y que nadie me explica? :)))

Otra pregunta... en el bloque de inicialización...

    // initialization of logo location, direction and speed
    initial
    begin
        x_logo <= (640 - width_logo)/4;
        y_logo <= (480 - height_logo)/4;
        dx <=0;
        dy <=0;
        SPEED <= 1;
    end

En este caso sí utilizas asignaciones no-bloqueantes... pero cuando yo hago esto mismo, luego tengo problemas: Por un lado me aparecen comportamientos no previstos, como que al hacer un hard-reset de la FPGA, en algunos casos, no se vuelve a inicializar. Es como si por algún motivo no ejecutara este bloque de inicializacion (He leido que es porque este bloque solo es para los test-bench y no se termina de sintetizar bien... aunque también he leido lo contrario...), o bien, con el bloque de inicialización, me aparecen errores de "drivers" duplicados si, además de estas, hago asignaciones no-bloqueantes dentro del bloque síncrono involucrando a las mismas variables (con el reset asíncrono tuve muchos problemas y verás que está comentado en el código y no se usa). ¿A qué se debe esto? ¿Qué estoy haciendo mal? ¿A ti te funciona siempre este bloque de inicialización con un hard-reset?¿Y con uno soft-reset?¿Te funciona?

Bueno, igual me he animado y te he preguntado demasiado... Cuando puedas... :)))

Saludos
Juan Manuel Rico

[scue...@gmail.com]

Hola Juanma,

yo vengo del VHDL, así es que seguramente se me habrán escapado algunas cosas del otro lenguaje. Voy a revisar algún tutorial verilog y te contesto.

Aprovecho para preguntarte. Estoy generando una señal VGA de color constante a partir de tu controlador y el ejemplo monsterLED

La única modificación que he hecho es la siguiente:

assign R= 1; // monocrome

assign G =0;

assign B = 0; 

En la simulación todo aparece correcto RGB es siempre igual a 100 pero cuando descargo en la tarjeta siempre me aparece el monitor en negro (como si RGB=000) , como si la síntesis hubiera eliminado esa asignación. 

Saludos

[Juanma Rico]

Hola Sergio,

Sé que es una pregunta tonta porque ya has trabajado (por lo que intuyo) con la VGA... pero por descartar... (y discúlpame si es muy evidente para ti)

¿Has conectado todos los cables de la señal de color?

Lo digo porque ese fue uno de mis primeros problemas "tontos" con los que tropecé... pensaba que conectando solo el cable rojo el monitor iba a funcionar... pero no, hay que conectar todos los cables aunque únicamente le envíes la señal roja al rojo, porque sino el monitor se queda en negro. :((

He aquí la metedura de pata registrada... :)))

Si no es eso y los has conectado todos... habría que investigar un poco más... ¿Dónde has hecho esa modificación?¿Dentro de la controladora?¿En un bloque exterior?
Ya me dices... ;)

Saludos
Juan Manuel Rico

[scue...@gmail.com]

Hola Juanma,

soy bastante novato con verilog, como te comentaba vengo de utilizar VHDL y otros lenguajes de síntesis de alto nivel. De hecho, la modificación de dynamic.v es una adaptación de un código VHDL que escribí hace muchos años,  por lo que no tomes mi código como una referencia de buenas prácticas.

Inserto mis respuestas a tus preguntas

El viernes, 27 de octubre de 2017, 1:56:04 (UTC+2), Juanma Rico escribió:

Perfecto... pues te pregunto... :)))

En las comparaciones para cambiar de sentido la velocidad hay dos opciones que no termino de entender...(para la x y la y)

if (x_logo>=x_logo_max  || x_logo>=(VISIBLECOLS-SPEED-border) || x_logo<border || x_logo<SPEED)

....

if (y_logo>=y_logo_max  || y_logo>=(VISIBLEROWS-SPEED-border) || y_logo<border || y_logo<SPEED)

¿Por qué esas comparaciones lógicas en rojo? ¿Qué evitan si ya están las de límites de borde? ¿Por qué no usas x_logo_min? Además, "dimensionalmente" no me cuadran... estamos comparando una posición con el resultado de una operación que contiene una velocidad con otras posiciones y dimensiones... e incluso directamente al final se compara una posición como x_logo (metros) con una velocidad como SPEED (metros/segundo) ¿qué sentido tienen?¿Por qué son necesarias?

<SC>

x_logo+width >visiblerows  controla que el logo no supere la zona de visualización

x_logo+ speed>visiblerows controla que la siguiente posición del logo no supere la zona de visualización 

speed es la velocidad en pixels/frame, o de otro modo, el incremento en pixels de x_logo (cada frame). Como el valor de x_logo se actualiza cada frame x_logo+speed nos dice la posición del logo en el siguiente frame 

 

Por otra parte, en la actualización de las coordenadas....

                // update the X coordinate
                if (dx==0)
                    x_logo = x_logo+SPEED;
                else
                    x_logo = x_logo-SPEED;

Comparas con cero (en rojo), en lugar de lo lógico que es comparar como positivo o negativo... ya que dx es una dirección (positiva o negativa)... ¿Comparar con cero es mucho mejor que con "mayor" o "menor"?¿Se obtiene un mejor sintetizado?¿Más eficiente?¿En qué afecta que se defina "signed" la señal y se compare con mayor o menor?

<SC> dx es un registro de 1bit de forma que la codificación de las direcciones será 0: hacia la dcha., 1:hacia la izq. Si la definimos como registro "signed" necesitaríamos 2bit para codificar.  

 

Aprovecho este mismo trozo de código que he pegado... este mismo código está dentro de un bloque "always @(posedge clk)".
No sé mucho de Verilog, pero no paro de leer por todos sitios (sin dar una explicación única... sino como una receta) que en un bloque sincronizado con el reloj (síncrono) no se deben poner asignaciones no-bloqueantes (=), sino bloqueantes (<=). ¿Por qué las utilizas aquí?¿Qué ventajas/desventajas tienen?¿Por qué son necesarias?¿Podrían ser no-bloqueantes?¿A qué se debe esta "receta" que no paro de leer y que nadie me explica? :)))

<SC> Ambas asignaciones se pueden utilizar en un bloque sincronizado por reloj. La diferencia entre ellas estriba en que un conjunto de asignaciones bloqueantes (=) se realizan siempre de forma secuencial. Es decir la segunda asignación no se realiza hasta que termina la primera (por eso se le llama bloqueante). Si todas las asignaciones son tipo (<=), estas se realizan simultáneamente (la primera no bloquea a las siguientes).

ej:

f1=1; f2=2; f0=0;

always(posedge clk)                                   always(posedge clk) // en el mismo ciclo se realizan ambas asignaciones

   f1=f0;                                                                      f1<=f0;

   if (f1==1)                                                                 if (f1==1)

      f2=f1;                                                                      f2<=f1;

   else                                                                        else

      f2=3;                                                                       f2=3;

f0   0    1   0                                          f0   0    1   0        

f1   1    0   1   0                                     f1   1    0   1   0

f2   2    3   1   3                                     f2   2    1   3   1

Caso =: f0=0 entonces f1=0 se comprueba el if (false) y f2=3;    f0=1 entonces f1=1 se comprueba el if (true) y f2=1

Caso <=: f0=0 entonces f1=0 simultáneamente se comprueba el if (con el valor anterior de f1) (true) y f2=1; etc...

En nuestro caso:

Supongamos que d=0 (hacia la derecha) y x_logo>x_logo_max, entonces al entrar en la zona de blanking (endframe) 1) dx cambia de dirección y  2)  x_logo=x_logo - speed. En el siguiente frame el logo se visualiza lejos del borde vertical.

Ahora cambiamos las asignaciones por <=. Como x_logo>x_logo_max entonces dx cambia de dirección (izq) y simultáneamente x_logo=x_logo + speed. Fíjate que x_logo se sigue incrementando porque todavía no ha detectado el cambio en dx  (se ha actualizado simultáneamente). En el siguiente frame el logo se sale parcialmente de la zona de visualización. Volvemos a la zona de blanking y de nuevo x_logo>x_logo_max, entonces dx cambia (dcha) y x_logo =x_logo - speed. El resultado es que el logo no se mueve.

 

Otra pregunta... en el bloque de inicialización...

    // initialization of logo location, direction and speed
    initial
    begin
        x_logo <= (640 - width_logo)/4;
        y_logo <= (480 - height_logo)/4;
        dx <=0;
        dy <=0;
        SPEED <= 1;
    end

En este caso sí utilizas asignaciones no-bloqueantes... pero cuando yo hago esto mismo, luego tengo problemas: Por un lado me aparecen comportamientos no previstos, como que al hacer un hard-reset de la FPGA, en algunos casos, no se vuelve a inicializar. Es como si por algún motivo no ejecutara este bloque de inicializacion (He leido que es porque este bloque solo es para los test-bench y no se termina de sintetizar bien... aunque también he leido lo contrario...), o bien, con el bloque de inicialización, me aparecen errores de "drivers" duplicados si, además de estas, hago asignaciones no-bloqueantes dentro del bloque síncrono involucrando a las mismas variables (con el reset asíncrono tuve muchos problemas y verás que está comentado en el código y no se usa). ¿A qué se debe esto? ¿Qué estoy haciendo mal? ¿A ti te funciona siempre este bloque de inicialización con un hard-reset?¿Y con uno soft-reset?¿Te funciona?

Bueno, igual me he animado y te he preguntado demasiado... Cuando puedas... :)))

<SC> En teoría el bloque initial no está soportado por los sintetizadores orientados a ASIC, y el valor por defecto de los registros debe estar determinado por una señal explícita de rst y una sentencia always donde se define que pasa cuando se activa el reset. 

Sin embargo en el caso de las FPGAs, además de utilizar una señal de rst, se puede utilizar el propio bitstream para cargar un estado inicial en los ff y memorias. Este parece ser el caso de yosys (y de otros sintetizadores verilog para FPGAs como el de Xilinx). También parece funcionar cosas como:  

                   reg [9:0] _x_logo = (640 - width_logo)/4; //inicialización en la declaración

El problema de los drivers duplicados viene por hacer asignaciones a un registro desde bloques always distintos. En el código original utilizas un bloque always para inicializar el valor de  x_logo con clr y en otro bloque always actualzas su valor.

Para que no haya estos problemas habría que hacer algo así:

always(posedge clk or posedge clr)

if (clr)

   x_logo<=0;

else

   if ()

      x_logo<= ......

Ya he verificado todo esto y he retocado un poco el código. ahora se utiliza el bloque initial para definir el valor de los registros después de cargar el bitstream y una señal clr para hacer un softreset (además se pueden definir valores distintos para cada caso)

Te hago pull-request

 

Saludos
Juan Manuel Rico

[scue...@gmail.com]

Si, lo conecto todo y las señales vsync /hsync las genero con el bloque vga_controller. (imagen)

Es como si el sintetizador eliminases estas asignaciones a constante

[Juan José Luna Espinosa]

Buena explicación scuenca. Perdonad que me meta. No tenía idea que el (=) se usa secuencialmente. Pero no acabo de comprenderlo: si estamos dentro de un always @(posedge clk), no veo cómo se pueden hacer varias operaciones seguidas una de otra, en un solo flanco de reloj. ¿Es que la siguiente asignación se espera al siguiente flanco? Y, ¿En qué casos se usa? ¿Es sólo para poder programar de una forma más tradicional, algorítmica?

--
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/32b7380b-bf4d-42fe-af11-3401b3064d5f%40googlegroups.com.

[scue...@gmail.com]

Hola Juan José,

la ejecución secuencial se refiere a que en el ciclo de reloj las operaciones se efectúan (evalúan) en el orden que marcan las asignaciones (no tiene que ver con un estilo de programación más algorítmico). De esta forma cuando se cambia el orden de las asignaciones cambia el resultado. En el caso (<=) se puede alterar el orden en que se escriben las asignaciones sin alterar el resultado, ya que se todas se evalúan simultáneamente

Adjunto ejemplo

En el segundo ejemplo se puede ver el resultado de la síntesis con un código similar al de vga_controller

Saludos

[Juanma Rico]

Buenas Sergio,

Yo también soy novato con Verilog y además sospecho que no tengo el background que tú tienes en VHDL, así que lo primero muchas gracias por el esfuerzo en contestar, sé que fueron muchas preguntas pero es que me "vine arriba" al ver una luz al final del túnel.... ;))

He leido con atención (lo que me ha permitido una de estas mañanas de ajetreo que tengo...) y aunque me has aclarado cosas, sigo con zonas oscuras.
Me arriesgaré y te volveré a preguntar... pero entiendo si finalmente no contestas al "pesao de Juanma"... jejejejejeje
Aprovecho y te pregunto sobre tus respuestas...

El miércoles, 1 de noviembre de 2017, 23:13:37 (UTC+1), scue...@gmail.com escribió:

Hola Juanma,

soy bastante novato con verilog, como te comentaba vengo de utilizar VHDL y otros lenguajes de síntesis de alto nivel. De hecho, la modificación de dynamic.v es una adaptación de un código VHDL que escribí hace muchos años,  por lo que no tomes mi código como una referencia de buenas prácticas.

Inserto mis respuestas a tus preguntas

<JMR>

Lo dicho, yo soy igual de novato o más que tú... y sin experiencia previa en otros HDL, así que... seguramente tus prácticas sean mucho mejor que las mías :))).

El viernes, 27 de octubre de 2017, 1:56:04 (UTC+2), Juanma Rico escribió:

Perfecto... pues te pregunto... :)))

En las comparaciones para cambiar de sentido la velocidad hay dos opciones que no termino de entender...(para la x y la y)

if (x_logo>=x_logo_max  || x_logo>=(VISIBLECOLS-SPEED-border) || x_logo<border || x_logo<SPEED)

....

if (y_logo>=y_logo_max  || y_logo>=(VISIBLEROWS-SPEED-border) || y_logo<border || y_logo<SPEED)

¿Por qué esas comparaciones lógicas en rojo? ¿Qué evitan si ya están las de límites de borde? ¿Por qué no usas x_logo_min? Además, "dimensionalmente" no me cuadran... estamos comparando una posición con el resultado de una operación que contiene una velocidad con otras posiciones y dimensiones... e incluso directamente al final se compara una posición como x_logo (metros) con una velocidad como SPEED (metros/segundo) ¿qué sentido tienen?¿Por qué son necesarias?

 

x_logo+width > visiblerows  controla que el logo no supere la zona de visualización

x_logo+speed > visiblerows   controla que la siguiente posición del logo no supere la zona de visualización 

speed es la velocidad en pixels/frame, o de otro modo, el incremento en pixels de x_logo (cada frame). Como el valor de x_logo se actualiza cada frame x_logo+speed nos dice la posición del logo en el siguiente frame 

 

<JMR>

Ok,  entiendo entonces que mezclar la posición con la velocidad es simplemente para anticiparse a lo que pueda pasar en el siguiente frame, imagino que eso también hace el código más eficiente. :))

 

Por otra parte, en la actualización de las coordenadas....

                // update the X coordinate
                if (dx==0)
                    x_logo = x_logo+SPEED;
                else
                    x_logo = x_logo-SPEED;

Comparas con cero (en rojo), en lugar de lo lógico que es comparar como positivo o negativo... ya que dx es una dirección (positiva o negativa)... ¿Comparar con cero es mucho mejor que con "mayor" o "menor"?¿Se obtiene un mejor sintetizado?¿Más eficiente?¿En qué afecta que se defina "signed" la señal y se compare con mayor o menor?

<SC> dx es un registro de 1bit de forma que la codificación de las direcciones será 0: hacia la dcha., 1:hacia la izq. Si la definimos como registro "signed" necesitaríamos 2bit para codificar.  

<JMR>

Perfecto... nos ahorramos un bit... aumenta la eficiencia del código como yo sospechaba. ;))

Veo que hacer explícitos los conceptos en el código no siempre es lo más eficiente. (Lo que demuestra que a veces es mejor comentar más y abstraer menos... :))).)

 

Aprovecho este mismo trozo de código que he pegado... este mismo código está dentro de un bloque "always @(posedge clk)".
No sé mucho de Verilog, pero no paro de leer por todos sitios (sin dar una explicación única... sino como una receta) que en un bloque sincronizado con el reloj (síncrono) no se deben poner asignaciones no-bloqueantes (=), sino bloqueantes (<=). ¿Por qué las utilizas aquí?¿Qué ventajas/desventajas tienen?¿Por qué son necesarias?¿Podrían ser no-bloqueantes?¿A qué se debe esta "receta" que no paro de leer y que nadie me explica? :)))

<SC> Ambas asignaciones se pueden utilizar en un bloque sincronizado por reloj. La diferencia entre ellas estriba en que un conjunto de asignaciones bloqueantes (=) se realizan siempre de forma secuencial. Es decir la segunda asignación no se realiza hasta que termina la primera (por eso se le llama bloqueante). Si todas las asignaciones son tipo (<=), estas se realizan simultáneamente (la primera no bloquea a las siguientes).

ej:

 

f1=1; f2=2; f0=0;

always@(posedge clk)          always@(posedge clk) // en el mismo ciclo se realizan ambas asignaciones

   f1=f0;                       f1<=f0;

   if (f1==1)                   if (f1==1)

      f2=f1;                       f2<=f1;

   else                         else

      f2=3;                        f2=3;

f0   0    1   0              f0   0    1   0        

f1   1    0   1   0          f1   1    0   1   0

f2   2    3   1   3          f2   2    1   3   1

Caso =: f0=0 entonces f1=0 se comprueba el if (false) y f2=3;    f0=1 entonces f1=1 se comprueba el if (true) y f2=1

Caso <=: f0=0 entonces f1=0 simultáneamente se comprueba el if (con el valor anterior de f1) (true) y f2=1; etc...

<JMR>

No sé si es un error mio de concepto o qué, pero el ejemplo no lo veo claro. Entiendo los conceptos "bloqueantes" y "no-bloqueantes", pero tu ejemplo me lía un poco... ¿En qué momento f0 se hace 1?

En nuestro caso:

Supongamos que d=0 (hacia la derecha) y x_logo>x_logo_max, entonces al entrar en la zona de blanking (endframe) 1) dx cambia de dirección y  2)  x_logo=x_logo - speed. En el siguiente frame el logo se visualiza lejos del borde vertical.

Ahora cambiamos las asignaciones por <=. Como x_logo>x_logo_max entonces dx cambia de dirección (izq) y simultáneamente x_logo=x_logo + speed. Fíjate que x_logo se sigue incrementando porque todavía no ha detectado el cambio en dx  (se ha actualizado simultáneamente). En el siguiente frame el logo se sale parcialmente de la zona de visualización. Volvemos a la zona de blanking y de nuevo x_logo>x_logo_max, entonces dx cambia (dcha) y x_logo =x_logo - speed. El resultado es que el logo no se mueve.

<JMR>

Sí, eso me pasó en mi primer intento de actualización de las posiciones (el logo no se movía) y tuve que cambiar en el bloque síncrono una no-bloqueante por una bloqueante, de hecho no sabía muy bien porqué pasaba esto antes de entender los conceptos y lo comenté en el código (el inglés es pésimo, pero está comentado... :))

Lo que ya no entiendo entonces es porqué existe esa "receta" de no usar bloqueantes en el código síncrono que no paro de leer por todos lados... :((

<JMR>

Muchísimas gracias por las respuestas...

pull-request integrado en el proyecto.... :))

Saludos

Juan Manuel Rico

 

Saludos
Juan Manuel Rico

[Juanma Rico]

Buenas a ambos...

Ahora me meto yo... :P
En el último esquema... ¿f2 no deberían ser dos bits para poder asignarle el 3 final?

Saludos
Juan Manuel Rico

[Juan José Luna Espinosa]

Gracias, me ha quedado mucho más claro. Sí, yo también pienso que debería asignarse un 1 a f2 en lugar de un 3.

--
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/789c8e5c-62ef-4a8d-b25f-1f5d3c6138ec%40googlegroups.com.

[scue...@gmail.com]

Creo que el tema = vs <= queda más claro en la contestación a Juan José

[José Raúl Montero Ponce]

Buenas, estoy emoezando ahora con las fpgas. Como puedo probar el proyecto. Tengo que hacer la conexion con las resistencias al monitor,ok. Despues como cargo el proyecto, he visto que en la carpeta del proyecto de juanma hay varios.Ice
Como lo hago, me gustaria cargarlo para ir aprendiendo. O con esa o con la basica de obijuan. En definitiva, como se crgan los proyectos cuando hay varios.Ice.
Gracias, saludos.

[Juan Gonzalez Gomez]

Hola Jose Raúl,

Prueba primero el "Hola mundo": El monster-led. Están todas las instrucciones explicadas de forma muy detallada:

https://github.com/Obijuan/MonsterLED/wiki

Para el resto de proyecto sólo tienes que cargar el .ice principal, o el ejemplo concreto. En el caso del screen-logo, es el screen-logo.ice.

Pero lo mejor es que pongas en marcha primero el hardware con el hola mundo, y cuando te funcione pruebas los demás

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 una entrada 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 este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fdd892d4-07b4-41f6-90ac-001e7c38cf0c%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[José Raúl Montero Ponce]

Gracias, lo pruebo.

[José Raúl Montero Ponce]

Pero cuando quiero ver el codigo del principal, me sale muy poco codigo, me gustaria verlo todo, para ver como funciona.

[Juan Gonzalez Gomez]

En el ejemplo que te he pasado, haz doble click en el módulo de la VGA. Ahí está todo el código

Este es un ejemplo:

Haces doble click en el bloque de la pantalla:

Y ahí tienes el código. No hay nada más (en el caso del monsterled)

Saludos, Obijuan

El 8 de noviembre de 2017, 13:02, José Raúl Montero Ponce <jr.mont...@gmail.com> escribió:

Pero cuando quiero ver el codigo del principal, me sale muy poco codigo, me gustaria verlo todo, para ver como funciona.

--
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 una entrada 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 este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/8b5c50f2-cfec-4a3c-8ef7-344e211e1ed3%40googlegroups.com.

[Juanma Rico]

Buenas José Raúl,

Cuando hayas probado el "Hola mundo" con el MonsterLED como te indica Obijuan, puedes probar un test muy sencillo de centrado (test.ice) y otro de colores (test-bars.ice) que puedes encontrar en mi github (https://github.com/juanmard/test-icestudio).

El primero te muestra una raya vertical en el centro de la pantalla de color rojo y el segundo ocho franjas verticales de colores, que son los ocho colores que se pueden representar con esta controladora.

Una vez te funcione el MonsterLED y estos dos test puedes estar seguro que el resto de ejemplos te van a funcionar sin ningún problema. :)))

Saludos
Juan Manuel Rico

[José Raúl Montero Ponce]

Gracias, estoy en ello, ya os cuento.
Saludos

El martes, 26 de septiembre de 2017, 19:07:50 (UTC+2), Juanma Rico escribió:

Buenas chicos/as,

En espera de los integrados de memoria RAM con protocolo SPI para el proyecto del "Cold/Warm boot" en el que estoy embarcado, he estado jugueteando este fin de semana con la controladora VGA y otros varios conceptos de desarrollo por bloques que me han llevado a un nuevo proyecto: el proyecto screen-logo. :)

Se trata de hacer un simple "salvapantallas" haciendo rebotar un logo por el monitor (por supuesto el de "FPGAWars").
Para ello me he basado en los proyectos de Roland y de Obijuan, la primera idea la plasmé en un papel como diagrama de bloques:

Básicamente son tres bloques, un controlador de vídeo que trabaja a 640x480@60Hz (vga_controller.v), uno de sonido (sound_controller.v, aún sin desarrollar) y un bloque que hace las veces de imagen en pantalla (logo.v). Este logo a su vez tiene una parte gráfica (graphics.v) y una dinámica (dinamic.v).

La parte gráfica toma la posición actual del pixel que se está representando en pantalla y que le entrega la controladora (x_px y y_px) y la posición actual del logo (x_logo y y_logo), según estas posiciones (y su relación entre ellas) envía de vuelta a la controladora el color del pixel que debe representar (color_px), en este caso blanco o verde. La "forma" del logo a su vez lo toma de otro módulo (image.v) que lo obtiene según la posición relativa dada por x_img e y_img.

Realmente suena más complejo de lo que es, el dibujo del diagrama de bloques ayuda en estos casos, como véis con muchos tachones a lo largo del desarrollo, pero tras traducir sin muchos problemas a bloques de Verilog y descubrir algunas peculiaridades del funcionamiento de la FPGA, creo que el proyecto está lo suficientemente avanzado como para compartir.

Os dejo un vídeo del aspecto que tiene actualmente el proyecto funcionando. Cuando conectas la iceZum Alhambra a un monitor VGA aparece esto en pantalla:

Aún queda por desarrollar el módulo de sonido (sound_controller.v) para que suene un buzzer o similar al rebotar, pero me pareció una buena idea que si alguien en alguna charla lo lleva, crea el público asistente que moviendo el ratón va a encontrar un Windows, Linux o algo así por debajo... y se quede con la boca abierta cuando sepa que no son más que unas puertas lógicas bien dispuestas y ordenadas en una FPGA dentro de una placa como la iceZum Alhambra... :))     ¡¡Y todo con herramientas libres!! jejejejeje

Como os digo el proyecto aún necesita de un módulo de sonido, pero lo básico ya lo podéis encontrar aquí, en mi cuenta de github. Si queréis cambiar el logo que rebota os he descrito con detalle como generarlo con GIMP y Matlab (he buscado como obtener el texto desde la imagen con algún plugin o alguna herramienta libre, pero no lo he encontrado... si alguien averigua como, que lo diga... ;D)

Para los que no se manejen con github y quieran probarlo calmando el SAV lo antes posible, os adjunto un comprimido con los ficheros necesarios.
Simplemente descomprimir en una carpeta y escribir apio upload. Si aparecen "warnings" del módulo de sonido es normal, está a medio construir.

Ya me contáis, cualquier duda...  en este hilo.  :))

Saludos.
Juan Manuel Rico

Pdta: Yo he adaptado el controlador VGA a mi monitor de frecuencia fija de 60Hz, si disponéis de un monitor que admita los 85Hz podéis usar los parámetros del PLL del proyecto de Roland, que debe funcionar sin problemas (aunque yo con mi "cutre monitor" no puedo probarlo).

Pdta2: Para los que no les gusten los ficheros de código he intentado pasar los bloques de Verilog a bloques de código en icestudio, pero me he quedado atascado a la primera al intentar utilizar el PLL desde icestudio. Desgraciadamente sin controladora VGA no podemos hacer ninguna prueba real. Si alguien sabe cómo integrar el PLL en icestudio le estaría agradecido me dijera y así puedo seguir con ello, de hecho si tiene mucho, mucho interés y se anima le paso lo que yo he hecho hasta ahora en icestudio para que continúe el trabajo.  :))

[José Raúl Montero Ponce]

Bueno, mejor voy a esperar a avanzar en el curso de obijuan, creo que quiero correr mas de lo que mis pies pueden.

Saludos. 

[Sergio Cuenca]

hola Juanma,

puedes recomendarme algún editor para generar el README.md de la colección. Me gustaría hacer algo parecido al que has incluido en el proyecto screen-logo.

Saludos

 

[Juanma Rico]

Buenas Sergio,

Pues he probado varios específicos y la verdad, al final termino desinstalándolos.
No uso el formato markdown mucho más allá de los pequeños ficheros README del github y alguna que otra prueba sencilla de documentación personal.
Hago muchas pruebas y al final siempre termino usando el plugin para el Notepad++. Este sí lo uso con frecuencia como editor rápido de código (incluso para Verilog).

Para las imágenes uso las herramientas libres GIMP e Inkscape y el Paint de Windows cuando trabajo con él, creo que es el mejor (y posiblemente el único) programa original que ha hecho Windows... jejejejeje :))).

Últimamamente intenté en otro proyecto hacer un TOC como hace Obijuan (una lista de contenidos) con una herramienta especializada que me bajé (tenía un loro o pájaro azul en el icono, no recuerdo el nombre) y después de mucho trabajo, al subirlo, el github no lo desplegó. Así que finalmente lo desinstalé (otro más) y sigo trabajando con el Notepad++.  :)))

Igual alguien del grupo que haga una documentación en markdown más frecuentemente que yo te pueda ayudar más.
Desde luego si te ha gustado el del README.md del screen-logo, ese precisamente lo hice con las herramientas que te comento.

Saludos
Juan Manuel Rico

 

[Juan Gonzalez Gomez]

Yo uso Atom, con el plug-in que tiene para markdown. Me divido la pantalla en dos y veo el texto en un lado y el renderizado en tiempo real en otro

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/f912e797-b982-4fac-bd1e-9d8c09a5f6f7%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Juanma Rico]

Idem pero con Notepad++ desde Windows. :))
No es por supuesto el renderizado final que hace github... pero sirve para hacerse una idea. :)))

Saludos

Juan Manuel Rico

[José Raúl Montero Ponce]

Buenas, a ver si me podeis ayudar, estoy haciendo un controlador vga y tengo estos 2 archivos, pero cuando sintetizo me dice que el archivo no pertenece al diseño.
Os paso los archivos. gracias

[Sergio Cuenca]

te falta la primera linea para incluir el fichero .v

// @include vga_controller.v

si te gusta el tema vga quizás te interese esta collección: 

https://github.com/sergicuen/collection-iPxs

Saludos

[José Raúl Montero Ponce]

Creia que al estar comentada no valia

[Juanma Rico]

Es un "truco" que usa icestudio para integrar el fichero sin que afecte al código Verilog.
Para Verilog está comentado, para icestudio no. ;))

Saludos
Juan Manuel Rico

[Jose Raul Montero Ponce]

Muchas gracias. voy a probarlo

[Jose Raul Montero Ponce]

Nada, "invalid module instiantation"

El miércoles, 22 de noviembre de 2017, 7:23:36 (UTC+1), Juanma Rico escribió:

[Juanma Rico]

Buenas José Raúl,

Como te veía atascado y para que no te desanimaras... en un "ratillo robado" a la mañana me he descargado los ficheros y los he probado.

A parte de lo que te comentaba Sergio, en el código del vga_controller.v había errores de escritura (algún "bengin" y "vcnout"... ¡¡Cuidado con las "enes"!! ¡¡Que se te cuelan!! jejejeje) 

Te adjunto los ficheros ya corregidos... ¡¡Atención!! Solo los he verificado, no sé si hacen lo que quieres que hagan, no los he sintetizado ni tampoco simulado, pero ya pasan una primera verificación y así sigues a partir de ahí. :))

Saludos

Juan Manuel Rico

[José Raúl Montero Ponce]

Gracias Juanma. Las carreras es lo que tienen. Bueno he aprendido que cuando da ese fallo es por que hay algo mal en el modulo. De todos modos, estudiando tu codigo, me he dado cuaenta que hace lo mismo. Asi que me quedo con tu codigo(que ya entiendo) y sigo avanzando. Muchas gracias por todo.

[Jose Pico]

Hola Juanma:

El del pájaro azul puede ser "harropad" ?

Yo me lo acabo de instalar y lo estoy probando un poco, por las pocas pruebas que he realizado parece que este acepta mucas más cosas que lo que realmente luego visualiza el wiki de Github por lo cual entiendo que si se usa de forma básica puede ser útil y cómodo ( entiendo que no hay que introducir por ejemplo códigos htmls que si 

entiende el harropad pero que luego la wiki de Github no entiende tan bien )

Saludos

[Juanma Rico]

Buenas José

Sí, puede ser... he buscado el logo y sí, me suena.
Creo que este es el me dejó hacer un TOC (table of content) y luego no se veía en Github. :(((
Hay que tener cuidado, te dejas llevar y luego... trabajo perdido (al menos para publicar en Github)... :((

Saludos
Juan Manuel Rico

[Jose Pico]

Si permite un TOC.

Supongo que es prudente probar un poco las opciones antes de lanzarse a realizar la biblia en pasta y luego llevarte una sorpresa.

Por otra parte lo veo cómodo ya que en Notepad supongo que tendrás que saberte las marcas de Markdown de memoria ( aunque en realidad son pocas )

Saludos

[Juanma Rico]

Sí, las marcas te las debes saber de memoria.
También puedes definirlas mediante macros, pero la verdad es que no sé si merece la pena (o si ya está hecho por alguien).

Al final te las aprendes por pura desidia... jejejejeje

Saludos.
Juan Manuel Rico

[1138-4EB]

Hola Jose, Juanma,

Si no he entendido mal, estáis hablando de un editor WYSIWYG para markdown que soporte las extensiones del lenguaje reconocidas en GitHub. Como opción más rápida yo utilizo la previsualización de Atom (Packages > Markdown Preview > Toggle Preview; o Ctrl+Shift+M). También he oído muy buenas críticas Typora.

El la práctica, mi opción preferida es Hugo. Es en sí un generador de webs estáticas, pero el mismo binario incluye un servidor con livereload, por lo que se puede utilizar como visualizador dinámico. Una ventaja/posibilidad que ofrece Hugo, a mayores, es publicar en GitHub Pages las mismas fuentes que se muestran en la wiki de GitHub, sin necesidad de modificar nada. Esto permite diseñar una visualización sin todo el "ruido" de GitHub, de forma que el contenido se muestre más limpio y sea más fácil navegar. Naturalmente Hugo ofrece muchas posibilidades, además de las cubiertas en GitHub, como por ejemplo la generación automática de ToC o shortcodes. Por lo tanto, deberemos limitarnos a las características más básicas si queremos que el contenido íntegro se vea bien en GitHub. Los parsers soportados por Hugo son:

https://github.com/russross/blackfriday
https://github.com/miekg/mmark

Saludos

[Jose Pico]

Muchas Gracias Unai.

Como siempre posees más información que el propio Google. jejejjejejje

Saludos

[1138-4EB]

Más bien, sucede que ya me he leído las dos primeras páginas de Google XD

[Jose Pico]

jejejejeje