[ACC0-Apolo]

[Miquel Servera]

Hola, llevo unos días jugando con el tutorial  del ACC0 creado por Obijuan pero no consigo hacerlo funcionar, lo he creado todo desde 0 para ir aprendiendo como funciona, pero al ejecutar el script de python y crear el archivo rom.list en vez de crearse un archivo como el de Obijuan se me crea uno con 1028 lineas de código en el cual todo son ceros excepto las tres primeras posiciones cuyo resultado es:

//-- Original file: test.ags.bin
//-- Output file format: verilog
//-- AGC Opcodes in hex
//-- Initial address: 0x800

0800
0801
7000

No se si sera que debo ejecutar el script antes de crear el bloque de memoria ya que al escribir la instrucción 

parameter ROMFILE = "rom.list";

me daba error al no encontrar dicho archivo, lo pregunto para saber si el error puede ser este antes de borrar lo que tengo hecho y ponerme a escribir todo el código otra vez.

Saludos.
   

[Juanma Rico]

Buenas Miquel,

Yo le eché un ojo hace tiempo y espero acordarme.
Como lo había borrado y ando un poco saturado con el SPI (¡¡¡no me funciona!!! :SSS ), he leído tu mensaje y lo he vuelto a descargar desde github.

He sintetizado el ACC0 (con apio) y me ha ido de escándalo... imagino que esto ya te funciona a ti también y lo que quieres es cambiar el código que ejecuta el ACC... (lógico).

El script si no recuerdo mal y como tú bien dices, lo que hace es tomar el fichero de texto y generar el "rom.list" (código binario puro y duro), es decir, es un ensamblador para el micro ACC y esto es lo que (junto a la estructura del micro) se graba en la FPGA.

Evidentemente si no encuentra el fichero "rom.list" no te va a funcionar (se te va a parar en ese error).
Busca el motivo del porqué no encuentra el fichero. Comprueba antes si se genera, puede ser que tengas un error en el fichero de texto y el script no te lo genere y así es difícil de que yosys lo encuentre.

Si quieres cuelga el fichero de texto y yo lo intento por mi cuenta (cuatro ojos ven más que dos) a ver si te puedo ayudar más.

Saludos.

[Juanma Rico]

Perdona Miquel, tantas ganas de ayudarte tenía que te he contestado sin revisar el script, jajajajaja

He mezclado lo que se hace en el Simplez-F con lo que se hace en el ACC.

El script de ACC (si hablamos del fichero acc-rom.py) lo que hace es tomar el binario que te genera el yaYUL (este sí es el ensamblador de los ficheros de texto... :)) ) y pasarlo a código que entienda el Verilog para integrarlo en la síntesis de la FPGA (el "rom.list").

Es decir, es una conversión de binario proveniente de yaYUL a texto entendible por Verilog... (doy permiso a Obijuan para que me dé una colleja si no es así... :))) ).

Con lo que imagino que ya estás usando el YaYUL para compilar, si el yaYUL no te dió error, tendrás un binario que deberás convertir con el script de Python y este tampoco darte error... sea como fuere, si incluyes los ficheros les echo un vistazo... :)))

Saludos.

[Miquel Servera]

Gracias Juanma por tu respuesta, te cuento lo que he estado haciendo hasta el día de hoy. Lo primero que hice fue coger todos los bloques usados por Obijuan en icestudio y crear unos de nuevos exactamente iguales, por la sencilla razón de poder estudiar el código así como lo iba escribiendo, y ahí me di cuenta que al crear el de la rom al verificar me daba error al no encontrar el "rom.list", con el consiguiente problema de no crearse el bloque, y opte por usar el de Obijuan, una vez creados todos los bloques procedí a conectarlos y verificar, luego usando yaYUL cree el .bin, para después crear el fichero rom.list el cual cambie por el que tenia en la carpeta del proyecto que era el que había usado para poder crear el bloque de la rom y al sintetizar y cargar en la Fpga no me funciona y al editar el rom.list creado por mi no coincide con el de Obijuan.
Creo no haberme dejado nada...





El martes, 30 de mayo de 2017, 20:12:56 (UTC+2), Miquel Servera escribió:

[Juanma Rico]

Me pillas sin ordenador... ¿ninguno te dio errores al generar el rom.list?

Si estás usando icestudio yo lo que haría es comprobar que todos los bloques funcionen con el rom.list de github.

Cuando veas que funciona todo, entonces intenta generar tu propio rom.list...

De todas formas mañana miro tus ficheros y veo si encuentro el error.

Saludos.

[Miquel Servera]

Voy a ver si hoy tengo un momento para probar lo que comentas y así descartar que el error pueda estar en la creación de algún bloque, ¿Puede influir no tener todas las herramientas en el mismo directorio aunque luego tenga todos los archivos en la misma carpeta?

Saludos.

[Juanma Rico]

Buenas Miquel,

Creo que he encontrado el error... está en la compilación de yaYUL.
Te lanza el siguiente mensaje:

test.ags:4: Fatal Error: Symbol "" undefined or offset bad

Mirando tu fichero veo que has sustituido los tabuladores por espacios, al parecer yaYUL necesita que sean tabuladores. Una vez cambiados me ha compilado sin problemas. Te adjunto tu fichero modificado con los tabuladores. Prueba y nos cuentas.

Saludos.

[Miquel Servera]

Voy a probar lo que comentas, aunque yo no tenia ningún tipo de error.

[Miquel Servera]

No podía estar sin probarlo, me genera el mismo "rom.list"

[Juanma Rico]

A mi me lo ha generado bien, estoy casi convencido que existe un error de tabuladores...

¿Seguro que en tu editor de texto no tienes activada la opción para que automáticamente los tabuladores se modifiquen por espacios?

De todas formas, para descartar...

• El adjunto que te he enviado, compílalo con el yaYUL directamente (sin abrirlo en tu editor) y comprueba que no te da errores.
  

• Confirma que el fichero que editas no tenga tabuladores (haz por ejemplo un "hexdump -C test.ags.bin" y busca si hay tabuladores (09) después de un retorno de carro (0A), o ábrelo con otro editor que muestre los tabuladores de forma visual).
  
  
• Toma un test.ags.bin que sepas esté bien compilado y ejecuta el acc-rom.py a ver si lo hace correctamente y genera el fichero verilog correspondiente.
  

Ya nos cuentas.

Saludos.

Pdta: Veo en la captura que usas Kate y tienes activada la opción de "tabuladores débiles"... revisa eso... ;)))

[Miquel Servera]

Después de 4 días con lo mismo ya empiezo a cansarme.

[Juanma Rico]

No te desanimes hombre. Eso tiene que funcionar.
Dime, ¿qué tal fueron las pruebas que te dije? ¿alguna conclusión?
¿Quitaste del Kate el tema de los tabuladores débiles?

[Juanma Rico]

Buenas Miquel,

He vuelto a probar tu fichero, tal y como los enviaste no van, elimino los tabuladores y funciona.
Este parece ser un problema localizado, luego si te sigue fallando es otra cosa.

No te centres en la generación del "rom.list", eso es una parte del ejercicio, pero no la única.
Busca los errores en otro lado. Si tu problema es que no tienes el "rom.list" no te atasques, yo te incluyo los tres ficheros ya generados y "tira palante". :))))

Si con estos que te adjunto tampoco funciona, usa los bloques de Obijuan, si tampoco, ya hay que buscar en como iceStudio maneja el tema de los bloques, la "rom.list" y demás... en eso ya te puede ayudar más Jesús, pero descarta cosas, como decía Sherlock Holmes... «Cuando eliminas toda solución lógica a un problema, lo ilógico, aunque imposible, es invariablemente lo cierto». :)))

Todo el tiempo que le dediques es tiempo de aprendizaje (llevas cuatro días aprendiendo), así que no te desanimes. :)))

Ya nos cuentas.

Saludos.

[Miquel Servera]

Desanimarme como que no, como editor he cambiado, uso Atom, creo que algo estoy haciendo mal ya que usando el ejemplo de Obijuan y sin modificar nada lo cargo en la Fpga y funciona correctamente, pero aunque modifique el archivo test.ags lo compile nuevamente cree un rom.list nuevo y sintetice el ultimo binario en la Fpga sigo teniendo el mismo de antes, y pregunto:

¿Debo tener todas las herramientas en el mismo directorio?
¿Cual es el camino a seguir?
 
Lo que yo hago primeramente es con Icestudio crear el circuito, escribo el código del archivo con extensión ags, compilo con yaYUL, creo el rom.list y por ultimo en Icestudio Build y Upload.

¿Que me estoy dejando?

Gracias.

[Juanma Rico]

Bien, bien... sin desanimarse... :)))

Perfecto, has cambiado de editor, (¡Atom al poder! :))) pero por cerrar temas y por si alguien tiene el mismo o parecido problema con los tabuladores... me instalé Kate (no uso KDE, uso Mate) y efectivamente, como sospechaba, lo que hace la opción de los "tabuladores débiles" es sustituir automáticamente espacios por tabuladores.

Para eliminar este comportamiento de manera fácil solo hay que pulsar y elegir "tabuladores" en el menú desplegable que te muestra.

Y si se quieren mostrar los tabuladores (y evitar sorpresas) elegir la opción "Ver->Mostrar espacios no imprimibles". Aparece entonces una doble ">>" para indicar que en ese punto existe un tabulador.

Dicho esto...
No sé a qué te refieres con "herramientas", si te refieres a yaYUL (el compilador) o al script (acc-rom.py) que usaste para generar el "rom.list" (por favor, sácame de dudas... ¿Ya lo puedes generar sin errores? :)) )
Mi respuesta es afirmativa y rotunda: NO  :))) jejejejeje

Lo importante es que tengas el "rom.list" en el mismo subdirectorio, eso sí. El "rom.list" es la "memoria" que junto a la estructura del ACC se sintetizará y grabará en la FPGA (bueno en realidad en la flash que le acompaña... digamos que se graba en la iceZUM Alhambra... :))) )

Tampoco me queda claro donde "tropiezas"... me dices que haces Build y Upload... ¿se te descarga entonces en la iceZUM Alhambra? ¿Sin errores? ¿Qué es lo que falla? ¿Quizás el comportamiento esperado?

Si me aclaras esto podemos seguir des-desanimándonos (¿Una doble negación es una afirmación...? :))) ).

Saludos

[Juanma Rico]

Buenas Miquel,

Me he estado peleando con iceStudio (versión "develop") para hacer funcionar el ejemplo que adjuntaste.
No ha funcionado. Incluso lo he exportado a Verilog y lo he sintetizado con apio... tampoco ha funcionado.
Después de algunas pruebas he llegado a algunas conclusiones:

• Lo dicho, yaYUL necesita tabuladores, no espacios (con espacios da error de compilación).
• Los únicos ficheros que debes tener en la carpeta donde grabes desde iceStudio es el fichero "ice" y el rom.list. (De hecho si usas "Guardar como" y utilizas una carpeta limpia iceStudio te copia el fichero rom.list automáticamente).
  
  
• El ejemplo de ACC0 es muy (pero muy...) antiguo para el desarrollo actual de iceStudio.
  Lo primero que te encuentras es que, en la versión antigua de iceStudio, los bloques están separados en distintos ficheros:
  
  ACC0.ice
  Reg-G-master.ice
  rom2Kx15.iceb
  Reg-S.iceb
  rom2Kx15-master.ice
  Reg-G.iceb
  Reg-S-master.ice
  
  
• Si abres el principal (ACC0.ice) con una versión actual de iceStudio automáticamente te los agrupa en uno solo y es con ese con el que se trabaja, el resto, una vez integrados, los ignora (si le das a "guardar como" en un subdirectorio limpio es lo que te hace, te copia un único fichero "ice").
  
  
• Una vez ya convertido y abierto hay bloques anticuados, pero funcionan, el problema está en bloques como este:
  
  
  
  

  
  Si los dejas, los botones no funcionan (si no recuerdo mal es un antiguo bloque pull-up que se necesitaba para las primeras versiones de la iceZUM Alhambra), quítalos y únelos al antirrebote directamente si tu iceZum Alhambra es una versión 1.1 (casi seguro).
  
  
• Con estos cambios este ejemplo ya funcionaría. Podrías cambiar el rom.list y al sintetizar el circuito tomaría el nuevo. Al pulsar los botones subirías y bajarías por la memoria iluminando los leds según el nuevo rom.list (imagino que hasta aquí es hasta donde has llegado).
  
  
• El problema viene cuando quieres modificar el circuito (o como es tu caso quieres reproducir los bloques), primero: los bloques del circuito original no se pueden modificar (los puedes ver, pero no modificar) y ya perdiste la referencia a los bloques originales. Segundo: Si aún así copias los bloques del original a uno nuevo (creo que me decías que esto es lo que también habías probado) la cosa tampoco funciona. Tercero: Si creas un bloque desde cero, tampoco funciona.
  
  Es decir, parece ser que un fichero base que sea una exportación de un fichero antiguo parece quedar "contaminado" y cualquier cambio que hagas no va a surtir el efecto deseado (por lo menos en el ejemplo del ACC0... a mi me han hecho cosas raras hasta asignaciones directas de leds).

He intentado mirar como se guarda el código en un fichero Verilog exportado desde uno ice para comparar el que funciona con el que no y te encuentras muchas referencias automáticas del estilo:

module v25915d (
 input vf68f06,
 input vb8b63b,
 input v053ebd,

Que hace muy difícil encontrar algún tipo de error... sinceramente, además... me ha dado pereza. :))))

Por tanto, como conclusiones... no desesperes, que no es tu culpa, es culpa de "algo" que pasa en la exportación de un proyecto antiguo a uno nuevo (este "algo" es mejor que se lo preguntes a Jesús que es el que te puede responder en este caso).

¿Cómo podría funcionar otra vez el ejemplo de ACC0 (y poderse editar para aprender) con las nuevas versiones de iceStudio? Pues sospecho que si Jesús no encuentra la solución habrá que rehacer todo el ejemplo desde cero, con los nuevos bloques y desde la nueva versión. (Yo he tenido que hacerlo alguna que otra vez, no es muy complicado).

Lo que no sé es qué solución se le ha dado en las nuevas versiones de iceStudio (yo lo he retomado después de mucho tiempo) a eso de editar los bloques internos de un proyecto una vez creado... eso también te lo podrá contestar Jesús.

Siento no haberte podido ayudar más, yo hice estos ejemplos en las primeras versiones y no creía que con las nuevas podía dar tantos problemas... por eso, como dice Goyo... "me vine a arriba" para intentar ayudarte y al final me he visto superado... jajajajaja   :)))

Saludos.

[Miquel Servera]

No encuentro el emoticono que se tira de los pelos, de todos modos me prometí no abandonar a la primera de cambio por lo cual estoy decidido a seguir adelante hasta donde pueda, eso si, a ser posible con vuestra ayuda.

Juanma, Muchas Gracias.

Saludos!

[Jesús Arroyo]

Buenas a todos:

He probado directamente el ACC0.ice del tutorial de Obijuan con el rom.list que viene por defecto:

• Sintetiza y descarga correctamente con Icestudio 0.2.3
• Sintetiza y descarga correctamente con Icestudio 0.3-dev

¿Cuál es el problema entonces? Pues parece que hay una diferencia entre la IceZUM v1.1 y la IceZUM v1.0 (que es con la que está hecha el tutorial) que hace que la v1.1 no funcione correctamente con este diseño ACC0. Concretamente parece que no captura bien el botón SW1:

El ACC0 permite navegar por la rom con SW1 (+) y SW2 (-). Al pulsar los botones no pasa nada porque parece que SW1 no captura los pulsos y SW2 navega en direcciones "negativas". He probado a cambiar los botones SW2(+) y SW1(-) y he comprobado lo siguiente: al pulsar SW2 avanza en la memoria, pero al pulsar SW1 no retrocede. Tampoco funciona correctamente sustityendo los bloques de antirrebotes. Por lo tanto es una cuestión de la electrónica y el diseño del ACC0, no de las herramientas.

Probad directamente los ficheros de GitHub con Icestudio 0.3 pero intercambiando los botones SW1 y SW2 para ver si da el mismo resultado. Adjunto videos de las pruebas:

- https://drive.google.com/open?id=0B_vQY-TVqNFYYzN1UGNXaVVMb3c

- https://drive.google.com/open?id=0B_vQY-TVqNFYZ2tlbEZwZ0tVYzQ

- https://drive.google.com/open?id=0B_vQY-TVqNFYRGhTWVgwekZQdjA

Juan, Eladio, si tenéis un momento y podéis aportar algo de información al asunto sería de gran ayuda para resolver el expediente X. ;)

Un saludo.

PD: tenemos pendiente migrar ACC a Icestudio 0.3 para utilizar las nuevas features como buses, constantes, etc. Pero la versión actual, creada con Icestudio 0.2 es completamente funcional en 0.3.

[Miquel Servera]

Hola Jesús, igual soy yo que estoy haciendo algo que no debo o me dejo algo sin hacer, si clono el repositorio de github, lo abro en Icestudio  lo compilo y cargo en la Fpga este funciona perfectamente sin errores, eso con la versión 0.3.0-rc, lo que no me funciona por ejemplo es si modifico el test.ags (cambio la secuencia de los led's) lo compilo nuevamente con yaYUL, creo un rom.list nuevo luego voy otra vez a Icestudio build y upload en la IceZum sigo teniendo la secuencia de led's que tenia antes sin modificar.

Gracias

[Jesús Arroyo]

Ok, vamos a concretar.

Si descargas la versión de GitHub directamente funcionan los botones SW1 y SW2 para moverte por la memoria? Es decir, no tienes el comportamiento que me sucede a mí en el video?

Segundo asunto: al modificar el rom.list no se carga la modificación: asegúrate de que el rom.list está en el mismo directorio que el .ice y que realmente se modifica: https://github.com/Obijuan/ACC/wiki/ACC0#ensamblar-testags-y-generar-la-rom. Por ejemplo. yo he hecho una prueba modificando el rom.list directamente y luego ejecutando Tools > Upload (cambiando  el primer valor de la memoria).

Como hay muchos componentes implicados en el proyecto es mejor ir paso por paso analizando y descartando posibles causas.

Un saludo.

[Juanma Rico]

Con permiso Jesús,

Le estás haciendo repetir las pruebas que ya he hecho yo y que he explicado (peor o mejor en el post anterior).

El ACC0 de Obijuan de github funciona sin problemas, siempre que elimines los bloques antiguos de pull-up, el antirrebote antiguo funciona, no es necesario cambiarlo para que funcione con la placa 1.1 (como he puesto en mi anterior post) únicamente el pull-up.

El tema de la rom.list ya lo he dejado también claro, es un problema de tabuladores y del yaYUL, si lo modificas directamente con un editor que no cambie tabuladores la secuencia de valores cambia sin problemas (siempre que fuerces de nuevo la síntesis ya que apio (hasta la versión más actual) no detecta los cambios en el fichero rom.list).

El problema ya está reducido, es un tema de "exportación-adaptación" del formato antiguo de iceStudio al nuevo en forma "compacta" siempre que en esta adaptación obtenida se intente modificar de alguna manera alguno de los bloques que conectes. (si eliminas como es el caso del pull-up parece que funciona, pero si, por ejemplo copias un bloque que funciona de una ventana a la que estas modificando, esta última deja de funcionar correctamente).

Al bloque ("hardware" como tú dices) en principio no le pasa nada puesto que en una ventana funciona, pero al copiarlo y conectarlo deja de funcionar correctamente.

Por si te sirve de pista, se exporta un esquema completo que funciona (p.j. el ACC0 de github sin los pull-up) en Verilog, se sintetiza apio y se graba en la tarjeta y sigue funcionando. Si se exporta uno que no funciona... sigue sin funcionar (de hecho el comportamiento fallido es el mismo), es decir... como conclusión: es una "cosa interna" que sucede al conectar o modificar un ejemplo antiguo convertido y compactado que funciona con cosas nuevas que se no estaban en el esquema original (si cambias el antirrebote antiguo por uno nuevo también funciona)...

Espero mi esfuerzo de esta mañana sirva para algo y te sirva para centrar el problema.

Saludos.

[Juanma Rico]

Miquel... ¡Que nooooo!

Que no es cosa tuya hombre... que yo he hecho lo mismo y no va... jajajajajaja :))))
¡¡Que ganas de autoflajelarse!! jajajajajaja :)))

Saludos.

El jueves, 1 de junio de 2017, 17:49:53 (UTC+2), Miquel Servera escribió:

[Juanma Rico]

Fé de erratas... no sea que nos liemos por dos palabras... :))

[..] sigue sin funcionar (de hecho el comportamiento fallido es el mismo), es decir... como conclusión: es una "cosa interna" que sucede al conectar o modificar un ejemplo antiguo convertido y compactado que funciona con cosas nuevas que no estaban en el esquema original (si cambias el antirrebote antiguo por uno nuevo tampoco funciona)...

[Miquel Servera]

Escrito por juanma Rico El ACC0 de Obijuan de github funciona sin problemas, siempre que elimines los bloques antiguos de pull-up tengo que decir que a mi me funciona tal cual esta sin eliminar ningún bloque, lo que si me pasa Jesús es que si modifico el test.ags y lo compilo, al leer la rom.list nueva todo son ceros excepto las tres primeras posiciones:

//-- Original file: test.ags.bin
//-- Output file format: verilog
//-- AGC Opcodes in hex
//-- Initial address: 0x800

0800
0801
7000

[Miquel Servera]

Si copio el rom.list nuevo, el que posteo en el mensaje anterior dentro de la carpeta ACC0 creada por Obijuan y lo grabo en la IceZUM la secuencia de los led's es:
INICIO = 00010000
SW1 = 00001110
SW1 = 00000000
No se si sera la correcta con el rom.list que tengo o no porque no se como comprobarlo eso si no coincide con la del test.ags modificado.

[Miquel Servera]

Perdón, se me ha olvidado comentar que luego con el SW2 se decrementa hasta volver a la secuencia de INICIO,

[Juanma Rico]

¿tienes una iceZUM Alhambra 1.0 (blanca)?
A mi si no quito los bloques de pull-up con la 1.1 no me funciona (y por los vídeos que ha colgado, a Jesús tampoco).

[Juanma Rico]

Los numeros que ves son los números que se tienen que reflejar en los leds. Los pulsadores lo único que hacen es moverse por la memoria e ir mostrandolo en los leds a modo de cursor.
Es evidente que no es tu caso...
Por curiosidad Miquel, ¿has probado esto mismo quitando los pull-up?

Saludos

[Juanma Rico]

Miquel tengo que dormir, pero la clave está en mi misma frase que has reproducido...

El ACC0 de Obijuan de github funciona sin problemas, siempre que elimines los bloques antiguos de pull-up

"Sin problemas"... si te da problemas elimínalos y pruebas. ;)))

Saludos.

[Miquel Servera]

Hola Juanma la mía es la 1.1, no había probado de quitar los pull-up los he quitado ahora y hace lo mismo, si he podido comprobar que se decrementa e incrementa de forma correcta, por ejemplo, si después de la ultima secuencia le doy 10 veces al sw2 y luego otras 10 al sw1 vuelvo a la secuencia que tenia antes de decrementar y viceversa.

[Juanma Rico]

Bueeeeno, ha costado unos cuantos post pero hemos avanzado algo. :)))

Ahora comprueba que los leds te están mostrando en binario la lista de números que tienes en el rom.list.

Luego modifica el fichero rom.list directamente y al sintetizar debe cambiarte la secuencia.

El tema de los ceros en el fichero puede ser por un error en la conversión, ya sea culpa de yaYUL y sus tabuladores, o por culpa de python y sus versiones o lo que sea... pero eso no es importante de momento, lo importante es que icestudio integre bien tus modificaciones y las del rom.list (que puedes hacer directamente con cualquier editor)

Icestudio usa apio y ya he detectado que apio 0.2.3 no detecta las modificaciones de rom.list, así que tampoco desesperes... verifica, sintetiza y carga las veces que haga falta si ves que no sigue la secuencia que acabas de modificar...

Mi mujer me mata si tengo el teléfono encendido desde la cama... y ya me está poniendo mala cara... así que mejor lo vemos mañana.... por aquello de no correr riesgos innecesarios... jajajaja :)))

Saludos.

[Juanma Rico]

¡¡Ya despierto!! jajajaja :)))

Bueno Miquel,

Ya para completar el asunto... cuando veas que poniendo números en la rom.list y sintetizando de nuevo se te refleja en los leds... y todo funciona como debe...

La segunda parte... si modificas ese mismo esquema que ya te funciona introduciendo un nuevo bloque o reproduciendo uno (para aprender), verás como el ejemplo te deja de funcionar.

En este punto es donde te digo que no te flajeles... (¿implica el "auto"?) :)))

No es culpa tuya, es algo que ocurre en la conversión de un antiguo formato de icestudio en uno nuevo cuando modificas un bloque.

Aquí es cuando te digo que no te atasques... que eso ya lo tiene que solucionar Jesús y hay que esperar.

La única solución que veo si no quieres esperar y quieres aprender modificando... es que empieces un fichero nuevo con la nueva versión (0.3.0-rc) y reproduzcas todo desde cero, sin aprovechar nada de los bloques del ejemplo. Tampoco copies y pegues los bloques... desde cero es desde cero... ;))

Si lo terminas y funciona, puede ser una buena aportación para los que usan o van a usar por primera vez iceStudio. Seguro que Obijuan estará encantado de integrar tu actualización al proyecto de ACC. :)))

Espero haberme explicado mejor esta vez.

Saludos.

[Jesús Arroyo]

Juanma, te agradecería que dejaras a la gente reportar lo que les pido. Resulta un poco molesto dar soporte con tanto ruido. Además las conclusiones que has obtenido con respecto a Icestudio no son correctas.

[Miquel Servera]

Buenos dias, lo que tengo hasta ahora es lo siguiente, a mi Jesús con el ejemplo de Obijuan sin eliminar bloques ni nada o sea el .ice tal cual esta me funciona correctamente tanto el SW1 como el SW2, no tengo el problema que tienes tu, pero creo que el error puede estar en la manera en que el script de python crea el rom.list, porque si modifico dicho archivo manualmente y lo cargo en la Fpga ejecuta la secuencia tanto hacia arriba como hacia abajo de forma correcta, siempre hablando del ejemplo de Obijuan, el que cree yo al principio del tema no lo he probado.

Saludos y Gracias a los dos.

P:D: Y por favor tengamos la fiesta en paz.

[Jesús Arroyo]

Hola Miquel,

Como decía, de los dos problemas aparentes con el ACC0 y la IceZUM v1.1 parece que tú sólamente tienes el de la rom. Por asegurar:

• Te funciona correctamente el ejemplo de GitHub, verdad? La síntesis descarga y los botones SW1 y SW2.
• Tu problema es que no genera correctamente la rom.list a partir del test.ags.

Ahora bien, por favor realiza una prueba:

1. Partiendo del proyecto ACC0 tal cual está en GitHub prueba a cargarlo en la placa.
2. A continuación modifica a mano el fichero rom.list: cambia el primer dato de la memoria (4000) por (7FFF).
3. Desde Icestudio descarga de nuevo el bitstream Tools > Upload.

El resultado es que se deberían encender los LEDS del 0 al 6. Las demás instrucciones funcionarían como antes. Adjunta por favor el fichero rom.list modificado por ti para que pueda verificar que es correcto.

El siquiente paso es concentrarnos en la síntesis del fichero rom.list a partir de test.ags. Este proceso no tiene que ver ni con Apio ni con Icestudio, sólamente con la toolchain del AGS: https://github.com/Obijuan/ACC/wiki/ACC0#instalar-la-toolchain-del-ags. Vamos a realizar otra prueba:

1. Partimos del test.ags que viene por defecto en GitHub, ACC0.
2. Elimina el fichero rom.list
3. Ejecuta las siguientes instrucciones: https://github.com/Obijuan/ACC/wiki/ACC0#ensamblar-testags-y-generar-la-rom

1. yaYUL test.ags

2. acc-rom.py test.ags.bin

3. NOTA: el fichero acc-rom.py lo encuentras aquí: https://github.com/Obijuan/ACC/tree/master/tools/acc-rom
4. Esto debería generar el fichero rom.list idéntico al del repositorio.

Si esto no sucede significa que hay un bug en la toolchain o el script. Si funciona correctamente pasamos a la siguiente prueba:

1. Modifica el fichero test.ags (y lo adjuntas al correo)
2. Repite el mismo proceso anterior y adjunta el rom.list generado

Sé que esto puede ser algo minucioso, pero es necesario para depurar un proceso en el que hay tantos subprogramas implicados.

Con toda la información que proporciones obtendré unas conclusiones y continuaremos avanzando.

Gracias.

Un saludo.

NOTA: el problema de que no funcionan los botones SW1 y SW2 con la IceZUM v1.1 y ACC0 (que yo he conseguido reproducir pero que parece que tú no tienes) lo trataramos a parte ya que puede tener causas en el hardware, tiempos de carga, etc.

[Jesús Arroyo]

Buenas Miquel,

Justo te has adelantado al correo que estaba escribiendo!! :)

Es la respuesta de las pruebas que te pedía. Se cumple lo que yo pensaba, por lo que pasamos directamente a la última prueba que es la de modificar el test.ags y generar el rom.list.

Adjunta por favor el fichero modificado test.ags y el rom.list para hacer un análisis de la toolchain AGS y el script acc-rom.py.

Un saludo.

[Juanma Rico]

El ruido para unos es música para otros, es cuestión de sensibilidades... :)))
pero sí, te entiendo y pido disculpas... necesitas un poco de calma.
Estaré pendiente a tus conclusiones. Todo tuyo.

Saludos.

El viernes, 2 de junio de 2017, 9:31:15 (UTC+2), Jesús Arroyo escribió:

[Jesús Arroyo]

Buenas Juanma,

Símplemente me resultaba confuso que por un lado dijeras que hace falta mi ayuda, por otro que no son necesarias unas pruebas que pido y finalmente que asumas que tengo que correjir algo que además no es correcto.

Yo sé que todos estamos aquí para avanzar y para ayudar!. Y desde luego es de agradecer el feedback y las opiniones pero quizá juicios precipitados puedan añadir más confusión por lo que es mejor hacer un análisis detallado y paso a paso.

Por mi parte todo OK. A seguir frikeando que es lo que nos gusta y no hay nada que con unas cañas no se pueda solucionar!

Un saludo.

[Juanma Rico]

A ver... por alusiones... y ya te dejo trabajar y dar soporte a tu ritmo.

Yo no digo en ningún momento que no sean necesarias las pruebas que pides, te digo que esas pruebas ya están hechas, las hice yo. Me "arremangué" y las hice en un intento de que Miquel no acabara "mareado" después de cuatro días de intentos y viendo que estaba desanimándose con el tema.

Después de hechas, las he resumido en un post, por supuesto las he resumido fatal porque nadie las ha leído con detenimiento y no se ha probado lo básico que yo estaba indicando... (como lo de eliminar los pull-ups).

Ese puede ser un error mio de comunicación, muchas veces creo que con una frase la cosa se entiende o surte el suficiente efecto como para provocar en el maker que la lee... "¡¡eso no se me había ocurrido!! ¡¡Lo voy a probar!! ¡¡Gracias!!"... pero veo que no es así y es algo a mejorar por mi parte.

Igual mi error es que soy más de "provocar" que de dar instrucciones paso a paso (quizás porque pienso que las recetas de cocina están bien, pero a la larga te hacen mal cocinero).

Todo esto unido a que en el siguiente post veo como tú vuelves a "marear" (entiéndase bien, no te tomes a mal la palabra) a Miquel con los botones (que tiene fácil solución, quitar los pull-ups como había dicho en el post) y con el fichero test.ags y la compilación de yaYUL (que es un paso intermedio y no es necesario para generar el rom.list)...

Ambas cosas son interesantes de investigar, pero por mi parte yo le estaba dando más importancia (sin decirlo explícitamente, igual aquí está mi error, como siempre...) al hecho del paso siguiente... y que de forma natural iba a dar Miquel,... lo hemos dado todos:

Cuando ya el ejemplo le funcionara, lo iba a querer modificar "a ver qué pasa"... "¿y este valor en qué afecta?... ¿y si le pongo 4 en vez de 8?"... Todos lo hemos hecho y te da un "subidón" cuando lo que imaginabas se cumple... (normalmente en forma de lucecitas... :)) ).

Y quizás quería evitarle este paso que iba a dar... y que es lo que más frustración le iba a traer (y que por experiencia he sufrido)...  porque al modificarlo no le iba a funcionar e iba a pensar que era culpa suya (como así ha sido, no es una conclusión mía, es un hecho...).

Por eso mi recomendación era (que igual tampoco me he sabido explicar bien) que una vez que pruebe el ejemplo, si quiere rehacer un bloque y no frustrarse a mitad (o tirarse de los pelos), que lo haga todo desde cero, sin aprovechar nada del ejemplo hecho con una versión antigua (¿la 0.2?) porque no se sabe (yo tampoco lo sé, eso te lo dejo a ti y ahí es donde le decía que te pidiera ayuda) en qué está afectando la "conversión-adaptación" de un fichero antiguo a uno nuevo... esto provoca que no se comporte como debería (al menos en el caso del ACC0, en otro no he probado).

Si ha eso le quieres decir que es una "conclusión" por mi parte... de acuerdo, lo es, llamémosle así, pero no me digas que es errónea porque para mi es un hecho (lo he comprobado, funciona, no funciona... ensayo-error...)

Otro hecho es que Icestudio usa apio 0.2.3 (¿O no?) y otra "conclusión" que he aportado (haciéndome entender o no) es que apio 0.2.3 no detecta las modificaciones de la rom.list, con lo que si se modifica este fichero (por el método que sea) y previamente se ha sintetizado algo (por el método que sea, apio o icestudio)... no se van a detectar cambios en el proyecto y no se va a actualizar el comportamiento en la iceZUM Alhambra cuando debería hacerlo (más frustración para el que no sabe lo que está pasando). ¿Es eso también una "conclusión" errónea por mi parte?

Bueno, pues ya está... lo es. Si te dedicas a intentar demostrar que mis "conclusiones son erróneas" (que por cierto, no lo has hecho todavía) la cosa seguirá así... errónea por mucho tiempo... si sin embargo te lo tomas no como una conclusión, sino como un hecho y simplemente, si no te fías, lo compruebas igual avanzaríamos a otro ritmo (lo digo de buen rollo...no es un ataque a tu persona)  ;)))

Pero en fin.... que cada uno aquí tiene su ritmo y que estoy de acuerdo contigo, estamos aquí para avanzar y frikear... Si Miquel se siente más a gusto con tu ritmo o tú con el suyo, por mi no hay problema... será que yo hecho de menos a Unai... jajajajajajaj :))

Nada, os dejo frikear a gusto.

Saludos.

Pdta: Dos cosas que se me olvidan; disculpas por lo extenso del post (por lo visto o me paso o no llego :)) y hace a esas cañas, si coincidimos (¿en Madrid?) invito yo. ;)).

[Juanma Rico]

Fé de erratas... también pido disculpas por algunas faltas de ortografía que se me han colado... las prisas... :))

[Jesús Arroyo]

Buenas Juanma,

Por concluir: me parece correcto el enfoque de cada cual, lo que pasa que en este caso hemos chocado en la forma de afortar los tests y analizar los resultados. Pero no pasa nada, cada uno tiene su punto de vista y al final lo importante es comprenderse ;)

En la parte más técnica te comento: no creo que haya un problema en la "conversión" de proyectos antiguos a nuevos, al menos yo no lo he encontrado. Las pruebas que he estado haciendo son cargar un mismo proyecto antiguo con Icestudio 0.2 y con el 0.3 (que incluye conversión) y se comportan igual. Como el ACC0 parece dependiente del HW, se podría aislar el test de la "conversión" con otros proyectos para analizar si realmente hay algún problema. Con las pruebas que yo he hecho he visto que todo era correcto, pero insisto, si detectamos algo en concreto siempre se puede analizar más en detalle.

Con respecto a la detección de modificaciones es cierto que apio 0.2.3 no detecta los cambios en rom.list (he creado una issue), pero esto no afecta a Icestudio ya que al generar el código verilog se añade una cabecera con la fecha y la hora. Por lo tanto en Icestudio el código siempre es distinto y por lo tanto las modificaciones que se hagan en el fichero rom.list siempre se van a sintetizar. Todo esto lo he comprobado también experimentalmente, claro.

Por eso vi que al final el problema se centraba en la generación del rom.list con la toolchain AGC. Además de esto también hemos visto que hay un posible bug con ACC0-HW para analizar en un nuevo hilo. Esta es una razón más por la que prefiero analizar los problemas con detalle ya que el stack de herramientas y posibles causas-consecuencias es muy amplio.

Un saludo.

[Juanma Rico]

Para no liarnos más... solo cosas técnicas, comentarios sin acritud y preguntas concretas.

El viernes, 2 de junio de 2017, 14:05:09 (UTC+2), Jesús Arroyo escribió:

Buenas Juanma,

Por concluir: me parece correcto el enfoque de cada cual, lo que pasa que en este caso hemos chocado en la forma de afortar los tests y analizar los resultados. Pero no pasa nada, cada uno tiene su punto de vista y al final lo importante es comprenderse ;)

Sí, está claro, no "tenemos química" en la forma de afrontar los temas (es lo que tiene desnudar almas...) puede que sea bueno no coincidir en nada o casi nada... aunque nos tenga escribiendo toda una mañana... aunque sea solo por el hecho de darle "vidilla" al grupo.... seguro que hay algún cabrón disfrutando y pendiente del hilo a la vez que anda gritando... "pelea, pelea, pelea..."  ¡Cuanto cabrón suelto! jajajajaja :))))

En la parte más técnica te comento: no creo que haya un problema en la "conversión" de proyectos antiguos a nuevos, al menos yo no lo he encontrado. Las pruebas que he estado haciendo son cargar un mismo proyecto antiguo con Icestudio 0.2 y con el 0.3 (que incluye conversión) y se comportan igual.

Vale, se comportan igual... hasta ahí de acuerdo. ¿Has probado a modificar el convertido?¿le has añadido algún bloque nuevo?¿Se sigue comportando igual o falla? Esa es mi pregunta estrella del hilo... más concreto no puedo ser... :)))
 

Como el ACC0 parece dependiente del HW, se podría aislar el test de la "conversión" con otros proyectos para analizar si realmente hay algún problema. Con las pruebas que yo he hecho he visto que todo era correcto, pero insisto, si detectamos algo en concreto siempre se puede analizar más en detalle.

Ahí ya no me meto... test de conversión para ver como se convierte... eso es cosa del convertidor (en este caso Icestudio) y por tanto tú sabrás las pruebas mejores para detectar el problema.
 

Con respecto a la detección de modificaciones es cierto que apio 0.2.3 no detecta los cambios en rom.list (he creado una issue), pero esto no afecta a Icestudio ya que al generar el código verilog se añade una cabecera con la fecha y la hora. Por lo tanto en Icestudio el código siempre es distinto y por lo tanto las modificaciones que se hagan en el fichero rom.list siempre se van a sintetizar. Todo esto lo he comprobado también experimentalmente, claro.

Perfecto, entonces Icestudio no le da ese control de ficheros a apio, duda resuelta. Posiblemente por eso no se haya detectado antes el problema.
 

Por eso vi que al final el problema se centraba en la generación del rom.list con la toolchain AGC. Además de esto también hemos visto que hay un posible bug con ACC0-HW para analizar en un nuevo hilo. Esta es una razón más por la que prefiero analizar los problemas con detalle ya que el stack de herramientas y posibles causas-consecuencias es muy amplio.

En este caso yo le daba más importancia y prioridad a la síntesis de Icestudio que a la conversión de la toolchain de AGC que solo se usa en el ACC... pero sin problemas, si a ti te parece bien así, cuestión de prioridades.

Un saludo.

Un saludo.

[Miquel Servera]

Ahora todavía me encuentro trabajando luego me pongo otra vez con ello y cuando tenga resultados lo digo.

Saludos.

[Miquel Servera]

Fichero rom.list modificado, no funciona como debería, lo que debería ser la primera secuencia todos los led's encendidos solo se enciende el led 5, a partir de aquí si incremento va incrementando hasta encender todos los led's y al decrementar decrementa hasta el led 5.

1. Ejecuta las siguientes instrucciones: https://github.com/Obijuan/ACC/wiki/ACC0#ensamblar-testags-y-generar-la-rom

1. yaYUL test.ags

2. acc-rom.py test.ags.bin

3. NOTA: el fichero acc-rom.py lo encuentras aquí: https://github.com/Obijuan/ACC/tree/master/tools/acc-rom
2. Esto debería generar el fichero rom.list idéntico al del repositorio.

Aquí si genera el rom.list identico al original
Adjunto imagen test.ags modificado.
Adjunto imagen rom.list del test.ags modificado

La ultima prueba realizada que seria el test.ags modificado y el rom.list correspondiente, me da como resultado que al inicio se salta la primera posición (OCT 40000) empieza en la (OCT 20000) y a partir de aquí se incrementa de forma correcta y cuando decrementas si que llega hasta la posicion (OCT 40000).

Creo no haberme dejado nada.

El viernes, 2 de junio de 2017, 9:52:27 (UTC+2), Jesús Arroyo escribió:

[Miquel Servera]

Bueno, después de unos días de desespero lo tengo funcionando al 100% (Seguimos hablando del ACC0 de Obijuan https://github.com/Obijuan/ACC) las únicas diferencias con los posts anteriores son:
Cambiar las pull-up.
Actualizar apio.

Dejo los archivos por si alguien quiere probar.

[Juanma Rico]

Genial Miquel...
Disculpa la pregunta. ¿me puedes decir la versión de apio a la que has actualizado?

[Jesús Arroyo]

Buenas Miquel,

Vamos avanzando! Te comento:

• Confirmamos que te funciona correctamente con Icestudio. Lo de la modificación de los bloques pull-up no supone realmente un cambio puesto que aunque en apariencia se vean distintos el código interno es el mismo por lo que el ACC0 que adjuntas y el original son equivalentes.
• La versión nueva de apio (0.2.4) permite ahorrar hacer clean del proyecto. Es decir, en vez de "apio clean; apio upload" (como viene en la documentación del ACC) ahora basta con hacer "apio upload". Así que OK.
• Por último, que era la parte interesante, he utilizado las herramientas yaYUL y acc-rom.py para generar el rom.list a partir del test.ags que adjuntas. Y me lo genera correctamente. Es idéntico al que adjuntas pero sin la lista de ceros al final. Ahora lo que hay que determinar es si hay algún problema en yaYUL o en acc-rom.py. Si puedes adjunta el fichero intermedio test.ags.bin para poder acotar más el problema.

Gracias.
Un saludo.

[Miquel Servera]

Perdón por no contestar antes pero ayer llegue cansado y me acosté temprano, la versión de apio es la 0.2.4

Saludos.

[Miquel Servera]

Hola Jesús te adjunto el fichero.

[Juanma Rico]

Gracias Miquel, era por confirmar...
Esa es tan reciente que me surgió la duda.

Saludos

[Jesús Arroyo]

Miguel:

He verificado que el fichero test.ags.bin (md5: 6c4e783b43e4769d1d590dccf8310ee4) es el mismo que genero yo con yaYUL (versión de la toolchain y compilada por mí).

El asunto está entonces en el script acc-rom.py. He comprobado que hay una diferencia entre el script de la toolchain (https://github.com/Obijuan/ACC/releases/tag/v0.1) y el de GitHub:



Yo he probado con ambos scripts y me genera la rom.list sin la lista de ceros al final.

Prueba las dos versiones del script para ver si te da el mismo resultado. Si persiste, se me ocurre que quizá no tengas instalado Python 3 y al ejecutarlo con Python 2 puede hacer ese efecto.

Un saludo.

[Jesús Arroyo]

Hola Miquel:

Acabo de caer en que esa diferencia es la respuesta XD: el script nuevo (que está en GitHub) genera una rom.list con 1024 posiciones. El script de la toolchain (https://github.com/Obijuan/ACC/releases/tag/v0.1) genera sólo los comandos utilizados sin ceros.

Al probar me funcionaba igual porque tenía acc-rom.py instalado en el sistema y me lo confundía con el nuevo, por eso no me cuadraba el resultado.

De todas formas, a efectos prácticos, los dos funcionan igual a la hora de sintetizar y cargar el bitstream en ACC0.

Con respecto a yaYUL, he probado tu programa test.ags modificado con la versión de la toolchain y con la versión compilada y resulta que en la versión compilada de GitHub por mí no genera errores. Prueba a compilar yaYUL y a ejecutarlo con tu programa "./yaYUL test.ags": https://github.com/Obijuan/ACC/wiki/ACC0#opcional-compilando-la-toolchain-del-agc-en-linux.

Si se confirma finalmente hablaré con Juan para crear una nueva release de las herramientas del ACC con todo actualizado y probablemente en estático para garantizar que no da confictos entre sistemas.

Quedan por tanto todos los cabos resueltos. Para el asunto del ACC y los botones de la IceZUM continuamos en el hilo nuevo.

Un saludo!

[Jesús Arroyo]

Buenas Miquel,

Un último dato: he vuelto a repasar el circuito que me has mandado y comparándolo con el original me he fijado que sí hay una diferencia en los pull-ups. En el original son pull-ups inversores y en el que mandas son pull-ups sin inversores.

En la v1.0 los botones no tenían resistencia de pull-up por lo que era necesario configurarlo en la FPGA y funcionan con lógica inversa lo que implicaba utilizar pull-up más un inversor. En la v1.1 sí tiene resistencias de pull-up por lo que no sería necesario añadirlas en la FGPA. He vuelto a hacer pruebas con tu proyecto con pull-ups y funciona "aleatoriamente". Por lo que quizá al configurar las dos resistencias (la física del botón y la interna de la FPGA) se añada un retardo en la señal que haga que no funcione correctamente. Por lo tanto está claro que es un tema de hardware.

Como decía, lo continuamos en el nuevo hilo: https://groups.google.com/forum/#!topic/fpga-wars-explorando-el-lado-libre/k2uD5eRF_oQ

Un saludo.

[Miquel Servera]

Gracias por vuestra ayuda, a seguir aprendiendo..

Miquel.

[Juanma Rico]

Gracias a ti por la paciencia demostrada.

Por la parte que me toca te pido disculpas por verte involucrado en este "fuego cruzado" de posts entre Jesús y yo.

Ya nos cuentas los resultados cuando te animes a modificar el ejemplo del ACC0 que ahora ya te funciona.
( Y si aún te queda paciencia y te ves con fuezas después de todo este lío... jejejejeje :)) )

Saludos.

[Miquel Servera]

No te preocupes Juanma, ni tu ni Jesús tenéis nada que perdonar, y por supuesto que voy a  seguir.