[iceZUM Alhambra v1.1][Cold boot]

[Juanma Rico]

Tras los interesantísimos mensajes de Unai en este hilo donde se habla del sistema "Cold boot" que admite la FPGA que lleva la iceZUM Alhambra (iCE40HX) y que básicamente consiste en la posibilidad de elegir entre cuatro imágenes de configuración distintas ante un mismo reset (grabadas de antemano en la flash), se me ha ocurrido generar un tema nuevo y hablar sobre esta posibilidad no explotada hasta ahora (que yo sepa) por nuestra querida placa con FPGA libre.
En esta captura se puede ver el concepto.

La idea es sencilla, se descargan en la flash cuatro bitstream distintos pertenecientes a cuatro cirtuitos sintetizados distintos y mediante dos pines externos a la FPGA (IO) y tras un reset, ésta pasa a comportarse de cuatro maneras distintas según los bitstream cargados. Todo esto sin necesidad de descargar por USB y mediante el PC el nuevo bitstream que refleja dicho comportamiento.

Para investigar esta posibilidad, lo primero era ver la disposición de los pines que se ven involucrados en este proceso y su disposición en la placa, no me ha sido fácil y me ha costado cierto trabajo encontrar la numeración de los pines entre tanta documentación sobre iCE40 pero finalmente, en la página web de Lattice, encontré uno entre tantos otros documentos excel donde aparece la numeración adecuada al modelo y empaquetado del chip que usa la iceZUM Alhambra.

En él podemos comprobar que el encapsulado en el que hay que fijarse es el TQ144 y los pines los enmarcados en rojo.

Los primeros son los más interesantes puesto que, como bien dice Unai, los de SPI son un bus y se pueden "pinchar" en cualquier punto que interese. Se localiza la numeración de los pines en el esquemático y aparecen sin conectar (buena señal).

Los pines 63 (CBSEL0) y 64 (CBSEL1) son los encargados de seleccionar el bloque que se desea cargar de memoria y se encuentran sin conectar a nada. Se localizan en el PCB y ahí están, al ladito de la resistencia R1.

Así que visto lo visto, al menos se puede intentar una prueba de "Cold Boot" con nuestra iceZUM Alhambra. De todas formas me surgen dudas por no saber si no influirán más de la cuenta las conexiones existentes a los pines CDONE y CRESET_B, e incluso es posible que se necesite algún "truco" para descargar cuatro bitstream distintos en la misma flash y por el USB conectado al FTDI... pero ya iremos informando.

De momento, el que se encuentre interesado por esta posibilidad y quiera investigarla dispone del documento de Lattice TN1248 (Página 14) donde se describe el proceso, si se consigue algún progreso o se llega a un callejón sin salida, siempre dispondremos de este hilo para ir comentándolo. Quién sabe... igual en un futuro Icestudio debe disponer para nuestra placa de cuatro pestañas distintas con los cuatro distintos esquemas que se podrían activar con un par de "switchs" en la propia placa... jejejejejeje :)

Saludos.

[una...@gmail.com]

Hola Juanma,

Muy interesantes los avances. He seguido un par de pasos más allá y la Alhambra YA ESTÁ UTILIZANDO el Cold Boot, aunque puede que de forma implícita (sin saberlo). [No estoy chillando, es la emoción ;)]. Sígueme:

Con respecto a CDONE y CRESET_B, en las páginas 3 y 4 del documento se muestran un diagrama de flujo y la explicación de su uso:

• After exiting the Power-On Reset (POR) state or when CRESET_B returns High after being held Low, the iCE40 device samples the logical value on its SPI_SS_B pin. Like other programmable I/O pins, the SPI_SS_B pin has an internal pull-up resistor. Refer to the iCE40LP/HX Family Data Sheet for the minimum pulse width requirement of CRESET_B.
• If the SPI_SS_B pin is sampled as a logic ‘1’ (High), then …
  
• If the SPI_SS_B pin is sampled as a logic ‘0’ (Low), then the device waits to be configured from an external controller or from another device in SPI Master Configuration Mode using an SPI-like interface.

Además de lo anterior, en los esquemáticos de la Alhambra podemos seguir la pista de todos los pines que has indicado:

Pin Bank Lattice-name      FPGA-sheet   N25Q032A USB-sheet FTDI-name FTDI-pin
63   2    IOB_42_CBSEL    x         
64   2    IOB_43_CBSEL1  x
65   2    CDONE                   iCE_CDONE              GPIO_L2    ADBUS6     23
66   2    CRESET_B            iCE_CREST               GPIO_L3    ADBUS7     24
67  SPI IOB_44_SDO         iCE_MOSI       SDI      SPI_DO     ADBUS1     17
68  SPI IOB_45_SDI           iCE_MISO       SDO    SPI_DI       ADBUS2     18
70  SPI IOB_46_SCK         iCE_SCK         SCK    SPI_SK     ADBUS0     16
71  SPI IOB_47_SS            iCE_SS_B       CS                          ADBUS4    GPIO_L0    21
72  SPI VCC_SPI                3V3

Por lo que tenemos en el mismo bus SPI a la FPGA, la memoria Flash externa a la misma (indicada como 'Configuration memory), y el FTDI. Además, de los cuatro puertos que tiene el FTDI, se utiliza uno para esta tarea. Parece ser que otro se utiliza para una UART (no vamos a profundizar), y dos están sin usar.

No conozco en detalle las posibilidades del chip FTDI, pero yo diría que:

- Podemos deducir que la Alhambra se programa directamente utilizando el caso SPI_SS_B=0. El proceso se describe más detalladamente a partir de las páginas 17-20. En ese caso el CS de la memoria flash está bajo, por lo que ni se entera.
- Si SPI_SS_B=1, el CS de la memoria flash está activo, por lo que a través del FTDI se programa la misma. Si se mantiene la FPGA en reset durante el proceso, no hay conflictos de acceso. Es razonable pensar que se hace así, y que, por lo tanto, los pines ADBUS6 y ADBUS7 del FTDI son programables por software.

Como resultado, concluimos que siempre que arrancamos la FPGA sin que intervenga el FTDI, se hace en SPI Master Configuration mode (páginas 10-13). El Cold Boot es exactamente lo mismo, tal como se explica en las páginas 14-15. La única diferencia es de software. De hecho, aunque hacen referencia a su herramienta, creo que ni siquiera es necesaria:

- Se especifica que las imágenes tienen que estar en la PROM, pero que en la dirección 0 tiene que estar el 'applet'.
- En la Figura 11, se indica que el 'applet' que contiene es la (des)habilitación del Cold Boot y/o Warm Boot, y los punteros a las cuatro direcciones de inicio de las imágenes.
- Al arrancar en modo SPI Master, lee la dirección 0 SIEMPRE, para comprobar si el Cold Boot está activo. Si no (lo que hace ahora la Alhambra), salta a la dirección indicada por el puntero 0. Es decir, hace un cold boot, asumiendo los pines de selección están a cero (sin mirarlos).
- Si el Cold Boot está activo, decide qué puntero usar en función de los pines.

Por lo tanto, el siguiente paso es mirar qué formato debe tener ese applet. Puede ser tan estúpido como un registro con dos bits (o bytes) para las habilitaciones, y 3 bytes para cada puntero. Los punteros son de 3bytes seguro, porque lo indica en la página 15. No sé si estará resuelto por icestorm, supongo que sí. Si no, todo es bajarse el Diamond Deployment Tool y hacer varias pruebas para sacarlo por ingeniería inversa.

A partir de aquí, se abren varias posibilidades:

• Me ha parecido leer que la memoria Flash es de 32Mb, no sé si lo he leído bien. Si es así, supongo que la intención es usarla para almacenar datos desde la FPGA, además de para guardar las propias imágenes de configuración.
• Como se puede acceder libremente a la Flash desde el FTDI, si quisiéramos podríamos escribir más de cuatro imágenes en la Flash. Digamos que metemos 12 de golpe. Mediante los pulsadores sólo se podrán elegir cuatro. Pero, si desde el FTDI (o la lógica dentro de la propia FPGA) reescribimos sólo los punteros, prácticamente de forma instantánea tenemos cuatro configuraciones diferentes.
• Posible hack to' chulo: un circuito RC para que la FPGA se autoresetee con un pin de salida. Un módulo en la lógica interna que escribe por SPI la dirección del primer puntero y resetea. Ya tenemos un circuito 'inteligente' que se puede cambiar a sí mismo en función de las necesidades. Sin CPU que intervenga, más que para meter todas las imágenes de golpe la primera vez.
• No requiere absolutamente ningún cambio en el PCB, creo, por lo que se puede hacer una miniplaquita con una impresora 3D, como algún otro accesorio que ya tenéis. Sólo haría falta un puente al reset.
• Digo 'creo', porque todo depende de si la FPGA permite utilizar desde la lógica el mismo SPI que se utiliza para configurar. En principio debería, bien porque el SPI sea un hard-core, o porque esos pines sean de propósito general una vez terminada la configuración.
  
• NOTA: como el pin de reset está conectado al FTDI a través de una resistencia, y también al pulsador reset a través de otra, posiblemente habría que añadir alguna más resistencia y/o diodo para evitar cortos. No lo he analizado en detalle, por lo que ahora mismo no veo cuál es la malla para calcular el RC. Pero creo que se entiende la idea.
  
• El FTDI tiene dos pines libres en el puerto que utiliza para SPI, y además otros dos puertos enteros libres. Si se conectan los pines de selección de imagen a éstos, desde el PC se podrían grabar cuatro imágenes de golpe, y cambiar de una a otra sólo cambiando esos dos bits y reiniciando la FPGA (sin tener que transmitir todo el bitstream).
• Creo que con el FTDI es más interesante tener unos pulsadores o microswitches. Pero, en caso de sustituir el FTDI por uno de los chips ethernet, wifi, BT, RF... así es como se controlarían.
  

Dicho lo anterior, creo que el primer experimento es colocar a través del FTDI una sola imagen en un punto concreto de la Flash (si lo permite el toolchain), y ver en el bitstream dónde se escribe el puntero. Después escribir otra imagen en otra posición, pero no como bitstream, sino escribiendo en la Flash directamente. Después, en otra transferencia, modificar sólo el puntero. Apagar la placa, y si al encender arranca el segundo circuito, la mayoría de las asunciones anteriores son válidas. Esto permitiría un pseudo-coldboot  sin realizar absolutamente ninguna modificación.

Un saludo!

[una...@gmail.com]

Hola de nuevo,

He buscado 'icestorm cold boot' y, efectivamente, ya está todo hecho... ¡desde agosto de 2015!. No lo he mirado en detalle (os lo dejo a vosotros), pero aquí se indica cómo activarlo: http://www.clifford.at/icestorm/format.html

Las líneas 159-174 del siguiente fichero hablan por si solas: https://github.com/cliffordwolf/icestorm/blob/master/icemulti/icemulti.cc

• Usage: icemulti [options] input-files\n");
• -c
• coldboot mode, power on reset image is selected by CBSEL0/CBSEL1
• -p0, -p1, -p2, -p3
• select power on reset image when not using coldboot mode
• -a<n>, -A<n>
• align images at 2^<n> bytes. -A also aligns image 0.
• -o filename
• write output image to file instead of stdout
  

Saludos

[Juanma Rico]

¡¡Brillante Unai!!

No he tenido tiempo de mirar en profundidad tus mensajes... pero intuyo lo que cuentas. En cuanto acabe este lunes de locos que tengo me pongo a miralo... ¡¡Genial!!

Saludos.

[Juan Gonzalez Gomez]

Hola,

Lo del cold boot funciona en la icestick, y por extensión en la alhambra (que deriva de la icestick). Sin embargo es algo que no hemos tenido tiempo de probar. Hay un porrón de frentes abiertos y es imposible abarcarlos todos. También está pendiente en el todo la prueba de las entradas analógicas de la icezum, a través del i2c.  Yo de momento estoy avanzando en otros frentes y de momento no puedo aportar nada en este.

Así que, vía libre para probar / experimentar. Cualquier contribución será siempre bienvenida :-)

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/e5cac79a-e704-41cd-a965-7e664d6cdfc6%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[una...@gmail.com]

Hola Obijuan,

¿Quién podría confirmar cuál de las siguientes es correcta?

- A través del FTDI se programa únicamente la Flash, por lo que la FPGA siempre arranca en Master.
- A través del FTDI se programa únicamente la FPGA, por lo que siempre se arranca en modo Slave.
- A través del FTDI se pueden programar tanto la Flash como la FPGA.

En otras palabras, ¿habéis hecho alguna modificación al circuito o es una copia exacta del icestick? En consecuencia, ¿habéis hecho alguna adaptación al software o la gestión del bitstream es exactamente igual?

Un saludo

[Juan Gonzalez Gomez]

Mismo esquema que icestick. Mismo software sin modificaciones. Los esquemas en kicad están el repo. Ahí podrás ver los detalles.

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/4c3db4d5-30ba-4515-bc6e-330b44731736%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[una...@gmail.com]

Muchas gracias @Obijuan

Juanma, ¡sólo el tiempo te separa de tu destino!

[Juanma Rico]

jajajajajajaja, desde luego, eso es lo que me falta: TIEMPO.

Ya hoy por fin (y con el SAV por las nubes) he conseguido sentarme tranquilamente en el laboratorio después de este inicio de semana tan loco.

He leído con atención tus descubrimientos con "icemulti" y el sistema "cold boot" lo único que se me ha ocurrido sin tener que tocar nada de hardware de la iceZum Alhambra es probar que el programa hace lo que dice, para ello he tomado cuatro bitstreams (generados a partir de VHDL, ;)) y he cambiado el parámetro "-px", que imagino que lo que hace es poner el vector correspondiente de la imagen elegida en la imagen completa que se genera con la herramienta...

La cuestión es que ha funcionado a la primera. :)

Os pongo los comandos por si alguien quiere reproducirlo y probarlo.

$ icemulti -p0 -o coldboot.bin counter8.bin blink.bin pushbutton_and.bin led_on.bin
$ iceprog coldboot.bin
init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5
file size: 130524
erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
programming..
reading..
VERIFY OK
cdone: high
Bye.

Donde "coldboot.bin" es la imagen final a grabar en la iceZUM Alhambra (o iCEstick) que se genera a partir de las otras cuatro imágenes sintetizadas (counter8.bin, blink.bin, pushbutton_and.bin  y led_on.bin). Tras estos comandos, efectivamente la imagen se ha cargado y se ha puesto en funcionamiento el primer bloque sintetizado (el contador de 8 bits), cambiando -p0 por -p1 al terminar la carga se utiliza la síntesis del "blink.bin"... y así con el resto, con lo que se confirma que la imagen se genera correctamente y se carga la adecuada.

Por ahora queda probar la opción "-c" para elegir la imagen mediante los pines CBSELx, pero eso requiere intentar soldar a los pines 64 y 65 de la iCE40HX "algo" para tenerlos accesibles. y se puedan manipular... aún tengo que pensar como hacerlo.

Aún así he hecho la prueba con "-c" y parece que la iCE40HX toma los pines al aire como HIGH, porque por más que pulso el reset (yo esperaba fuera aleatorio) siempre carga la imagen cuatro (led_on.bin).

Y esas son las pruebas que he podido hacer para calmar el SAV. Lo siguiente será imaginar cómo hacer para imponer en los pines un valor concreto y elegir la imagen adecuada intentando no dañar la iceZUM Alhambra. Si alguien tiene alguna idea estoy abierto a sugerencias... :)

Seguiré informando (muchísimas gracias Unai).
Saludos.


[Juanma Rico]

Buenooooooo, el SAV ha podido conmigo y ha ganado a la prudencia...

He visto que cerca de los pines 63 y 64 (antes confundí los números) de la iceZUM Alhambra hay un pin con GND... y he pensado... "si al aire los toma como HIGH y pongo algún pin a tierra...debe cambiar la imagen cargada si hago un reset" y ya he caído en la trampa del SAV y lo he tenido que probar para confirmar la teoría...

Así que arriesgándome mucho he puesto un cablecillo en equilibrio entre los dos pines, con lo que ambos (63 y 64) están a GND y debería, sin volver a programar la iceZUM Alhambra, cargar la imagen primera (el contador de 8 bits) y si suelto el cable, la última (la del led_on)...

¡Y ha funcionado! Se cargan las imágenes tal cual... con un simple reset tenemos el contador y tras soltar el cable y hacer un reset tenemos el led encendido... así que con una selección adecuada en los pines 63 y 64 y un reset... ¡¡podemos seleccionar entre cuatro circuitos hardware distintos sin tener que sintetizar de nuevo!! jejejejejeje

La posibilidades de tener cuatro circuitos distintos para ser usados con un solo reset aún ni me las puedo imaginar...

Ahora queda tomar las señales de esos pines, hacerlos accesibles sin riesgos y con alguna shield que lo controle, elegir entre una u otra... incluso intentar que desde la propia FPGA se mantengan los niveles con algún circuito tipo "memoria" para hacer una "FPGA autoreconfigurable". La imaginación se me dispara...  :)

Saludos.

[Juan José Luna Espinosa]

Wow, qué bueno! Eres un crack.

--

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/e6a1384b-b6d6-44c8-95a9-10d9cb7791d6%40googlegroups.com.

[Democrito]

Felicidades!!! Es genial poder hacer eso!!!

[Juan Gonzalez Gomez]

Muy bueno Juanma!  Muchísimas gracias por las pruebas! Era algo que tenía en el TODO

Es una información muy importante para dejar esos pines accesibles en las Alhambras futuras que hagamos (La Alhambra II seguramente)

Genial!!!!  :-)

Saludos, Obijuan

El 8 de marzo de 2017, 11:11, Democrito <spo...@gmail.com> escribió:

Felicidades!!! Es genial poder hacer eso!!!

--
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/317ee104-7bb2-4e3d-b8fa-126c0a644c86%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[1138-4EB]

Muchas felicidades Juanma! Me alegra ver que todo funciona según lo esperado.

Con respecto a hacer alguna otra prueba "sin tocar nada del hardware", ¿podríamos hacer un 'mapa' de coldboot.bin?

•  Sabemos que tiene cinco bloques diferenciados: el applet y los cuatro bitstream.
• Podemos hacer un hexdump de cada uno de los cuatro bistream, y de cooldboot.bin.
• Podemos localizar la primera y última línea de cada bitstream en coldboot. El espacio restante por delante es el applet.
  

Algo así:

0x0000 > applet (empieza)
0xXXX1 < applet (termina)
0xXXX2 > counter8.bin
0xXXX3 < counter8.bin
0xXXX4 > blink.bin
0xXXX5 < blink.bin
0xXXX6 > pushbuttton_and.bin
0xXXX7 < pushbuttton_and.bin
0xXXX8 > led_on.bin
0xXXX9 < led_on.bin
0xXXXa fin de la memoria

¿Me ayudas a rellenar las direcciones 0xXXX con los datos de tu coldboot.bin? Si es tal como supongo:

- 0xXXX1 y 0xXXX2 serán consecutivas. Los mismo que 3 y 4, 5 y 6, 7 y 8. Por lo que basta con un valor de cada pareja.
- El contenido de los bitstream no nos interesa, porque ya los tenemos por separado.
- ¿Podrías copiar aquí el hexdump del applet íntegro?
- Si puedieras hacerlo para los dos casos (-p0 y -p1), nos ayudaría a entender si lo que hace es cambiar los punteros, o si guarda los bitstream en diferente orden físicamente.

Intentaremos encontrar las direcciones en el applet, para pogramar sólo el puntero de inicialización por defecto. Así se podrá cambiar la imagen desde Apio, aunque las dos patillas de selección estén sin conectar (Alhambra 1.1).

También permitirá cambiar la imagen utilizando cualquier patilla de la FPGA, y no exclusivamente las dos explícitamente indicadas para ello.

Al mismo tiempo, podremos comprobar cuál es el efecto de la opción de alineación al llamar a icemulti. No la has utilizado, pero es muy interesante, y su función resultará evidente una vez hayamos resuelto el mapa anterior. Especialmente si los bitstream tienen diferentes tamaños (deberían).

Un saludo!

[una...@gmail.com]

2017-03-08, 10:27:32 (UTC+1), Juanma Rico:

Así que arriesgándome mucho he puesto un cablecillo en equilibrio entre los dos pines, con lo que ambos (63 y 64) están a GND y debería, sin volver a programar la iceZUM Alhambra, cargar la imagen primera (el contador de 8 bits) y si suelto el cable, la última (la del led_on)...

He llegado tarde, pero para una próxima puedes soldar el cable al 'culo' de una aguja hipodérmica. Así tienes una pieza más rígida (lo que te da precisión) para apoyar en las patillas. Si no te hace gracia tener algo tan afilado sobre la mesa, puede rebajarle la punta a tu gusto.

Ahora queda tomar las señales de esos pines, hacerlos accesibles sin riesgos y con alguna shield que lo controle, elegir entre una u otra... incluso intentar que desde la propia FPGA se mantengan los niveles con algún circuito tipo "memoria" para hacer una "FPGA autoreconfigurable". La imaginación se me dispara...  :)

Ahora que lo has visto en marcha y has ensanchado el campo de visión, echa un ojo a mis mensajes anteriores. Esa 'shield' puede ser el propio FTDI, ya que tiene patillas libres que sirven como 'circuito tipo memoria'. Cualquier otra solución, requeriría hardware adicional, ya que necesitarías un 'integrado' que guarde al menos dos bits. A priori, no puedes utilizar ninguna de las salidas de las FPGA, porque su estado no se mantiene durante el reset y la programación. Aunque todo sería mirarlo.

Por lo anterior, yo hacía referencia a un circuito RC, que puede ser un 555 en modo monoestable si queremos hacerlo más fino. Creo que es el elemento de memoria más simple que se puede implementar, ya que funcionalmente sólo es un bit de memoria. Y de entre todas las posibilidades de memoria, es la más barata porque es volátil.

El esquema de funcionamiento, relacionándolo con mi mensaje inmediatamente anterior, sería:

- Añadimos un circuito RC/555 entre una salida cualquiera de la FPGA y el reset.
- A través de los pines que queramos (dos, tres o diez) seleccionamos la imagen que deseamos de entre todas las que quepan en la Flash (no sólo cuatro).
- La FPGA escribe un sólo dato en el applet de la Flash para indicar el vector del próximo arranque, en función de los dos pines escogidos.
- La FPGA emite un pulso en la salida cualquiera que va al RC/555.
- El RC/555 mantiene el reset a nivel alto/bajo el tiempo suficiente para que la FPGA se reinicie en modo Master SPI.
- La FPGA arranca con el nuevo circuito.

Esta es la posible implementación en la Alhambra que sólo requeriría un punto de soldadura al reset (más accesible que las patillas 63 y 64, creo).

NOTA: todos los diseños sintetizados deberán incluir una pequeña parte lógica para guardar los valores de los vectores asociados a cada posición de los pulsadores. Si alguno no lo incluye, se podrá cambiar de otro a este, pero no volver a cambiar después.

NOTA2: si la FPGA no puede usar el hard-core SPI (que debería poder hacerlo) habría que implementar en la lógica un pequeño maestro. El código está hecho, sólo sería utilizarlo.

Saludos!

[Juanma Rico]

Esperad, esperad... todo ideas geniales que voy a poner en práctica en cuanto me anime a soldar sobre la iceZum Alhambra... pero es que esta tarde he descubierto algo muy grande... Mirando el esquema de la figura 11 veo un módulo asociado que pone "warm boot"... que hace exactamente lo mismo que el "cold boot"... ¡¡pero desde la misma FPGA!!

No hay que implementar ningún circuito externo ni mantener los niveles externos de los pads en una memoria... el chip iCE40HX... ¡¡ya trae uno interno!!

Mi miedo a soldar ha dado pie a que pruebe antes otras posibilidades... y entre ellas estaba esta... la he probado... ¡¡Y funciona!! ¡¡Triunfo total!! jejejejejeje :)

Leyendo este documento lo he visto claro... solo se necesita instanciar un módulo "top" en la FPGA, lo he probado y funciona. Para hacer las pruebas lo podéis hacer todos los que tengáis una iceZUM Alhambra (imagino que en la iCEStick también funcionará) sin arriesgaros con la aguja y el cablecillo... que ya quedará para cuando me anime a soldar...  :)

Os cuento: en el fichero sb_warmboot.v adjunto está la definición del módulo top. En el fichero test_warmboot.v está mi prueba, la prueba hace que al ir pulsando el botón 1 de la iceZUM Alhambra nos modifica un contador de 0 a 3 (se refleja la pulsación y el valor en los leds de salida) y al pulsar el botón 2 mandamos la señal de "warm boot" a la FPGA y ella se reinicia cargando el bloque indicado en los pines S0 y S1 (internos) que se ven reflejados en ese momento en los leds y carga la imagen nueva... y lo mejor, ¡funciona!... para volver a hacer una prueba se hace un reset general y se vuelve a la imagen inicial de selección. :)

El problema de la prueba es que se pierde una imagen al tener que sintetizar el "seleccionador de imágenes", por eso mejor usar el "cold boot"... pero bueno, para probar sin tener que soldar nada... vale... :D

Si queréis reproducir el test os dejo unas instrucciones básicas...

Primero os descargáis los ficheros adjuntos, sintetizáis la prueba (yo he usado apio) y otras tres imágenes sintetizadas más (yo he usado tres de las sintetizadas desde VHDL de la prueba que hice con "cold boot").

$ apio build

apio genera un hardware.bin que debe ser la imagen principal. con icemulti añadimos el resto de imágenes en un único bitstream.

$ icemulti -p0 -o warmboot.bin hardware.bin counter8.bin led_on.bin blink.bin

y todas las englobamos en un warmboot.bin que es la que finalmente grabamos en la flash (-p0 indica que la imagen inicial es hardware.bin).

$ iceprog warmboot.bin

Y listo, cada vez que demos un reset general se cargará la imagen de test_warmboot y ésta nos permitirá elegir entre el resto de imágenes al pulsar el botón 2 y enviar la señal de boot... Así podemos probar la carga de más de una imagen... ¡Y sin necesidad de soldar un solo cable! ;)

Ahora solo queda dejar todo esto ordenadito y a disposición de todos. Si alguien (Obijuan?) me indica en qué proyecto de GitHub lo debo incluir, en un rato mañana lo hago y así queda como un ejemplo más para las posibilidades de nuestra iceZUM Alhambra. :)

Estudiaré todas vuestras propuestas de hardware (el de la aguja hipodérmica sospecho que lo voy a terminar usando... :D) y muy posiblemente sean necesarias en otras FPGAs que no dispongan del "warm boot", pero nuestra iceZUM Alhambra... afortunadamente la tiene, lo que nos permite probar y experimentar sin peligro.

Saludos.

[Carlos]

Excelente trabajo Juanma y unai :D

En algun mensaje (no recuerdo si de este u otro tema) vi que esto que estas haciendo tambien esta disponible en la iceStick, lo probare en ella y veo si sirve igual, para cambiar la imagen que carga el FPGA se podría utilizar un dipSwitch (si se tiene acceso fisico a la placa o en caso de que no se esta usando un FTDI, he leido que son un tanto "caros").

Saludos

[una...@gmail.com]

¡Brillante observación!

[Juanma Rico]

El miércoles, 8 de marzo de 2017, 18:37:35 (UTC+1), 1138-4EB escribió:

Muchas felicidades Juanma! Me alegra ver que todo funciona según lo esperado.

Gracias... y el descubrimiento del "warm boot" me tiene loco. :)

Con respecto a hacer alguna otra prueba "sin tocar nada del hardware", ¿podríamos hacer un 'mapa' de coldboot.bin?

•  Sabemos que tiene cinco bloques diferenciados: el applet y los cuatro bitstream.
• Podemos hacer un hexdump de cada uno de los cuatro bistream, y de cooldboot.bin.
• Podemos localizar la primera y última línea de cada bitstream en coldboot. El espacio restante por delante es el applet.
  

Algo así:

0x0000 > applet (empieza)
0xXXX1 < applet (termina)
0xXXX2 > counter8.bin
0xXXX3 < counter8.bin
0xXXX4 > blink.bin
0xXXX5 < blink.bin
0xXXX6 > pushbuttton_and.bin
0xXXX7 < pushbuttton_and.bin
0xXXX8 > led_on.bin
0xXXX9 < led_on.bin
0xXXXa fin de la memoria

¿Me ayudas a rellenar las direcciones 0xXXX con los datos de tu coldboot.bin? Si es tal como supongo:

- 0xXXX1 y 0xXXX2 serán consecutivas. Los mismo que 3 y 4, 5 y 6, 7 y 8. Por lo que basta con un valor de cada pareja.
- El contenido de los bitstream no nos interesa, porque ya los tenemos por separado.
- ¿Podrías copiar aquí el hexdump del applet íntegro?
- Si puedieras hacerlo para los dos casos (-p0 y -p1), nos ayudaría a entender si lo que hace es cambiar los punteros, o si guarda los bitstream en diferente orden físicamente.

 

El iceprog ya te da esos datos de cabecera al programar el chip (creo), pero te los adjunto por si te son de utilidad.

Así los he generado (dejo adjuntos todos los bin):

 
 $ icemulti -p0 -o coldboot_p0.bin counter8.bin blink.bin pushbutton_and.bin led_on.bin
 $ icemulti -p1 -o coldboot_p1.bin counter8.bin  blink.bin pushbutton_and.bin led_on.bin

Y la salida de iceprog:

$ iceprog coldboot_p0.bin
init..
cdone: low
reset..

cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5
file size: 130524
erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
programming..
reading..
VERIFY OK
cdone: high
Bye.

 

Intentaremos encontrar las direcciones en el applet, para pogramar sólo el puntero de inicialización por defecto. Así se podrá cambiar la imagen desde Apio, aunque las dos patillas de selección estén sin conectar (Alhambra 1.1).

También permitirá cambiar la imagen utilizando cualquier patilla de la FPGA, y no exclusivamente las dos explícitamente indicadas para ello.

Al mismo tiempo, podremos comprobar cuál es el efecto de la opción de alineación al llamar a icemulti. No la has utilizado, pero es muy interesante, y su función resultará evidente una vez hayamos resuelto el mapa anterior. Especialmente si los bitstream tienen diferentes tamaños (deberían).

Un saludo!

Un saludo, espero te sea útil. Si necesitas algo más... "pide por esa boquita". :D

 

[1138-4EB]

2017-03-08, 20:12:06 (UTC+1), Juanma Rico escribió:

para volver a hacer una prueba se hace un reset general y se vuelve a la imagen inicial de selección. :)

El problema de la prueba es que se pierde una imagen al tener que sintetizar el "seleccionador de imágenes", por eso mejor usar el "cold boot"... pero bueno, para probar sin tener que soldar nada... vale... :D

Creo que esto te va a gustar... Es posible que el nombre 'top' te esté confundiendo, porque no tiene sentido perder una imagen. Lo que estás haciendo es interactuar con un circuito hard-core, es decir, parte del silicio de la FPGA que no es reconfigurable. Una micro máquina de estamos más bien. Por lo tanto, si incluyes se módulo 'top' en todas las imágenes, podrás cambiar de una a otra sin necesidad de hacer un reset general. El único posible conflicto es que estés usando esos mismos pulsadores para alguna otra función.

Lo que quiero decir es que el módulo top no hace absolutamente nada más que conectar tres cables. Y el contador de dos bits es muy barato.

Releyéndolo, igual lo has entendido bien, pero no has querido complicarte para la prueba. Dejo la explicación, en todo caso.
 

Ahora solo queda dejar todo esto ordenadito y a disposición de todos. Si alguien (Obijuan?) me indica en qué proyecto de GitHub lo debo incluir, en un rato mañana lo hago y así queda como un ejemplo más para las posibilidades de nuestra iceZUM Alhambra. :)

¿Cuál es tu usuario de GitHub? Independientemente de dónde quieran situarlo, dado que a partir de este punto vamos a compartir listados con cierta extensión, creo que es interesante mover ya el contenido. No cuesta crear un repositorio temporal, o una branch, y después se hace merge a donde se quiera.
 

Estudiaré todas vuestras propuestas de hardware (el de la aguja hipodérmica sospecho que lo voy a terminar usando... :D) y muy posiblemente sean necesarias en otras FPGAs que no dispongan del "warm boot", pero nuestra iceZUM Alhambra... afortunadamente la tiene, lo que nos permite probar y experimentar sin peligro.

Visto lo visto, en la Alhambra no tiene sentido soldar. Sólo para ahorrar recursos lógicos. Pero estoy de acuerdo en que por ahora no merece la pena siquiera intentar soldar nada. A mayores, si esta FPGA, siendo del rango más básico del mercado, tiene estas características, raro será encontrar otras que no tengan algo equivalente.

Felicidades, de nuevo.

[Juanma Rico]

Hola Carlos, gracias por la parte que me toca, pero aquí el "teórico" y el maestro "yedi" es Unai, yo soy un simple padawan y no sé si las merezco... :P

respondiendo a tu pregunta creo que sí. En principio está disponible para la iCEStick, en realidad para todas aquellas placas basadas en una iCE40HX (y las iCE40LP, según la documentación). En el ejemplo del "warm boot" donde se definen todos los pines de los leds de la iceZUM Alhambra, imagino tendrás que adaptar el fichero pcf a los leds de la iCEStik, pero por lo demás debería funcionar. Ya nos cuentas. :)

Saludos

[una...@gmail.com]

Me pongo con ello.

BTW, he encontrado esto: http://www.mouser.com/ds/2/225/iCE40FamilyHandbook-311139.pdf
Página 62. User SPI IP.

Lo que quiere decir que, sí podemos gestionar el número de imágenes que nos apetezca. No sólo cuatro

[una...@gmail.com]

La diferencia entre el dump de coldboot_p0.dump y coldboot_p1.dump es la siguiente:

0000000 aa7e 7e99 0092 4400 0003 0001 0082 0100

0000000 aa7e 7e99 0092 4400 0003 0080 0082 0100

Por lo tanto, puedes programar coldboot_p0.bin. Después desde el ordenador, a través del FTDI modificas sólo el byte número 11 de la flash, para sustituir "01" por "08". El resultado será el mismo que si hubieras vuelto a programar todo otra vez, pero notablemente más rápido.

[Carlos]

Imagino que el número de imagenes que se pueden grabar esta limitada por el Cold Boot Control: En la imagen muestra solo dos pines de control es decir 4 combinaciones distintas

[una...@gmail.com]

Perdón, hay que sustituir "01" por "80", no "08". Nótese, que está en hexadecimal, por lo que en decimal sería 128.

Diría, que si haces la prueba con p2 y p3, dará:

0x0001 p0 1
0x0080 p1 128
0x0100 p2 256
0x0200 p3 512

En otras palabras, utilizan una codificación one-hot de tres bits:

000 p0
001 p1
010 p2
100 p3

Donde esos tres bits son el más significativo del byte número 11 y los dos menos significativos del byte número 12.

Saludos!

[una...@gmail.com]

Hola Carlos, interpreto que esto es una respuesta a mi afirmación de que podemos gestionar más de cuatro imágenes.

Lo que comentas es cierto, en lo que respecta a los recursos físicos (hard) de la FPGA. Eso es lo que está en silicio y no se puede cambiar.

Sin embargo, el documento al que he hecho referencia te lleva al TN1274 donde se explica cómo utilizar el SPI desde la lógica de la FPGA. Por lo tanto, siguiendo el mismo esquema del warm-boot, se puede escribir algún contenido en la Flash antes de procesar la pulsación del boton de reset auxiliar. Ese contenido puede ser la dirección desde la que arrancará después del reset.

Esto es así porque la flash debe tener un tamaño mínimo (128KB), pero no máximo. La única posible pega, es que la codificación de los punteros impida llegar a un rango más allá de la cuarta imagen. Eso es lo que estoy analizando.

En relación al mensaje que acabo de enviar, el cambio de ese byte (o dos) se puede hacer desde la FPGA. Por lo que se puede obtener la misma funcionalidad del warm-boot pero utilizando sólo el cold-boot. Sólo hay que adaptar el verilog de Juanma para añadir un decodificador a la salida del contador.

Un saludo!

[Juan Gonzalez Gomez]

Impresionante Juanma!! Es la caña!! :-)

Como ya han comentado, mételo en un repo tuyo

Esto es muy grande! :-)

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/a65fc775-83b7-4931-8d47-c9d27c3c4054%40googlegroups.com.

[Carlos]

Que tal,

Todavía tengo que leer la documentación que han estado subiendo, pero usando icemulti y la opcion -px (con 4 binarios que encienden 4 leds diferentes) pude comprobar el funcionamiento en la icestick, que debe estar de más ya estaba comprobado todo xD, tengo que buscar los pines que controlan el warm_boot y el pin de reset.

Saludos

[una...@gmail.com]

Hola Juanma y Carlos,

Mi suposición anterior sobre p2 y p3 era incorrecta. No usan codificación one-hot. Es muchísimo más fácil:

• Cada imagen ocupa 31.4 KB (32220 bytes), en disko 32KB.
  
• coldboot_p?.bin ocupa 127 KB (130524 bytes), en disco 128KB
  
• Cada imagen empieza en la siguiente dirección:
• 0x000100 counter8 byte número 256
  
• 0x008000 blink byte número 32768
  
• 0x010000 pushbutton_and byte número 65536
  
• 0x018000 led byte número 98304

Por lo tanto, el applet ocupa los primeros 256 bytes. Después, aunque es ineficiente, cada imagen ocupa un bloque de 32KB. No existen los 'punteros', hay un único puntero:

'0001' p0 1

'0080' p1 128

'0100' p2 256

'0180' p3 384

'0200' p4 512

'0280' p5 640

'0300' p6 768

'0380' p7 896

'0400' p8 1024

'0480' p9 1152

...

'0980' -p19 2432

NOTA: es cierto que el primer bloque es de 32K-256 bytes. Pero no es problema porque eso son 32512 bytes, que es más que 32220.

La conclusión es que en la Alhambra, que si no me equivoco tiene una flash de 32Mb/4MB (@Obijuan?), entran 128 diseños, estando el último situado en 127*128=16256, '0x3F80'. El icestick otro tanto de lo mismo.

¿Hay ánimos para hacer una 'biblioteca' en formato BIN? Una sola programación que permita elegir cualquiera de los hasta 128 diseños y cambiar de uno a otro con el sistema de pulsadores que ha comentado Juanma. Tareas necesarias:

- Empaquetador alternativo a icemulti. Posible contribución a icestorm.

- CLI para cambiar la imagen activa por USB.

- LUT y FSM en Verilog/VHDL para cambiar la imagen activa desde la FPGA por SPI.

Saludos

[Juanma Rico]

Noooo, Carlos, nunca están de más las pruebas, bienvenidas todas las pruebas. :)

Respecto a tu comentario:  "tengo que buscar los pines que controlan el warm_boot y el pin de reset", imagino que cuando leas los mensajes del hilo te darás cuenta,... pero para que no te lies más de lo necesario... una aclaración:

• En el modo "warm boot" no tienes que buscar pines, es algo interno de la FPGA, lo único que tienes que hacer es activarlos adecuadamente y eso se hace simplemente instanciando el bloque existente en la FPGA (mira el ejemplo en los ficheros test_warnboot.v y sb_warmboot.v adjuntos en uno de los mensajes). En la figura 11 que tú pusiste aparece dicho bloque en forma simbólica con el título SB_WARMBOOT.
  
  
• El otro modo es el "cold boot" que este sí se selecciona de forma externa con los pines 63 y 64 (son pines de la iCE40HX en empaquetado TQ144 y por tanto deben estar en la misma posición en el chip de la iCEStick) y este modo es el que se programa con la opción "-c" del icemulti y "necesita" de hardware para cambiar de imagen sintetizada.

Es decir, existen dos modos que funcionan prácticamente igual, pero uno se activa externamente (cold boot) y otro internamente (warn boot).

La confusión quizás venga por el título del hilo... pero es que se empezó a investigar el modo "cold boot" pensando que era el fácil y hemos terminado descubriendo el modo "warn boot" que resulta ser más "cómodo" para experimentar y cacharrear... y claro, el título ya no corresponde... :)

Espero tus pruebas en la iCEStick. :)

Saludos.

[Juanma Rico]

¡Genial Unai!

Lo de hacer una contribución al proyecto icestorm me parece que sería grandioso, en cierta forma podríamos poner nuestro granito de arena y sería motivo de orgullo.

Y el resto... ¡Qué te voy a decir! Tener ya 128 ejemplos en la misma placa y poder cambiar de uno a otro con dos simples botones...y sin necesidad de descargar un nuevo bitstream, ni de PC ni de nada... puede que didáticamente no aporte mucho, pero funcionalmente puede ser espectacular.

Ahora es un contador, ahora un registro de desplazamiento, ahora una UART, ahora un pequeño micro... si para colmo se pueden hacer interaccionar estos diseños externamente entre sí con otra placa...¡ufff! ¡Imaginación al poder! jejejejejeje

Yo me animo, claro que sí. Por lo pronto voy a intentar mañana ordenar los conceptos y ejemplos en un github y ponerlos a disposición de todos de forma fácil, por si alguien se quiere animar a probar esta herramienta tan potente y quiere aportar ideas.

Por cierto, Unai, tú que preguntabas... mi github es este: https://github.com/juanmard

No hay mucho porque lo tengo un poco abandonado, pero ahí pondré el resumen de este hilo, ya aviso cuando haya algo qué clonar y/o mezclar (mergear).

Saludos.

[Carlos]

Quedó todo claro, tenia mezclados los modos warm y cold.

En la iceStick los pines que controlan el cold boot no están conectados a nada, mi duda es con el pin de reset, lo controla el pin CREST del chip FTDI, esta conectado directamente al pin CRESET_B del iCE40 y este último también esta conectado por medio de una resistencia (R22) de 10k a 3.3v que lo mantiene con un 1 lógico. La resistencia de abajo (R23) no esta, por lo que creo que poniendo un botón en su lugar puedo resetear la ICE40 al presionar el botón, ¿estoy en lo correcto?

Saludos y gracias por la ayuda :D

[Juanma Rico]

Yo diría que sí Carlos, que estás en lo correcto
 En la iceZUM Alhambra en el esquema aparece una resistencia antes del interruptor, pero es de cero ohmnios.


El tema está en si se necesita resetear algo más que la FPGA con este interruptor. Eso ya no lo sé, Eladio es el indicado quizás para responderte a esto.

Saludos.

[Carlos]

Que tal Juanma,

Pues viendo las señales que salen del botón de reset, la señal FPGA_PWR_EN va al ENABLE de los reguladores de voltaje, el SYS_RESET va a un header y la señal FPGA_RESET va al pin que comentaba antes, abriré otro hilo para no mezclar temas.

Saludos

[una...@gmail.com]

 Hola Juanma,

Revisando tus pasos, me parece que no has hecho nada diferente en icemulti al crear las imágenes para cold boot y warm boot. Es decir, el diseño es lógico es diferente, pero ¿has indicado en algún sitio que querías activar el warm boot? En el manual TN1248 se explica que hay que activar una pestaña para ello.

Un saludo

[Juanma Rico]

No, no hice nada diferente, simplemente no activé la opción "-c".

No me hagas mucho caso, pero creo que icestorm o icemulti (no sé exactamente cual ni en qué punto) detecta de alguna manera que está instanciado el módulo top de sb_warmboot y coloca un valor especial en la cabecera de la flash (lo que llaman 'applet') que hace activar uno u otro modo.

No investigué mucho el código de icemulti porque todo tan rodado y funcionó tan rápido que no tuve que investigar mucho más allá. ;)

Pero si descubres algo interesante... ¡no dejes de avisar! 😊

Saludos

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/85259365-2509-456b-b9e4-25cbff79b4af%40googlegroups.com.

[Jesús Arroyo]

Qué tema más interesante! Enhorabuena por los experimentos!

En la última release de la toolchain de icestorm he incluido el binario de icemulti. Si véis que puede simplificar el proceso podemos crear un nuevo comando en apio que encapsule esta funcionalidad y así esté disponible en todas las plataformas, lo dejo a vuestra elección ;)

Un saludo.

[Juanma Rico]

Hola Jesús, sí vamos a necesitar tu ayuda, eso seguro... sobre todo si se puede meter en la flash 128 diseños distintos... 😊

Yo medio en broma dije que tendrías que añadir cuatro pestañas en icestudio para programar las cuatro distintas capas a las que se puede acceder... pero si los cálculos de Unai son correctos ya veo inviable lo de las pestañas.... jajajaja

Saludos

El 09/03/2017 10:19, "Jesús Arroyo" <jesus...@gmail.com> escribió:

Qué tema más interesante! Enhorabuena por los experimentos!

En la última release de la toolchain de icestorm he incluido el binario de icemulti. Si véis que puede simplificar el proceso podemos crear un nuevo comando en apio que encapsule esta funcionalidad y así esté disponible en todas las plataformas, lo dejo a vuestra elección ;)

Un saludo.


El jueves, 9 de marzo de 2017, 9:50:26 (UTC+1), Juanma Rico escribió:

No, no hice nada diferente, simplemente no activé la opción "-c".

No me hagas mucho caso, pero creo que icestorm o icemulti (no sé exactamente cual ni en qué punto) detecta de alguna manera que está instanciado el módulo top de sb_warmboot y coloca un valor especial en la cabecera de la flash (lo que llaman 'applet') que hace activar uno u otro modo.

No investigué mucho el código de icemulti porque todo tan rodado y funcionó tan rápido que no tuve que investigar mucho más allá. ;)

Pero si descubres algo interesante... ¡no dejes de avisar! 😊

Saludos

El 09/03/2017 09:10, <una...@gmail.com> escribió:

 Hola Juanma,

Revisando tus pasos, me parece que no has hecho nada diferente en icemulti al crear las imágenes para cold boot y warm boot. Es decir, el diseño es lógico es diferente, pero ¿has indicado en algún sitio que querías activar el warm boot? En el manual TN1248 se explica que hay que activar una pestaña para ello.

Un saludo

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/85259365-2509-456b-b9e4-25cbff79b4af%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/14715962-18fa-4320-889d-f23421845029%40googlegroups.com.

[una...@gmail.com]

Aupa Juanma,
 
2017-03-09, 9:50:26 (UTC+1), Juanma Rico:

No, no hice nada diferente, simplemente no activé la opción "-c".

No me hagas mucho caso, pero creo que icestorm o icemulti (no sé exactamente cual ni en qué punto) detecta de alguna manera que está instanciando el módulo top de sb_warmboot y coloca un valor especial en la cabecera de la flash (lo que llaman 'applet') que hace activar uno u otro modo.

El applet no es 'un valor', son 256 bytes. Estos incluyen, entre otra información:

- Puntero a la imagen por defecto si -c no se usa.
- Los cuatro punteros a cada una de las cuatro imágenes. Esto último se me había pasado por alto, pero también está en el dump.
- Des/activación del coldboot.
- Des/activación del warmboot.

¿Podrías pasarme los binarios 'warmboot' y 'hardware', además de uno de los 'coldboot' usando '-c'? El caso es que en los dos ejemplos que me pasaste, sólo cambia el quinto puntero, el default, por lo que me faltan datos para comparar.

Tengo la sensación de que la (des)activación del coldboot y warmboot es la misma, y que el icemulti tiene hardcodeado ese parámetro. Al fin y al cabo, si activas siempre el warmboot, pero el diseño lógico no está conectado a los pines internos, no pasa nada. Me gustaría confirmarlo.

Otro aspecto sobre el que estoy dudando es si, en caso de escribir una sola imagen, se escribe algún applet o la imagen empieza en la posición 0 de la flash. En principio no lleva nada, pero en ese caso me falta entender qué diferencia hay entre eso y grabar un coldboot. Puesto que el primero se supone que no tiene que hacer ningún salto, y el segundo sí.
 

No investigué mucho el código de icemulti porque todo tan rodado y funcionó tan rápido que no tuve que investigar mucho más allá. ;)

Pero si descubres algo interesante... ¡no dejes de avisar! 😊

Por el momento estoy acumulando las referencias en https://github.com/1138-4EB/go/tree/master/elide/dynreconfig

He corregido los cálculos, y entran 127 diseños, no 128. Si se sustituye/modifica icemulti para generar binarios más compactos, 130. Pero el iCE40 en sí, puede direccionar hasta 511 o 520.

Por eso, me he calentado un poco y me he pillado un par de icestick, además de una flash de 64Mb (1€), otra de 128Mb (2,25€). La idea es sustituir la memoria en una de ellas, y si no explota nada, la otra en la segunda. Como necesitaba un par de euros para completar el pedido, he cogido también una iCEHX4K-TQ144. Me ha parecido que es pin-compatible con la de 1K, y la diferencia es de 5,25€ a 6,15€. En este caso veo jodido (que no imposible) sustituir el chip que ya está soldado, por lo que se quedará en el cajón hasta que me anime a pedir un PCB.

Saludos!

[Juanma Rico]

jajajajaja, ¡¡Te veo a tope!! :)

Precisamente me iba a poner en el ratito que tengo a subir a github el resumen, pero como este fin de semana no voy a disponer de la iceZUM alhambra, me he puesto a mirar y hacer pruebas con el icemulti y dejar el github para el finde...

El jueves, 9 de marzo de 2017, 19:14:41 (UTC+1), una...@gmail.com escribió:

Aupa Juanma,
 
2017-03-09, 9:50:26 (UTC+1), Juanma Rico:

No, no hice nada diferente, simplemente no activé la opción "-c".

No me hagas mucho caso, pero creo que icestorm o icemulti (no sé exactamente cual ni en qué punto) detecta de alguna manera que está instanciando el módulo top de sb_warmboot y coloca un valor especial en la cabecera de la flash (lo que llaman 'applet') que hace activar uno u otro modo.

El applet no es 'un valor', son 256 bytes. Estos incluyen, entre otra información:

Sí, con applet me refería a esos 256 bytes... En el documento he creído entender que siempre tiene que estar y siempre lo lee empezando por la dirección cero de la PROM, por eso hablaba de la "cabecera de la flash" como applet. Corrígeme si estoy equivocado.

- Puntero a la imagen por defecto si -c no se usa.
- Los cuatro punteros a cada una de las cuatro imágenes. Esto último se me había pasado por alto, pero también está en el dump.
- Des/activación del coldboot.
- Des/activación del warmboot.

 Ok, lo he mirado en icemulti y efectivamente lo que hace es sustituir en la cabecera un 0x10 por un 0x00 si se activa o no el modo "cold boot" con "-c".

void Header::write(std::ostream &ofs, uint32_t &file_offset)
{
    // ...
    // Boot mode
    write_byte(ofs, file_offset, 0x92);
    write_byte(ofs, file_offset, 0x00);
    write_byte(ofs, file_offset, (coldboot_flag? 0x10: 0x00));

¿Podrías pasarme los binarios 'warmboot' y 'hardware', además de uno de los 'coldboot' usando '-c'? El caso es que en los dos ejemplos que me pasaste, sólo cambia el quinto puntero, el default, por lo que me faltan datos para comparar.

Adjuntados están.
 

Tengo la sensación de que la (des)activación del coldboot y warmboot es la misma, y que el icemulti tiene hardcodeado ese parámetro. Al fin y al cabo, si activas siempre el warmboot, pero el diseño lógico no está conectado a los pines internos, no pasa nada. Me gustaría confirmarlo.

Casi seguro sea así. Ya me dices si pudiste confirmarlo con los binarios que te pasé.
 

 

Otro aspecto sobre el que estoy dudando es si, en caso de escribir una sola imagen, se escribe algún applet o la imagen empieza en la posición 0 de la flash. En principio no lleva nada, pero en ese caso me falta entender qué diferencia hay entre eso y grabar un coldboot. Puesto que el primero se supone que no tiene que hacer ningún salto, y el segundo sí.

Como te comento creo recordar que en la documentación habla de que tiene que estar y que es lo primero que lee y según la activación de uno u otro así actúa. No sé exactamente en qué punto lo leí, pero si no lo localizas dímelo y hago memoria.

 

No investigué mucho el código de icemulti porque todo tan rodado y funcionó tan rápido que no tuve que investigar mucho más allá. ;)

Pero si descubres algo interesante... ¡no dejes de avisar! 😊

Por el momento estoy acumulando las referencias en https://github.com/1138-4EB/go/tree/master/elide/dynreconfig

He corregido los cálculos, y entran 127 diseños, no 128. Si se sustituye/modifica icemulti para generar binarios más compactos, 130. Pero el iCE40 en sí, puede direccionar hasta 511 o 520.

Me asustas con esos nuevos datos... si se eligen bien las síntesis de circuitos... ¡igual solo hay que programar la flash una vez en la vida! :)
 

Por eso, me he calentado un poco y me he pillado un par de icestick, además de una flash de 64Mb (1€), otra de 128Mb (2,25€). La idea es sustituir la memoria en una de ellas, y si no explota nada, la otra en la segunda. Como necesitaba un par de euros para completar el pedido, he cogido también una iCEHX4K-TQ144. Me ha parecido que es pin-compatible con la de 1K, y la diferencia es de 5,25€ a 6,15€. En este caso veo jodido (que no imposible) sustituir el chip que ya está soldado, por lo que se quedará en el cajón hasta que me anime a pedir un PCB.

jajajajaja ¿Y tú eras el que me decía que no me calentara demasiado? :D

Saludos!

Otros para ti.

[Juanma Rico]

Buenas,

Como este fin de semana no puedo estar con la iceZUM Alhambra, he aprovechado para juguetear con el código del icemulti y la posibilidad de poner más de cuatro imágenes (síntesis) en la flash, lo he recompilado dando un máximo de 8 imágenes para probar...

/// static const int NUM_IMAGES = 4;
static const int NUM_IMAGES = 8;
static const int NUM_HEADERS = NUM_IMAGES + 1;
static const int HEADER_SIZE = 32;

Y parece que se lo ha tragado:

$ ./icemulti -p0 -o multiimage.bin hardware.bin coldboot.bin blink.bin coldboot_p0.bin coldboot_p1.bin counter8.bin led_on.bin pushbutton_and.bin

$ iceprog multiimage.bin

init..
cdone: low
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5

file size: 552960

erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..

erase 64kB sector at 0x020000..
erase 64kB sector at 0x030000..
erase 64kB sector at 0x040000..
erase 64kB sector at 0x050000..
erase 64kB sector at 0x060000..
erase 64kB sector at 0x070000..
erase 64kB sector at 0x080000..

programming..
reading..
VERIFY OK
cdone: high
Bye.

La idea es rellenar la flash con el máximo de imágenes posibles ya que, ya sea en modo "warm boot" o en modo "cold boot", aunque solo se pueden direccionar cuatro mediante dos pines (internos o externos), estos lo que hacen es leer de la propia flash (en su cabecera) los vectores de dirección de la imagen a cargar, con lo que si de alguna manera, podemos "reprogramar" dichos vectores, podemos seleccionar (de cuatro en cuatro) todas las síntesis grabadas en la flash.

Puesto que la flash se programa mediante protocolo SPI en teoría se podrían cambiar esos vectores usando el USB con el chip FTDI, otro circuito externo conectado al bus SPI e incluso, es posible, desde la propia FPGA, con lo que se podría saltar de un circuito sintetizado a otro sin más que cambiar desde el propio circuito sintetizado el vector de dirección,...

Para ello se cambiaría el vector de posición, se apuntaría con los dos pines al nuevo y haciendo un reset... un circuito llamaría a otro usando la propia FPGA y así "autoprogramándose" ella misma utilizando los bloques "presintetizados" y grabados en la flash.... ¡una locura! jajajajaja

Esa es la idea en la que está trabajando Unai, buscando la estructura de la cabecera de estos vectores dirección (lo que en la documentación llama "applet") y haciendo ingeniería inversa sobre los "dump" que se generan desde icemulti... lo bueno de esta última prueba es que al parecer el software icemulti admite más de cuatro imágenes sin más que cambiar una constante... con lo que el software ya está hecho. :)

Lo he probado, tarda más en grabar la flash (lógicamente) y he puesto la imagen "seleccionadora" en la última posición... (p7) y...  ¡ha funcionado!! al hacer reset es la imagen que se ha ejecutado y he podido seleccionar otras cuatro... si conseguimos hacer una imagen "seleccionadora" que pueda seleccionar el resto cambiando los vectores de la flash... ya podría funcionar el invento... :)

Sigo a la espera de que Unai me confirme la estructura y sacar conclusiones claras (aún me hace alguna cosa extraña) pero sigo haciendo pruebas. Seguimos informando.

Saludos.

[Juanma Rico]

Nuevas noticias... ¡ha funcionado!, icemulti sirve como herramienta para generar más de una imagen sintetizada y grabarla en la flash. Creía que me hacía cosas raras, pero no... era que he reciclado alguna imagen y no recordaba qué hacía cada una de ellas... con lo que el comportamiento no era el esperado por mi. :)

La cuestión es que con este pequeño comando (modificando y recompilando icemulti con el número máximo de imágenes)... ¡¡ahora tengo 5 imágenes sintetizadas accesibles!! :)

 $ ./icemulti -p7 -o multiimage.bin counter8.bin led_on.bin blink.bin pushbutton_and.bin counter8.bin led_on.bin pushbutton_and.bin hardware.bin

 $ iceprog multiimage.bin

Y diréis... ¿Cómo es posible si solo se pueden direccionar cuatro vectores?
Pues porque el comando -p7 sitúa la imagen del "seleccionador de imágenes" que se carga con el reset al final de la flash (8 imágenes) y deja las primeras (de 0 a 3) para seleccionar con la prueba del seleccionador que hice, así que tal y como está se puede acceder a cinco imágenes distintas... :)

En cuanto confirmemos que las imágenes son de tamaño fijo, en el seleccionador pondremos un contador mayor, multiplicar por el tamaño fijo de la imagen para calcular los vectores, utilizar SPI para cambiar los cuatro vectores (sería como mover la ventana de selección "hardware") y elegir y hacer un "warm reset" para cargar imagen apuntada por el nuevo contador...

Y sin tener que generar código que lo haga... ¡Está ya hecho! ¡Icemulti al poder! jajajaja :)

Lo dejo por hoy....
Saludos.

[una...@gmail.com]

Hola Juanma,

como este fin de semana no voy a disponer de la iceZUM alhambra, me he puesto a mirar y hacer pruebas con el icemulti y dejar el github para el finde...

Sabia elección, ya que yo por el momento tampoco tengo hardware para probar.

Sí, con applet me refería a esos 256 bytes... En el documento he creído entender que siempre tiene que estar y siempre lo lee empezando por la dirección cero de la PROM, por eso hablaba de la "cabecera de la flash" como applet. Corrígeme si estoy equivocado.

No, no estás equivocado. Yo he entendido lo mismo, y con el hexdump he comprobado que, efectivamente, ahí está el applet cuando utilizas icemulti. En el mismo están los cuatro punteros, y el quinto default. Por lo tanto, no nos cabe ninguna duda de cuál es el funcionamiento cuando escribimos lo que yo he llamado 'pack'  (el applet y varios bistream en un solo bin).

Sin embargo, cuando escribes el bistream de un sólo diseño con iceprog (lo que yo llamo 'image'), no hay applet por ningún lado. Estás escribiendo sólo una imagen. Y ahí está mi duda: ¿cómo sabe la FPGA si tiene que leer desde cero hasta terminar o si tiene que hacer un primer salto y luego leer secuencialmente?
Hay varias diferencias evidentes en los binarios que me has enviado. Aquí los primeros 16 bytes de una imagen y de un pack, respectivamente:

ff 00 00 ff 7e aa 99 7e  51 00 01 05 92 00 20 62

7e aa 99 7e 92 00 00 44  03 00 01 00 82 00 00 01

Como explica Clifford http://www.clifford.at/icestorm/format.html, '7e aa 99 7e' es un token. Por lo que una diferencia es que las imágenes tienen un cometario delante: 'ff 00 00 ff'. Además, el byte inmediatamente posterior es diferente para una imagen y un pack, '51' y '92', respectivamente.

Sin embargo, estos detalles no los he encontrado en la documentación de icestorm, y icemulti parece no tener ninguna. Puede que baste con enviarle un mensaje/issue. Al fin y al cabo es más por curiosidad que necesidad.

Ok, lo he mirado en icemulti y efectivamente lo que hace es sustituir en la cabecera un 0x10 por un 0x00 si se activa o no el modo "cold boot" con "-c".

Eso había interpretado, pero voy a identificar qué bit es exactamente en el binario y lo añado a las notas.

Gracias de nuevo por los binarios.

Me asustas con esos nuevos datos... si se eligen bien las síntesis de circuitos... ¡igual solo hay que programar la flash una vez en la vida! :)

¡Pues eso no es nada! Todas las imágenes ocupan lo mismo, independientemente del contenido, lo cual es muy ineficiente. Como hay una CPU, lo suyo es comprimir todas las imagenes excepto las cinco direccionables. Utilizando gzip, o bzip2, una imagen ocupa menos de 1KB. (127-5)*32=3904 nos da hasta 3909 circuitos en la flash de la Alhambra, y 16197 son los que permitiría el sistema con una memoria cuatro veces mayor.

En cuanto a programarla sólo una vez... ¡hay tantos contextos/productos diferentes! Puede tener su interés una única imagen para distribuirla con la Alhambra y una serie de manuales con circuitos documentados. Pero eso no deja de ser un único producto. Pero la potencia está en aprovechar la coordinación CPU-FPGA, y eso está bastante limitado por el FTDI. Es un sistema más jugoso para placas conectadas a una RPi, por ejemplo, las que son shields en vez de base.

jajajajaja ¿Y tú eras el que me decía que no me calentara demasiado? :D

Si meto la pata en alguno de los pasos de compresión o recolocación de las imágenes, es posible que la FPGA lea contenido que no debe, se configure indebidamente y se queme. En ese punto, prefiero hacer las pruebas con un hardware 'desechable', y no tenerte de conejillo de indias ;).

Por eso mismo, antes de meterme con la compresión, quiero forzar los límites de la capacidad de direccionamiento de la FPGA: ¿será capaz de leer una imagen que empiece en el espacio direccionable de la flash pero termine fuera? Si la lectura es estrictamente secuencial, la FPGA no debería darse cuenta de que se ha salido de su espacio de conocido. Pero si no lo es... pueden pasar cosas raras y... ¡chispas!
 
Por último, no me digas que no sería interesante una Alhambra v2 con una FPGA tres veces más grande y cuatro veces más memoria. La diferencia de precio es de 2€ y creo que el PCB casi no habría que tocarlo.

Lo de las imágenes y ta si es un poco calentada... pero esto último tenía que probarlo.

Saludos!

[una...@gmail.com]

Hola de nuevo,

¿Estos dos últimos mensajes los has escrito antes o después de visitar mis notas (si es que las has mirado? Te lo pregunto sin ninguna acritud, pero has expresado exactamente lo mismo en castellano, y me ha sorprendido que sean las mismas conclusiones. No sólo eso, sino que las pruebas que has realizado son algunas de las que tenía en la lista XD:

•         Write pack_cp0.bin to flash.
• Change default pointer only, through FTDI.
• Rearrange the pointers, through FTDI.
• Pack more than four images and write the binary to flash.
• Set a fifth image as default (which is not referred by any of the four pointers).
• Rearrange the poiners, through FTDI.
  

    TODO: CLI to rearrange pointers. measure and compare reconfiguration time.

Concretamente, lo que comentas de `-p7` es 'Pack more than four images and write the binary to flash > Set a fifth image as default (which is not referred by any of the four pointers)'.

Por otro lado, 'rearrange pointers' es lo que tú has denominado 'ventana de selección' de imágenes. Lo que pasa es que mi idea es que la ventana no tenga que estar compuesta por imágenes consecutivas, sino por cualquier grupo de cuatro/cinco.

Estoy reescribiendo icemulti en golang. El rendimiento es muy parecido a C, pero creo que sintácticamente es mucho más intuitivo, y me permite hacer una GUI web con más facilidad. ¿Podrías darme una referencia de cuánto tarda (en segundos) la programación con iceprog? Me vale con dos valores orientativos, uno para una sola imagen y otra para un pack.

Una vez hecho eso, miraré cómo hacer una sola transacción SPI desde el PC a través del FTDI (lo que he denominado CLI).

Un saludo!

[Juanma Rico]

Jejejeje...

Hola Unai...

Pues han sido puñetera casualidad... ;)

Espero no te hayas enfadado más de lo normal en estos casos. :)

De hecho intenté acceder al enlace que dejaste de tus notas, no pude acceder, me dio error (no sé porqué) y hasta que no lo has vuelto a mencionar ni me acordaba.

Siento haberte copiado las palabras aunque haya sido sin querer y traducidas... jejejeje

Ahora que lo has mencionado y recordado,  en cuanto pueda, intento acceder de nuevo a tus notas y me las leo.

Saludos.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/c8f4c80b-a0c3-49b2-bcf8-9fdd44d05585%40googlegroups.com.

[Juanma Rico]

Se me olvidaba contestarte... es posible que mañana por la tarde pueda escaparme unos minutos al laboratorio, en cuanto llegue te hago la prueba de tiempos que me pides y te la mando.

Saludos

El 09/03/2017 23:46, <una...@gmail.com> escribió:

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/c8f4c80b-a0c3-49b2-bcf8-9fdd44d05585%40googlegroups.com.

[Unai Martinez]

¡Enfado ninguno, hombre! Es sólo por ordenar las 'tareas'. Si sé que tú vas a hacer unas pruebas, me las ahorro ;). Este finde o el lunes más tardar podré hacer alguna y me ayudaría saber en qué orden las estás haciendo. Ya sea tomando mi documento como referencia, o cualquier otro que uses tú.

Si sigues teniendo problemas para acceder a las notas a través del enlace, deberías poder llegar navegando en GitHub.

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/c8f4c80b-a0c3-49b2-bcf8-9fdd44d05585%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/CAOpm3532g%2Byr53hxiynge_L-YNw%3DPhe2v7nJ2stubzumy6GNcg%40mail.gmail.com.

[Juanma Rico]

Desde el móvil no estoy teniendo problemas para leer tus notas y las estoy ahora mismo leyendo desde aquí. 😊

Respecto al orden de las pruebas... pues ningún orden en concreto... fundamentalmente hago pruebas según se me van ocurriendo... funciono tal que así: "esto no ha funcionado... ¿y si hago tal cosa o tal otra?¿funcionará? "

Si funciona soy "el mejor" en ese momento... si no funciona, pues intento otra cosa... un poco caótico.  😊

Sigo ldyendo tus siempre interesantes notas... (otro día que duermo poco... ja ja ja ja)

😊

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAOpm3532g%2Byr53hxiynge_L-YNw%3DPhe2v7nJ2stubzumy6GNcg%40mail.gmail.com.

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

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/CAGZZdDGXUaLZjZG30wCpp_zTsQgbYFwtw-TBumU-_xwayaCccQ%40mail.gmail.com.

[Juanma Rico]

El SAV es muy fuerte estos días en mi... debe ser cosa de los midiclorianos... ¿Cuantos midiclorianos trae un Actimel? :)
Así que esta mañana, en una escapada, una rápida conexión y te adjunto lo que me pedías, Unai.

 $ time ./icemulti -p7 -o multiimage.bin counter8.bin led_on.bin blink.bin pushbutton_and.bin counter8.bin led_on.bin pushbutton_and.bin hardware.bin

real    0m0,056s
user    0m0,004s
sys     0m0,004s

 $ time iceprog multiimage.bin
init..
cdone: high

reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5

file size: 258048

erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
erase 64kB sector at 0x020000..
erase 64kB sector at 0x030000..

programming..
reading..
VERIFY OK
cdone: high
Bye.

real    0m52,058s
user    0m0,144s
sys     0m0,632s

$

Casi un minuto para el "pack" (multiimage.bin).

$ time iceprog counter8.bin
init..
cdone: high

reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5

file size: 32220

erase 64kB sector at 0x000000..

programming..
reading..
VERIFY OK
cdone: high
Bye.

real    0m7,452s
user    0m0,020s
sys     0m0,140s

$

Ni ocho segundos para la imagen del contador (counter8.bin).

Saludos.

[Eladio Delgado]

Hola!

Cuando diseñamos la placa me pregunté porqué la Icestick usaba una memoria de 4 MB cuando la FPGA se configura con mucha menos memoria. Vi por encima el tema del cold/warm boot (quedó en el TO-DO verlo en detalle y hacer pruebas) y decidimos mantener la memoria de 4 MB por si alguien usaba esto, ya que no es un componente muy caro.

Ya ha merecido la pena sin duda! Muy interesantes las aportaciones que estáis haciendo. Muchas gracias y felicidades a los que participáis en este hilo!! Gran trabajo!!!

Saludos, Eladio

--

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/7e73620e-b2e3-47b0-ab0a-783c75703d0b%40googlegroups.com.

[Juanma Rico]

Gracias Eladio, cada día es un orgullo y un placer poder trabajar con tu "criatura", todo lo que hagamos para ella es poco. :)

Aprovecho para unas conclusiones rápidas del rato que he podido echar esta mañana con la iceZUM Alhambra.

Quería intentar cambiar uno de los vectores de la cabecera de la flash (a partir de ahora applet, los primeros 256 bytes) para ver si con una misma imagen mútiple (Unai lo ha llamado "pack") se podía acceder al resto sin volver a compactar (se compacta usando icemulti). Para eso hay que cambiar el contenido de la flash usando SPI, lo más fácil de momento: hacerlo usando el FTDI (lo de hacerlo usando directamente la FPGA será para nota...)

Lo primero generar la imagen múltiple de prueba (pack.bin) mediante el icemulti modificado para 8 imágenes distintas.

$ ./icemulti -p7 -o pack.bin counter8.bin led_on.bin pushbutton_and.bin  counter.bin shift4.bin blink.bin tones.bin hardware.bin

El seleccionar de imágenes (4) es el hardware.bin  que situamos en último lugar y que apuntamos por defecto (al dar al reset) mediante el comando -p7.

Editando el bitstream generado mediante un editor bianario (yo uso mc en GNU/Linux) y buscando el "token" FF0000FF, que al parecer según las notas de Unai indican el inicio de las imágenes individuales, encontramos que las direcciones deben corresponder a esto:

0x000120 - counter8.bin
0x007EFC - led_on.bin
0x00FCD8 - pushbutton_and.bin
0x017AB4 - counter.bin
0x01F88C - shift4.bin
0x027664 - blink.bin
0x02F440 - tones.bin
0x037218 - hardware.bin

Donde solo podemos direccionar mediante los botones de la iceZUM Alhambra las cuatro primeras y siempre gracias al "circuito seleccionador" que se encuentra en la última (hardware.bin) y que se selecciona con el reset general.

Si hacemos una lectura de los primeros 256 bytes (applet) tenemos reflejados los cinco vectores a las imágenes que podemos acceder:

00000000  7e aa 99 7e 92 00 00 44  03 03 72 18 82 00 00 01  |~..~...D..r.....|
00000010  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  7e aa 99 7e 92 00 00 44  03 00 01 20 82 00 00 01  |~..~...D... ....|
00000030  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  7e aa 99 7e 92 00 00 44  03 00 7e fc 82 00 00 01  |~..~...D..~.....|
00000050  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  7e aa 99 7e 92 00 00 44  03 00 fc d8 82 00 00 01  |~..~...D........|
00000070  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  7e aa 99 7e 92 00 00 44  03 01 7a b4 82 00 00 01  |~..~...D..z.....|
00000090  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  7e aa 99 7e 92 00 00 44  03 01 f8 8c 82 00 00 01  |~..~...D........|
000000b0  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  7e aa 99 7e 92 00 00 44  03 02 76 64 82 00 00 01  |~..~...D..vd....|
000000d0  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  7e aa 99 7e 92 00 00 44  03 02 f4 40 82 00 00 01  |~..~...D...@....|
000000f0  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

La primera es el reset el resto aparecen en orden (hasta completar el tamaño del applet... ¿o no?¿Qué pasaría si en lugar de 8 decimos en icemulti que hay más imágenes?¿saldría del tamaño de los 256 bytes? ¿Es únicamente el token "ff0000ff" el que limita el tamaño del applet? A investigar...).

Como solo podemos acceder a los cuatro primeros, la idea es modificar o intercambiar uno de los cuatro primeros vectores por uno de los "no-accesibles", con ello si mágicamente aparece el nuevo comportamiento al seleccionar el antiguo es que la teoría es cierta y modificando los vectores podemos acceder a la multitud de síntesis que podamos empaquetar con icemulti en una misma imagen.

Modificamos e intercambiamos las imágenes de led_on.bin por la de blink.bin... es decir intercambiamos el vector del applet 0x007EFC por el del 0x027664. Para ello modificamos el bitstream pack.bin y lo guardamos como pack_mod.bin (ambos se adjuntan para que podáis experimentar, con iceprog lo podéis grabar en vuestra iceZUM Alhambra. El resto de binarios no los subo para no ensuciar el post, pero los he obtenido directamente del tutorial de Obijuan para la ICEStick).

Antes de probar comprobamos que únicamente se han modificado las direcciones y los valores correctos:

$ cmp -l pack.bin pack_mod.bin | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'

0000004A 00 02
0000004B 7E 76
0000004C FC 64

000000CA 02 00
000000CB 76 7E
000000CC 64 FC

Y efectivamente se han intercambiado los valores en ambos vectores.
Programamos y cruzamos los dedos...

$ iceprog pack_mod.bin
init..

cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5

file size: 258036

erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
erase 64kB sector at 0x020000..
erase 64kB sector at 0x030000..
programming..
reading..
VERIFY OK
cdone: high
Bye.

Después de un minutillo de espera para que se grabe en la flash... Reset y tenemos el seleccionador funcionando, elegimos el cero y está el counter8.bin actuando...Nuevo reset para volver al seleccionador, botón 1 y elegimos la imagen siguiente... ahora viene la hora de la verdad... ¿saltará a la imagen del blink.bin?... pulsamos el botón 2 para saltar y....... ¡Funciona! ¡los 8 leds se ponen a parpadear como locos! (y yo con ellos.... jajajajaja)

Confirmado, guardando una tabla de direcciones de la imagen (buscando los tokens FF0000FF) podemos acceder a todas las imágenes modificando únicamente estos vectores de la applet que están en la flash.

Ahora solo queda acelerar el proceso modificando únicamente esos vectores sin tener que grabar la imagen entera como yo he hecho en la flash.

He intentado hacerlo modificando el iceprog para que permita grabar valores en una dirección concreta, pero no funciona, imagino que porque la flash tiene que borrarse y grabarse por bloques,.. si alguien tiene experiencia en este tipo de dispositivos y quiere modificar el iceprog para que pueda hacerlo ya tendríamos medio camino hecho.

Os adjunto mi fichero iceprog.c modificado por si queréis intentarlo, para hacerlo funcionar hay que incluir un "-m" y hace por cambiar un vector de prueba, algo así:

 

$ ./iceprog -mv dummy.txt

init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5

Programming test multi...
write enable..
prog 0x000029 +0x001..
00
prog 0x00002A +0x001..
7e
prog 0x00002B +0x001..
fc
waiting..
cdone: high
Bye.

El fichero dummy.txt es necesario para que no proteste por falta de parámetros, pero no se usa ni existe.
En la salida dice que los ha grabado, pero al leer la flash (con el propio iceprog) los bytes no se han modificado... :(
Os lo dejo por si alguien quiere intentarlo.

Saludos.

[una...@gmail.com]

¡Vaya ritmo que llevas! Casi no me da tiempo a procesar y actualizar las notas :D

Como observación los 'tokens' nos los he 'descubierto' yo. Están en la página de clifford, donde se explica el formato del bitstream. Igual está enlazado un poco antes en las notas y no se entiende claramente que sólo he copiado y pegado.

Es muy interesante lo de que escriba todas las cabeceras y no sólo cuatro, pero yo diría que es 'culpa' tuya. Al modificar icemulti a huevo, repite el mismo proceso para cualquier número de imágenes. Lo suyo sería que en el applet se escribieran sólo cuatro, que son las esperadas por el cold/warm boot.

De todas formas, como ha funcionado, sabemos que podemos meter cualquier contenido después de los cuatro punteros. Y no tenemos que respetar el límite de 256 bytes, ya que eso es una decisión de clifford. Conocemos lo suficiente sobre el funcionamiento ahora, para saber que las imágenes pueden ir donde nos plazca.

Es más, creo que el siguiente esquema tiene bastante sentido:

token del applet con puntero a imagen default
token del applet con puntero a imagen A
token del applet con puntero a imagen B
token del applet con puntero a imagen C
token del applet con puntero a imagen D
puntero imagen 1, puntero imagen 2, puntero imagen 3, puntero imagen 4, puntero imagen 5...
...
puntero imagen 127
token inicio imagen 1
...
token inicio imagen 2
...

Donde cada puntero de imagen >4 son sólo tres bytes. De esta forma en la flash tenemos todas las imágenes y un índice completo compactado. Da igual que utilicemos el FTDI o la FPGA, no hay que guardar los punteros en ningún sitio. Sólo tenemos que saber:

• Qué imagen queremos poner.
• En cuál de las cinco posiciones queremos ponerla.

El algoritmo es leer de una posición y escribir en otra.

Es más, si en lugar de 3 bytes por imagen utilizamos seis o los que sean, se puede escribir un UID relacionado con un repositorio de bitstreams. De forma que el usuario indique el UID del bitstream que quiere, y si no sabe en que posición está escrito, se puede buscar en el índice cuál le corresponde. Aunque es cierto que esa equivalencia podría ser un fichero auxiliar al bistream del pack, el hecho de que esté en la flash dá más versatibilidad para hacer programaciones parciales de la memoria de forma dinámica.

Por último, lo que comentas de iceprog, creo que lo suyo es empezar al revés: intenta leer todo el applet. Después, intenta leer sólo una línea del applet. Por último, intenta escribir. Igual ya lo has hecho, y estoy escribiendo por escribir.

Un saludo y felicidades!

[Juanma Rico]

El viernes, 10 de marzo de 2017, 15:39:58 (UTC+1), una...@gmail.com escribió:

¡Vaya ritmo que llevas! Casi no me da tiempo a procesar y actualizar las notas :D

 

jajajajajaja, es que el saber que toodoo un fin de semana no voy a poder rebajar el SAV usando la iceZUM Alhambra me hace acelerar... :D

Como observación los 'tokens' nos los he 'descubierto' yo. Están en la página de clifford, donde se explica el formato del bitstream. Igual está enlazado un poco antes en las notas y no se entiende claramente que sólo he copiado y pegado.

jejejejeje, Ya no sé ni donde ni por donde leo las cosas... soy un poco caótico en ese sentido... pero a veces una buena referencia contextualizada es mejor que la propia fuente... :)
 

Es muy interesante lo de que escriba todas las cabeceras y no sólo cuatro, pero yo diría que es 'culpa' tuya. Al modificar icemulti a huevo, repite el mismo proceso para cualquier número de imágenes. Lo suyo sería que en el applet se escribieran sólo cuatro, que son las esperadas por el cold/warm boot.

Sí, está claro que habrá que afinar esto... pero de momento viene bien para que icemulti calcule automáticamente las direcciones y queden todas reunidas al inicio de la flash.... más cómodo para hacer pruebas. :)

De todas formas, como ha funcionado, sabemos que podemos meter cualquier contenido después de los cuatro punteros. Y no tenemos que respetar el límite de 256 bytes, ya que eso es una decisión de clifford. Conocemos lo suficiente sobre el funcionamiento ahora, para saber que las imágenes pueden ir donde nos plazca.

Es más, creo que el siguiente esquema tiene bastante sentido:

token del applet con puntero a imagen default
token del applet con puntero a imagen A
token del applet con puntero a imagen B
token del applet con puntero a imagen C
token del applet con puntero a imagen D
puntero imagen 1, puntero imagen 2, puntero imagen 3, puntero imagen 4, puntero imagen 5...
...
puntero imagen 127
token inicio imagen 1
...
token inicio imagen 2
...

Donde cada puntero de imagen >4 son sólo tres bytes. De esta forma en la flash tenemos todas las imágenes y un índice completo compactado. Da igual que utilicemos el FTDI o la FPGA, no hay que guardar los punteros en ningún sitio. Sólo tenemos que saber:

• Qué imagen queremos poner.
• En cuál de las cinco posiciones queremos ponerla.

El algoritmo es leer de una posición y escribir en otra.

Sí, eso estaría mejor, mucho más fino desde luego. :)
Lo bueno en esta etapa usando el iceprog original es que cualquiera con una iceZUM Alhambra y el bitstream (pack_mod.bin) que adjunté en el mensaje anterior, puede poner a prueba el sistema...¡animaros! :)

Es más, si en lugar de 3 bytes por imagen utilizamos seis o los que sean, se puede escribir un UID relacionado con un repositorio de bitstreams. De forma que el usuario indique el UID del bitstream que quiere, y si no sabe en que posición está escrito, se puede buscar en el índice cuál le corresponde. Aunque es cierto que esa equivalencia podría ser un fichero auxiliar al bistream del pack, el hecho de que esté en la flash dá más versatibilidad para hacer programaciones parciales de la memoria de forma dinámica.

Ya te me estás calentando... ¡no te acerques a una página de compras on-line!¡Que se te va el sueldo en frikadas! jajajajajajaja :)

Por último, lo que comentas de iceprog, creo que lo suyo es empezar al revés: intenta leer todo el applet. Después, intenta leer sólo una línea del applet. Por último, intenta escribir. Igual ya lo has hecho, y estoy escribiendo por escribir.

Sí, lo he hecho, pero no funciona, por lo menos a mi no me funciona. Te cuento:

Además de la prueba modificando el iceprog para grabar los bytes individuales en una dirección de memoria... hice otra: una vez grabada la flash con el pack.bin mediante el iceprog ($ iceprog pack.bin), he leído los primeros 256 bytes y los he guardado en otro fichero ($ iceprog -R256 applet.bin), he modificado el fichero (al igual que hice con el pack.bin) y he intentado grabar únicamente el applet ($ iceprog applet_mod.bin), pero al terminar la transferencia la FPGA se queda "colgada" (los leds se ven a medio gas), ni siquiera respondía a un reset.

Lo que no he hecho (e igual debería haberlo hecho) es, una vez grabado el applet y desconectada y vuelta a conectar (el reset no iba), volver a leer la flash y comparar los cambios con el pack.bin, a ver qué estaba pasando.... También tengo que comprobar qué ocurre si añado más de 8 imágenes al pack, porque aún no sé si funcionaría iceprog con un applet de más de 256 bytes. Investigaremos.

Un saludo y felicidades!

Saludos. :D

[una...@gmail.com]

Esta appnote de FTDI creo que puede serte útil:

http://www.ftdichip.com/Support/Documents/AppNotes/AN_178_User%20Guide%20for%20LibMPSSE-SPI.pdf

Hay un ejemplo de código en C sobre cómo interactuar con la memoria por SPI. Aunque supongo que iceprog tendrá una implementación diferentes, puede servirte como referencia para ver si estás saltándote algún paso.

Lo del límite de 256 bytes, creo que puedes estar tranquilo, funcionará.

[Juanma Rico]

Tema límite 256 bytes en applet comprobado, no existe tal límite (en esta prueba su tamaño es de 383 bytes).
He modificado el icemulti con 10 imágenes, las he tomado todas, las he empaquetado, grabado en la flash y funcionando.... :)

Ahora mi iceZUM Alhambra tiene en su interior 11 circuitos distintos dispuestos a usarse, de los cuales cinco de ellos ya se pueden utilizar. ¿Alguien más puede decir lo mismo?... no, ¿verdad? jejejejeje :-P
¡Que quede para la historia que la primera fue la iceZUM Alhambra número 26! jejejejejeje :-)

Gracias por la documentación del FTDI, le echaré un vistazo, pero ya tendrá que ser para otro día.

Un saludo a todos y buen fin de semana.

[Eladio Delgado]

El 10 de marzo de 2017, 15:12, Juanma Rico <juan...@gmail.com> escribió:

Gracias Eladio, cada día es un orgullo y un placer poder trabajar con tu "criatura", todo lo que hagamos para ella es poco. :)

Al contrario, el placer es mío por ver que sirve a tantas personas. Y es una criatura de todos, ha nacido gracias a vuestro apoyo y crece con oportaciones como las que estáis haciendo en este hilo.

Gracias a todos!

Saludos, Eladio

[Miguel Alarcón Ortiz]

Hola a todos,

Estoy siguiendo el tema porque verdaderamente me interesa, personalmente ando liado con dos proyectos personales pero cuando saque tiempo pienso meterme de cabeza. Respecto de cold boot o warm boot ¿Se resintetizaría toda la FPGA o se puede seleccionar un área?

Mi pregunta viene porque por ejemplo yo sintetizo un microblaze con perifericos en la FPGA, y por necesidades del circuito solo quisiera variar los perifericos¿Esto se podría hacer o se tendría que sintetizar todo?

saludos.

  Alarcón. 

[Juanma Rico]

Hola Miguel,

Se sintetizan por separado, se obtienen los bitstream (*.bin) con, por ejemplo, "apio build", se agrupan esos bitstream individuales en uno mayor (con icemulti) y éste es el que finalmente se graba en la flash de memoria para que esté a disposición de la FPGA mediante "iceprog".

Si tienes los pines 63 y 64 de la iCE40HX accesibles puedes elegir el bitstream a cargar mediante "hardware" con el "cold boot" o si quieres lo haces internamente mediante un "warm boot".

El chip iCE40HX ya te permite elegir entre cuatro bitstream distintos, pero se está intentando "trampear" (hackear) para que permita elegir el máximo posible que entren en la memoria flash.

Si quisieras cambiar uno de los diseños solo tendrías que generar el nuevo bitstream, volver a compactar con icemulti y grabar de nuevo con iceprog.

Anímate es muy fácil, ya hay por ahí un bitstream preparado para grabar con iceprog (pack.bin y pack_mod.bin) y poner a prueba el concepto. 😊

Saludos.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/55a05942-da2c-4249-b8ee-6ea31142e7ee%40googlegroups.com.

[una...@gmail.com]

Buenos días Miguel,

Lo que estamos tratando en este hilo es 'Reconfiguración Dinámica', es decir, reprogramar toda la FPGA sin intervención del usuario. Bueno, ahora mismo Juanma lo hace con un pulsador, pero se entiende que se puede accionar desde la propia lógica.

Por lo que tú preguntas es por la 'Reconfiguración Parcial Dinámica'. La diferencia principal es que lo que se ha comentado en este hilo desconecta prácticamente toda la FPGA excepto una minúscula máquina de estados que sólo sabe leer de la Flash. La reconfiguración parcial es más ambiciosa, porque verás que necesitas tener partes de la FPGA encendidas y que sigan funcionando con normalidad, mientras apagas, desconectas, reconfiguras y enciendes otras.

Una vez entendido eso, lo que tienes que hacer es particionar la FPGA. Con el PlanAhead (no sé cómo se llama ahora en VIvado), verás el esquema de la FPGA y seleccionarás un rectángulo. Todos los recursos que queden dentro de ese rectángulo serán una partición. Puedes hacer una o varias. Después, en tiempo de ejecución, utilizarás el Microblaze para acceder a la memoria, leer un nuevo bitstream y cambiar la funcionalidad de esa partición. El proceso tiene alguna particularidad adicional:

• Naturalmente cualquier diseño que quieras meter en la partición, deberá caber. Por ello, al seleccionar la zona, deberás fijarte en cuántos BRAM y DSPs quedan dentro.
• Los diseños que sintetices para las particiones no deberán tener bloque I/O, porque irán conectados internamente.
• No estoy seguro, pero diría que la entidad tiene que ser la misma, y lo que modificas es la arquitectura. Esto quiere decir que si los diferentes diseños que quieres meter no tienen exactamente los mismos puertos, deberás hacer una entidad común donde se incluyan todos, y después asignar constantes a las salidas que no utilices.
• No estoy seguro, pero creo que también puedes especificar el valor que tendrás esos puertos mientras se esté realizando la reconfiguración.

Tienes tutoriales y user guides en https://www.xilinx.com/products/design-tools/partial-reconfiguration.html

Concretamente, este explica lo que tú quieres hacer paso a paso: https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/PlanAhead_Tutorial_Reconfigurable_Processor.pdf

Ten en cuenta que como has hablado de Microblaze he asumido que estás trabajando con FPGAs de Xilinx. La iCE40 dudo que tenga nada de reconfiguración parcial (aunque podría sorprenderme todavía).

Un saludo

[una...@gmail.com]

Si estás ocupado ahora, puedes mirar esto: https://www.xilinx.com/support/documentation/white_papers/wp374_Partial_Reconfig_Xilinx_FPGAs.pdf

Son ocho páginas con bastantes dibujitos.

[Miguel Alarcón Ortiz]

Muchas gracias a los dos por las respuesta, es eso en concreto lo que tengo intención de ver. En principio para esta versión de ICE40 no puede resultar util porque el espacio que se tiene no muy grande pero para FPGA de tamaño medio prodría dar muchisimo juego. Yo lo entiendo como un concepto parecido al warm o cold bootloader.

saludos y esta tarde después del curro le echaré un vistazo.

[OSWALDO MERCHAN]

Waooooooo impresionante masters of universe pfgas.. Este joven padawan entender tratando esta...

[una...@gmail.com]

Hola Juanma y cía,

Buscando sobre las diferentes posibilidades para programa la iCE40HX, he encontrado esta placa de Olimex: https://www.olimex.com/Products/FPGA/iCE40/iCE40HX1K-EVB/open-source-hardware Es básicamente lo que comentábamos en este hilo. Y ya tienen cuatro placas de periféricos: https://www.olimex.com/Products/FPGA/iCE40/

Lo que nos interesa es que tienen instrucciones concretas sobre cómo programar la flash y/o la FPGA desde un Arduino. Aquí el sketch: https://github.com/OLIMEX/iCE40HX1K-EVB/blob/master/programmer/olimexino-32u4%20firmware/iceprog.ino La explicación completa está al final de: https://olimex.wordpress.com/tag/icecube2/

No obstante, el esquema no es el mismo que el de la Alhambra: https://github.com/OLIMEX/iCE40HX1K-EVB/blob/master/iCE40HX1K-EVB_Rev_B.pdf Particularmente hay varias resistencias adicionales en los pines correspondientes al SPI. Relacionado con lo planteado aquí: https://groups.google.com/forum/#!topic/fpga-wars-explorando-el-lado-libre/4L0QO0WVPm4

Un saludo

[Juanma Rico]

Gracias por la info Unai.

Le he echado un vistazo rápido a los enlaces y sí, es prácticamente una traducción de la programación que hace iceprog al Arduino (quitando las funciones del FTDI, claro). Ha confirmado lo que me tiene bloqueado y no me deja avanzar (además de que aún no he tenido tiempo de sentarme esta semana en el laboratorio), la flash se programa al parecer por bloques (¿64kb?) y no me deja cambiar únicamente un byte de una dirección concreta, así que imagino que habrá que leer un bloque, modificar el byte de dicha dirección y volver a grabarlo (¿antes hay que borrar el bloque completo?).

Mi falta de experiencia en este tipo de memorias me tiene sin poder hacer una prueba rápida (me he bajado muchos documentos y datasheet de este tipo de memorias pero en un vistazo rápido no me lo aclaran y tengo que poder sentarme a "estudiar" el tema).

La idea en mi cabeza para completar el hilo es la siguiente: primero controlarlo todo usando el FTDI (el PC con su USB) para escribir el menor número de bytes posible en la flash para cambiar los vectores (esto permitirá que todos los que tengan una Alhambra puedan usar el programa para aprovechar al máximo la flash y cambiar de una a otra imagen sintetizada, en esta fase ya se podria pensar en integrar en icestudio el icemulti), luego usar directamente el SPI con el Arduino (tu enlace viene genial) para cambiar los vectores (ya no necesitaríamos el PC) y en una fase posterior cambiar directamente la configuración de la FPGA por SPI aunque dicha configuración se vaya al perder la alimentación (imagino que es más rápido que cambiar la flash, resetear y leer de la flash la configuración completa de nuevo) y como fase final que desde la propia FPGA se puedan cambiar estos vectores y saltar de una a otra imagen sin intervención externa de un micro o similar.

Igual son muchas fases para quedarse bloqueado en la primera... 😊

Saludos.

[una...@gmail.com]

Le he echado un vistazo rápido a los enlaces y sí, es prácticamente una traducción de la programación que hace iceprog al Arduino (quitando las funciones del FTDI, claro). Ha confirmado lo que me tiene bloqueado y no me deja avanzar (además de que aún no he tenido tiempo de sentarme esta semana en el laboratorio), la flash se programa al parecer por bloques (¿64kb?) y no me deja cambiar únicamente un byte de una dirección concreta, así que imagino que habrá que leer un bloque, modificar el byte de dicha dirección y volver a grabarlo (¿antes hay que borrar el bloque completo?).

Por lo que estuve mirando la semana pasada, sí, las flash pueden exigir que se borre un sector entero antes de escribir. Borrar es poner todos los valores a 1. Digo 'pueden' porque la clave está en que las operaciones de escritura sólo son capaces de cambiar unos a ceros. Por lo tanto, si la modificación que queremos hacer implica sólo quitar unos, no es necesario el borrado. Si intentas cambiar un cero a un uno, no pasa nada. Por eso tú no viste diferencias en las pruebas que hiciste. ¿Probaste a activar el coldboot por defecto y después intentar desactivarlo con una sola escritura?

No obstante, la solución más general es que se requiera también cambiar ceros a unos. Por lo que, como comentas, la estrategia sería leer el sector más pequeño posible, modificar el contenido, hacer un borrado y reescribir el nuevo contenido. Entendiendo un poco cómo funcionan tiene sentido: tú escribes a un buffer (de 256 bytes en este caso) y cuando terminas se hace una copia instantánea de ese buffer a la página correspondiente. Al leer es lo mismo: se copian 256 bytes de golpe y luego tú los lees en serie. Puedes verlo en la página 12 de la datasheet.

Icemulti (y creo que iceprog también) borran la memoria en sectores de 64KB (fíjate en las mayúsculas, son bytes). Pero el modelo concreto que lleva la Alhambra soporta los siguientes modos (primera página de la datasheet):

• Erase capability
– Subsector erase 4KB uniform granularity blocks
– Sector erase 64KB uniform granularity blocks
– Full-chip erase

Explicado en más detalle en la página 12 de la datasheet:

Each page of memory can be individually programmed. Bits are programmed from one
through zero. The device is subsector, sector, or bulk-erasable, but not page-erasable.
Bits are erased from zero through one. The memory is configured as 4,194,304 bytes (8
bits each); 64 sectors (64KB each); 1024 subsectors (4KB each); and 16,384 pages (256
bytes each); and 64 OTP bytes are located outside the main memory array.

Por lo tanto, este modelo en concreto sólo tiene granularidad de borrado hasta el nivel de subsector. Desconozco si otros modelos permiten hacerlo a nivel de página.

Como conclusión:

• Para escribir el pack: borrar en sectores de 64KB.
• Para cambiar una sola imagen, borrar 8 sectores de 4KB. O bien, uno de 64KB guardando previamente la otra imagen que este en el sector.
• Para cambiar el applet y activar el coldboot, borrar el primer subsector de 4KB. Para desactivarlo, no es necesario borrar.
  

Mi falta de experiencia en este tipo de memorias me tiene sin poder hacer una prueba rápida (me he bajado muchos documentos y datasheet de este tipo de memorias pero en un vistazo rápido no me lo aclaran y tengo que poder sentarme a "estudiar" el tema).

Espero que estas pistas anteriores te ayuden ;)
 

La idea en mi cabeza para completar el hilo es la siguiente: primero controlarlo todo usando el FTDI (el PC con su USB) para escribir el menor número de bytes posible en la flash para cambiar los vectores (esto permitirá que todos los que tengan una Alhambra puedan usar el programa para aprovechar al máximo la flash y cambiar de una a otra imagen sintetizada, en esta fase ya se podria pensar en integrar en icestudio el icemulti), luego usar directamente el SPI con el Arduino (tu enlace viene genial) para cambiar los vectores (ya no necesitaríamos el PC) y en una fase posterior cambiar directamente la configuración de la FPGA por SPI aunque dicha configuración se vaya al perder la alimentación (imagino que es más rápido que cambiar la flash, resetear y leer de la flash la configuración completa de nuevo) y como fase final que desde la propia FPGA se puedan cambiar estos vectores y saltar de una a otra imagen sin intervención externa de un micro o similar.

Esa es exactamente la hoja de ruta. Lo de escribir desde Arduino directamente en la FPGA es exactamente lo mismo que escribir en la Flash, por lo que es una prueba, más que un paso adicional.

Yo ahora mismo estoy peleándome para echar a andar el icestick con las herramientas de Lattice en Windows 10. Icecube2 funciona perfectamente, y he podido sintetizar, analizar el floorplan, hacer estimaciones de consumo de potencia, simulación post-síntesis... Pero no hay manera de que el programador se conecte a la placa. El driver lo reconoce, pero al escanear da error.

He probado con Zadig, que es lo que utiliza apio/icestudio, y no hay problema. Pero quiero echar a andar el toolchain del fabricante, para asegurarme de no hacer alguna burrada.

go-icemulti lo estoy haciendo con Cobra, de forma que cuando se implemente todo, la API quede algo así como:

• go-icemulti pack -m -o mypack.bin -b 0 -p 1,2,3,4 -v -c lzp2
  
• go-icemulti read all
  
• go-icemulti read pack
  
• go-icemulti read image 12
  
• go-icemulti write pack myback.bin
• go-icemulti write index
  
• go-icemulti write refs -b 5 -p 6,7,8,9

lzp2 es un algoritmo de compresión basado en tokens bastante sencillo, con el que he podido comprimir cada bistream de 32KB a 1KB. Naturalmente, utilizarlo implica un cambio de estrategia, en el siguiente sentido: en la flash sólo están descomprimidas las cinco imágenes iniciables por hardware. Por lo tanto, los punteros son siempre los mismos y la operación "cambio de puntero" lo que hace es descomprimir una imagen y guardarla en la posición correspondiente al puntero indicado.

• Si se ejecuta desde el Arduino, como has comentado, se puede leer la imagen, descomprimirla y configurar la FPGA directamente. En este caso la flash es sólo un almacenamiento de alta capacidad para el Arduino.
• Si se ejecuta desde la FPGA, hay que leer la imagen, descomprimirla, escribirla y después resetearse (volviendo a leerla). Es más lento, pero tiene el potencial de disponer de miles de circuitos sin necesidad de ninguna CPU externa.

No obstante, por el momento estoy limitándome al comando go-icemulti pack, que es prácticamente lo mismo que el icemulti original, pero admite más de cuatro imágenes y genera un índice compacto con metainformación (además de los punteros en sí). Este hilo lo he abierto justamente por esa metainformación. En principio voy a identificar cada imagen con una cadena "vendor:library:image:version:revision", de la que seguramente obtendré un hash.

Saludos

[una...@gmail.com]

https://flashdba.com/2014/06/20/understanding-flash-blocks-pages-and-program-erases/

[Juanma Rico]

Buenas Unai,
Comentarios en azul.

El viernes, 17 de marzo de 2017, 10:12:47 (UTC+1), 1138-4EB escribió:

Le he echado un vistazo rápido a los enlaces y sí, es prácticamente una traducción de la programación que hace iceprog al Arduino (quitando las funciones del FTDI, claro). Ha confirmado lo que me tiene bloqueado y no me deja avanzar (además de que aún no he tenido tiempo de sentarme esta semana en el laboratorio), la flash se programa al parecer por bloques (¿64kb?) y no me deja cambiar únicamente un byte de una dirección concreta, así que imagino que habrá que leer un bloque, modificar el byte de dicha dirección y volver a grabarlo (¿antes hay que borrar el bloque completo?).

Por lo que estuve mirando la semana pasada, sí, las flash pueden exigir que se borre un sector entero antes de escribir. Borrar es poner todos los valores a 1. Digo 'pueden' porque la clave está en que las operaciones de escritura sólo son capaces de cambiar unos a ceros.

Ahora me cuadra... algunas veces me modificaba un valor, aunque la mayoría me los ponía a cero, lo más seguro es que ese valor modificado coincidiera con que en esa posición había un bit uno.. siendo la probabilidad más alta de que o bien en origen o destino existiera ya un bit cero... de ahí los bytes cero que me quedaban eran mayoría. todo cuadra. :)
 

Por lo tanto, si la modificación que queremos hacer implica sólo quitar unos, no es necesario el borrado. Si intentas cambiar un cero a un uno, no pasa nada. Por eso tú no viste diferencias en las pruebas que hiciste. ¿Probaste a activar el coldboot por defecto y después intentar desactivarlo con una sola escritura?

La última pregunta no la entiendo bien... imagino que por "coldboot" te refieres a "warnboot" (decidí usar esta característica del iCE40HX por no tener que andar con cables), pero aún así no entiendo... ¿Por "coolboot por defecto" te refieres al bitstream tal y como te lo entrega icemulti con los cinco vectores en el sitio indicado por el orden de empaquetamiento y el parámetro "-px" para el vector de reset? Si te refieres a esto... la respuesta es afirmativa, con el iceprog modificado (que está adjunto en uno de los mensajes) y la opción "-m" escribo "a piñón fijo" en una dirección de memoria de la flash correspondiente a uno de los vectores (la 0x29 creo recordar) un valor de prueba... pero claro, sin borrar el bloque... y es ahí donde al leer la flash (con iceprog) se ven ceros y algunos bytes con otros valores.

No obstante, la solución más general es que se requiera también cambiar ceros a unos. Por lo que, como comentas, la estrategia sería leer el sector más pequeño posible, modificar el contenido, hacer un borrado y reescribir el nuevo contenido. Entendiendo un poco cómo funcionan tiene sentido: tú escribes a un buffer (de 256 bytes en este caso) y cuando terminas se hace una copia instantánea de ese buffer a la página correspondiente. Al leer es lo mismo: se copian 256 bytes de golpe y luego tú los lees en serie. Puedes verlo en la página 12 de la datasheet.

No sé a qué datasheet te refieres... ¿el de la memoria flash N25Q032A? Me he bajado como tres distintos de distintos fabricantes de esa misma memoria flash y claro, no me coinciden las páginas... :(
 

Icemulti (y creo que iceprog también) borran la memoria en sectores de 64KB (fíjate en las mayúsculas, son bytes). Pero el modelo concreto que lleva la Alhambra soporta los siguientes modos (primera página de la datasheet):

No, creo que no. Icemulti no usa nada la comunicación serie con la flash, no tiene parámetros para borrar ni programar ni nada... únicamente se encarga de empaquetar los distintos ficheros "bin" de distintas síntesis en uno solo que es el que luego se graba con iceprog... (seguro que ha sido un lapsus tuyo). Respecto iceprog y a los 64KB, eso sí... además te avisa con un mensaje cada vez que borra un sector.
 

• Erase capability
– Subsector erase 4KB uniform granularity blocks
– Sector erase 64KB uniform granularity blocks
– Full-chip erase

Explicado en más detalle en la página 12 de la datasheet:

Each page of memory can be individually programmed. Bits are programmed from one
through zero. The device is subsector, sector, or bulk-erasable, but not page-erasable.
Bits are erased from zero through one. The memory is configured as 4,194,304 bytes (8
bits each); 64 sectors (64KB each); 1024 subsectors (4KB each); and 16,384 pages (256
bytes each); and 64 OTP bytes are located outside the main memory array.

Por lo tanto, este modelo en concreto sólo tiene granularidad de borrado hasta el nivel de subsector. Desconozco si otros modelos permiten hacerlo a nivel de página.

Perfecto, entonces lo único que hay que hacer es leer el primer subsector (4KB,... muchos me parecen), borrarlo (llenarlo de unos), modificar los vectores y volver a grabar esos 4KB con los vectores ya modificados. En cuanto pueda sentarme en el laboratorio lo pruebo en la iceZUM Alhambra (desgraciadamente tengo por delante otro fin de semana en que no voy a poder). De todas formas me parecen muchos 4KB para cambiar solo tres bytes de un vector de dirección... pero bueno. :(

Como conclusión:

• Para escribir el pack: borrar en sectores de 64KB.

Vale, eso ya lo hace el iceprog.

• Para cambiar una sola imagen, borrar 8 sectores de 4KB. O bien, uno de 64KB guardando previamente la otra imagen que este en el sector.

Perfecto, suponiendo que dejamos que esta tarea la haga iceprog una sola vez con todas las imágenes posibles y que entren en la flash igual no es necesario cambiar las imágenes.

• Para cambiar el applet y activar el coldboot, borrar el primer subsector de 4KB. Para desactivarlo, no es necesario borrar.
  

Esto no lo entiendo... cambiar el applet sí (realmente yo cambiaría solo los cinco vectores que apuntan a las imágenes) y tal como yo había pensado... pero no entiendo lo de "Para desactivarlo, no es necesario borrar" ¿Por qué no es necesario borrrar?

• 
  

Mi falta de experiencia en este tipo de memorias me tiene sin poder hacer una prueba rápida (me he bajado muchos documentos y datasheet de este tipo de memorias pero en un vistazo rápido no me lo aclaran y tengo que poder sentarme a "estudiar" el tema).

Espero que estas pistas anteriores te ayuden ;)

Sí, mucho, como siempre... :)
Ya solo de intentar contestarte el correo me ha surgido una prueba rápida que puedo hacer... :)
 

 

La idea en mi cabeza para completar el hilo es la siguiente: primero controlarlo todo usando el FTDI (el PC con su USB) para escribir el menor número de bytes posible en la flash para cambiar los vectores (esto permitirá que todos los que tengan una Alhambra puedan usar el programa para aprovechar al máximo la flash y cambiar de una a otra imagen sintetizada, en esta fase ya se podria pensar en integrar en icestudio el icemulti), luego usar directamente el SPI con el Arduino (tu enlace viene genial) para cambiar los vectores (ya no necesitaríamos el PC) y en una fase posterior cambiar directamente la configuración de la FPGA por SPI aunque dicha configuración se vaya al perder la alimentación (imagino que es más rápido que cambiar la flash, resetear y leer de la flash la configuración completa de nuevo) y como fase final que desde la propia FPGA se puedan cambiar estos vectores y saltar de una a otra imagen sin intervención externa de un micro o similar.

Esa es exactamente la hoja de ruta. Lo de escribir desde Arduino directamente en la FPGA es exactamente lo mismo que escribir en la Flash, por lo que es una prueba, más que un paso adicional.

Tienes razón... pero eso de quitarte de en medio el FTDI y no tener que depender del PC... para mi es un avance, un logro :)
Incluso si funciona estoy pensando en soldar un Arduino Nano a una shield protoboard y conectarla directamente a la iceZUM Alhambra mediante el SPI... así ya tenemos el uC que pedías para controlar la FPGA... :)
 

Yo ahora mismo estoy peleándome para echar a andar el icestick con las herramientas de Lattice en Windows 10. Icecube2 funciona perfectamente, y he podido sintetizar, analizar el floorplan, hacer estimaciones de consumo de potencia, simulación post-síntesis... Pero no hay manera de que el programador se conecte a la placa. El driver lo reconoce, pero al escanear da error.

He probado con Zadig, que es lo que utiliza apio/icestudio, y no hay problema. Pero quiero echar a andar el toolchain del fabricante, para asegurarme de no hacer alguna burrada.

¡Genial! Si lo consigues avisa. ;-)

go-icemulti lo estoy haciendo con Cobra, de forma que cuando se implemente todo, la API quede algo así como:

• go-icemulti pack -m -o mypack.bin -b 0 -p 1,2,3,4 -v -c lzp2
  
• go-icemulti read all
  
• go-icemulti read pack
  
• go-icemulti read image 12
  
• go-icemulti write pack myback.bin
• go-icemulti write index
  
• go-icemulti write refs -b 5 -p 6,7,8,9

lzp2 es un algoritmo de compresión basado en tokens bastante sencillo, con el que he podido comprimir cada bistream de 32KB a 1KB. Naturalmente, utilizarlo implica un cambio de estrategia, en el siguiente sentido: en la flash sólo están descomprimidas las cinco imágenes iniciables por hardware. Por lo tanto, los punteros son siempre los mismos y la operación "cambio de puntero" lo que hace es descomprimir una imagen y guardarla en la posición correspondiente al puntero indicado.

¿No va a enlentecer la compresión demasiado el cambio de imágenes?¿No complicará este cambio cuando se quiera hacer desde la propia FPGA sin intervención de un uC externo? ¿Con la de sitio que hay en la memoria es necesario?¿Conveniente crear una fuente de posibles errores?

• Si se ejecuta desde el Arduino, como has comentado, se puede leer la imagen, descomprimirla y configurar la FPGA directamente. En este caso la flash es sólo un almacenamiento de alta capacidad para el Arduino.

Efectivamente. :)

• Si se ejecuta desde la FPGA, hay que leer la imagen, descomprimirla, escribirla y después resetearse (volviendo a leerla). Es más lento, pero tiene el potencial de disponer de miles de circuitos sin necesidad de ninguna CPU externa.

¿Quién descomprimiría?¿La propia FPGA?¿No consumiría muchos recursos? Mira que hablamos de la 1K... :)
 

No obstante, por el momento estoy limitándome al comando go-icemulti pack, que es prácticamente lo mismo que el icemulti original, pero admite más de cuatro imágenes y genera un índice compacto con metainformación (además de los punteros en sí). Este hilo lo he abierto justamente por esa metainformación. En principio voy a identificar cada imagen con una cadena "vendor:library:image:version:revision", de la que seguramente obtendré un hash.

¡Perfecto! Pero el icemulti ya guarda más de una imagen y únicamente hay que cambiar una constante... lo hace (muy ineficientemente, pero lo hace...)
¿Cómo tienes pensado acceder a esa metainformación?¿Desde la propia FPGA?¿Desde el PC?

El proyecto es estupendo... ¿Pero crees que es necesario acceder a esos bitstream comprimidos cuando ya disponemos de las fuentes Verilog y del software libre necesario para que cualquiera pueda generarlos?¿La idea sería conectar la placa con la FPGA a un puerto ethernet sin necesidad del PC ni de la toolchain de icestorm? ¿Para qué?

Ya me dices cuales son tus ideas al respecto...  :)

Saludos

Saludos. :)

[1138-4EB]

La última pregunta no la entiendo bien... imagino que por "coldboot" te refieres a "warnboot" (decidí usar esta característica del iCE40HX por no tener que andar con cables), pero aún así no entiendo... ¿Por "coolboot por defecto" te refieres al bitstream tal y como te lo entrega icemulti con los cinco vectores en el sitio indicado por el orden de empaquetamiento y el parámetro "-px" para el vector de reset? Si te refieres a esto... la respuesta es afirmativa, con el iceprog modificado (que está adjunto en uno de los mensajes) y la opción "-m" escribo "a piñón fijo" en una dirección de memoria de la flash correspondiente a uno de los vectores (la 0x29 creo recordar) un valor de prueba... pero claro, sin borrar el bloque... y es ahí donde al leer la flash (con iceprog) se ven ceros y algunos bytes con otros valores.

 
Utilizo los términos cold/warm indistintamente, ya que a efectos de sistema hacen exatamente lo mismo. Me refiero a programar el bistream tal como te lo entre icemulti con el parámetro -c. Y, después, sin borrar nada, grabar el mismo pack pero generado sin el parámetro -c. En ese caso la reprogramación debería ser efectiva. Este es el experimento mínimo para comprobar que puedes hacer cambios de un solo bit, si es para pasar a cero.

No sé a qué datasheet te refieres... ¿el de la memoria flash N25Q032A? Me he bajado como tres distintos de distintos fabricantes de esa misma memoria flash y claro, no me coinciden las páginas... :(

La que estoy mirando es la de Micron: https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_32mb_3v_65nm.pdf

Yo no he encontrado ningún otro fabricante con esa misma referencia. ¿Cuáles estás manejando?
 

 No, creo que no. Icemulti no usa nada la comunicación serie con la flash, no tiene parámetros para borrar ni programar ni nada... únicamente se encarga de empaquetar los distintos ficheros "bin" de distintas síntesis en uno solo que es el que luego se graba con iceprog... (seguro que ha sido un lapsus tuyo). Respecto iceprog y a los 64KB, eso sí... además te avisa con un mensaje cada vez que borra un sector.

Efectivamente, ha sido un lapsus mío. Me refería que en los los que pusiste se veía lo de los 64KB que comentas. Pero es por lo que dices, que con icemulti o sin él, siempre utilizas iceprog. Fallo de mi memoria, por haber visto el resultado de tus comandos en lugar de ejecutarlos yo ;).
 

Perfecto, entonces lo único que hay que hacer es leer el primer subsector (4KB,... muchos me parecen), borrarlo (llenarlo de unos), modificar los vectores y volver a grabar esos 4KB con los vectores ya modificados. En cuanto pueda sentarme en el laboratorio lo pruebo en la iceZUM Alhambra (desgraciadamente tengo por delante otro fin de semana en que no voy a poder). De todas formas me parecen muchos 4KB para cambiar solo tres bytes de un vector de dirección... pero bueno. :(

Bueno, a 33MHz lees esos 4KB en 2ms (suponiendo que por cada bit de información necesites enviar otro adicional). Aún así, no hay que leerlo entero. Si utilizas la opción `A` de icemulti, alineará también p0, por lo que la colocará en 32KB, en lugar de en la posición 256. Así, sólo tienes que leer 256 bytes, borrar el subsector de 4KB, y reescribir sólo los 256.

Siguen siendo 512 lecturas/escrituras para cambiar 3 bytes. Pero trantándose de memoria Flash y como estamos obligados a mantenernos en las primeras posiciones, poco más podemos hacer.
 

• Para cambiar el applet y activar el coldboot, borrar el primer subsector de 4KB. Para desactivarlo, no es necesario borrar.
  

Esto no lo entiendo... cambiar el applet sí (realmente yo cambiaría solo los cinco vectores que apuntan a las imágenes) y tal como yo había pensado... pero no entiendo lo de "Para desactivarlo, no es necesario borrar" ¿Por qué no es necesario borrrar?

Desactivar el cold/warm boot implica cambiar un bit de un uno a un cero. Por eso no hay que borrar el sector.

Para hacer cualquier cambio adicional, hay que borrar.
 

Tienes razón... pero eso de quitarte de en medio el FTDI y no tener que depender del PC... para mi es un avance, un logro :)

Incluso si funciona estoy pensando en soldar un Arduino Nano a una shield protoboard y conectarla directamente a la iceZUM Alhambra mediante el SPI... así ya tenemos el uC que pedías para controlar la FPGA... :)

Casualmente, mira lo que estuve bocetando el finde pasado...


 

¿No va a enlentecer la compresión demasiado el cambio de imágenes?¿No complicará este cambio cuando se quiera hacer desde la propia FPGA sin intervención de un uC externo? ¿Con la de sitio que hay en la memoria es necesario?¿Conveniente crear una fuente de posibles errores?

El tiempo de descompresión de un algoritmo basado de tokens es menor incluso que el de lectura del mismo contenido. Lo primero que lees es una tabla de una columna y después una cadena de índices. Por cada índice escribes la línea correspondiente de la tabla. Una vez cargado el diccionario dentro de la FPGA, consultar y leer en paralelo cada línea de la tabla es más rápido que leer equivalente en serie de la flash.
 
En cuanto a la complejidad, la compresión si tiene un requerimiento de memoria mayor. Posiblemente difícil de implementar en la FPGA, pero posible en Arduino: http://www.cbloom.com/src/index_lz.html En cualquier caso, ni siquiera es necesario comprimir en el Arduino, ya que en principio lo hará go-icemulti.

Mi interés principal es probar a implementar un algoritmo de descompresión lossless en la FPGA. Aunque los de este tipo no son útiles para otro tipo de aplicaciones que desarrollo, en este caso parece que funcionan muy bien (3% del tamaño original es brutal). Por ello, me sirve como excusa para i) ver qué limitaciones tiene el toolchain libre en un diseño que no sea un toy-example ii) estudiar cómo de compacto puede ser un bloque de decompresión hardware, y iii) disponer de un módulo que pueda adaptar/reutilizar.

A mayores, aunque utilicemos la flash por ser lo que tenemos disponible, no es el dispositivo más adecuado para andar reescribiendo casi continuamente (tiene un límite de 100.000 borrados por subsector). No es grave, porque cuesta menos de un euro y es un chip de ocho patas muy fácil de cambiar. Pero lo suyo sería utilizar una SRAM, que también las hay disponibles por SPI. Lo que pasa es que son más caras y no están disponibles en tamaños tan grandes. En este contexto sí que la complejidad adicional se ve compensada por la funcionalidad añadida.

• Si se ejecuta desde la FPGA, hay que leer la imagen, descomprimirla, escribirla y después resetearse (volviendo a leerla). Es más lento, pero tiene el potencial de disponer de miles de circuitos sin necesidad de ninguna CPU externa.

¿Quién descomprimiría?¿La propia FPGA?¿No consumiría muchos recursos? Mira que hablamos de la 1K... :)
 

Como he comentado, ahí está el reto. Todo lo anterior son los preparativos :D
 

¡Perfecto! Pero el icemulti ya guarda más de una imagen y únicamente hay que cambiar una constante... lo hace (muy ineficientemente, pero lo hace...)
¿Cómo tienes pensado acceder a esa metainformación?¿Desde la propia FPGA?¿Desde el PC?

Es cierto que lo hace en tu versión modificada (no en la distribución binaria, o la que podría incluir apio). Pero, al no estar pensada para ello, no es capaz de diferenciar entre imágenes direccionables y las de reserva. Eso es lo que considero la contribución. La implementación concreta puede variar.

Por el momento no he profundizado. En principio, no es para utilizarse en tiempo de ejecución, sino para poder relacionar un bitstream con sus fuentes:

Si yo te paso un pack con cincuenta imágenes y un manual de usuario, es posible que en algún momento quieras ver las fuentes y puede que hacer alguna modificación. Te puedo dar una lista ordenada de las imágenes, y decirte donde encontrar las fuentes. Hasta aquí no hay problema.

Ahora, tú reempaquetas todas las imagenes y la que has modificado en un nuevo pack, y los distribuyes. Si un usuario se descarga el mío original y el tuyo, ¿cómo puede compararlos? No es razonable que tenga que andar com hexdumps para ver las diferencias. Además, si por error se baja mi documentación y no la tuya, las fuentes que mire no se corresponderán con el bitstream.

Por otro lado, un tercero puede coger sólo la mitad del pack y juntarlo con otro que tenga, reordenando las imágenes además. Cómo ves, se complica. Sin embargo, si cada imagen tiene asociada una cadena única como la propuesta, se pueden distribuir los bitstream por un lado (empaquetados o de forma individual), las fuentes por otro, y la documentación aparte.

Esto no es nuevo. Así funciona el mercado de IP-cores. El estándar que se utiliza es IP-XACT, un mastodonte basado en XML. La idea es desplegar una estructura mínima y funcional, pero que respete la esencia de IP-XACT. De forma que, conforme crezca en complejidad, los cambios requieran añadir información, campos, parámetros, etc. pero que no sea necesario cambiar la arquitectura del sistema (léase, evitar reescribir las herramientas).

El proyecto es estupendo... ¿Pero crees que es necesario acceder a esos bitstream comprimidos cuando ya disponemos de las fuentes Verilog y del software libre necesario para que cualquiera pueda generarlos?¿La idea sería conectar la placa con la FPGA a un puerto ethernet sin necesidad del PC ni de la toolchain de icestorm? ¿Para qué?

Deducirás de la explicación anterior que la idea es más como los binarios en software. ¿Por qué utilizar apio en lugar de compilar el toolchain en tu ordenador? Principalmente, por tiempo. Si yo sólo quiero probar un circuito y ya está sintetizado para mi placa, me lo bajo, miro en la documentación cómo tengo que conectarla, y listo. Si después quiero modificar algo, ya iré a las fuentes.

En cuanto a Ethernet, personalmente no creo que las FPGAs se lleven bien con ello. Se puede hacer, pero es un tipo de código que no es adecuado para implementarlo en hardware, por su irregularidad. En todo caso, incluir una CPU blanda, eso sí es habitual y útil. Pero yo no estaba pensando en nada de eso. Metainformación, la parte importante es "meta".
 

Ya me dices cuales son tus ideas al respecto...  :)

Espero haberme explicado un poco mejor ;)

Saludos

[1138-4EB]

Se me olvidaba: sobre conectar el Nano por SPI, si vas a hacerlo pásate por el otro hilo, para valorar si hay que añadir alguna resistencia.

[Juanma Rico]

Buenas Unai... en rojo

El viernes, 17 de marzo de 2017, 21:44:06 (UTC+1), 1138-4EB escribió:

La última pregunta no la entiendo bien... imagino que por "coldboot" te refieres a "warnboot" (decidí usar esta característica del iCE40HX por no tener que andar con cables), pero aún así no entiendo... ¿Por "coolboot por defecto" te refieres al bitstream tal y como te lo entrega icemulti con los cinco vectores en el sitio indicado por el orden de empaquetamiento y el parámetro "-px" para el vector de reset? Si te refieres a esto... la respuesta es afirmativa, con el iceprog modificado (que está adjunto en uno de los mensajes) y la opción "-m" escribo "a piñón fijo" en una dirección de memoria de la flash correspondiente a uno de los vectores (la 0x29 creo recordar) un valor de prueba... pero claro, sin borrar el bloque... y es ahí donde al leer la flash (con iceprog) se ven ceros y algunos bytes con otros valores.

 
Utilizo los términos cold/warm indistintamente, ya que a efectos de sistema hacen exatamente lo mismo. Me refiero a programar el bistream tal como te lo entre icemulti con el parámetro -c. Y, después, sin borrar nada, grabar el mismo pack pero generado sin el parámetro -c. En ese caso la reprogramación debería ser efectiva. Este es el experimento mínimo para comprobar que puedes hacer cambios de un solo bit, si es para pasar a cero.

Ok, ahora sí. Lo probaré la semana que viene (aguantaré el SAV como pueda el fin de semana) y te cuento... casi seguro que desactiva el cold boot y se puede usar el warm boot... pero lo pruebo y confirmo. ;)

No sé a qué datasheet te refieres... ¿el de la memoria flash N25Q032A? Me he bajado como tres distintos de distintos fabricantes de esa misma memoria flash y claro, no me coinciden las páginas... :(

La que estoy mirando es la de Micron: https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_32mb_3v_65nm.pdf

Yo no he encontrado ningún otro fabricante con esa misma referencia. ¿Cuáles estás manejando?

Sí, la de Micron es la más completita... pero hay algún otro... ahora no recuerdo los otros... pero lo tengo en el git del equipo, lo miro, te lo digo y lo subiré al github para que sirva de documentación (por cierto, ya creé el proyecto en mi github, pero no le he dado mucha publicidad porque aún no hay mucho que contar y está un poco desordenado. Si por casualidad en el README.md o en cualquier otro fichero cometo alguna barrabasada o imprecisión encantado de corregir (un pull-request y listo... :-D).

 

 No, creo que no. Icemulti no usa nada la comunicación serie con la flash, no tiene parámetros para borrar ni programar ni nada... únicamente se encarga de empaquetar los distintos ficheros "bin" de distintas síntesis en uno solo que es el que luego se graba con iceprog... (seguro que ha sido un lapsus tuyo). Respecto iceprog y a los 64KB, eso sí... además te avisa con un mensaje cada vez que borra un sector.

Efectivamente, ha sido un lapsus mío. Me refería que en los los que pusiste se veía lo de los 64KB que comentas. Pero es por lo que dices, que con icemulti o sin él, siempre utilizas iceprog. Fallo de mi memoria, por haber visto el resultado de tus comandos en lugar de ejecutarlos yo ;).

Ya sabía yo que era un lapsus y no error de concepto. :-D

 

Perfecto, entonces lo único que hay que hacer es leer el primer subsector (4KB,... muchos me parecen), borrarlo (llenarlo de unos), modificar los vectores y volver a grabar esos 4KB con los vectores ya modificados. En cuanto pueda sentarme en el laboratorio lo pruebo en la iceZUM Alhambra (desgraciadamente tengo por delante otro fin de semana en que no voy a poder). De todas formas me parecen muchos 4KB para cambiar solo tres bytes de un vector de dirección... pero bueno. :(

Bueno, a 33MHz lees esos 4KB en 2ms (suponiendo que por cada bit de información necesites enviar otro adicional). Aún así, no hay que leerlo entero. Si utilizas la opción `A` de icemulti, alineará también p0, por lo que la colocará en 32KB, en lugar de en la posición 256. Así, sólo tienes que leer 256 bytes, borrar el subsector de 4KB, y reescribir sólo los 256.

Siguen siendo 512 lecturas/escrituras para cambiar 3 bytes. Pero trantándose de memoria Flash y como estamos obligados a mantenernos en las primeras posiciones, poco más podemos hacer.

¡Otra prueba que no se me había ocurrido! Me incrementas el SAV por momentos, no sé si aguantaré todo el fin de semana... ¡¡Hay que ponerlo a funcionar con el Arduino y hacer la iceZUM Alhambra independiente ya!! jajajaja

 

• Para cambiar el applet y activar el coldboot, borrar el primer subsector de 4KB. Para desactivarlo, no es necesario borrar.
  

Esto no lo entiendo... cambiar el applet sí (realmente yo cambiaría solo los cinco vectores que apuntan a las imágenes) y tal como yo había pensado... pero no entiendo lo de "Para desactivarlo, no es necesario borrar" ¿Por qué no es necesario borrrar?

Desactivar el cold/warm boot implica cambiar un bit de un uno a un cero. Por eso no hay que borrar el sector.

Para hacer cualquier cambio adicional, hay que borrar.

Ok, ok... relacionado con la primera prueba... :)

 

Tienes razón... pero eso de quitarte de en medio el FTDI y no tener que depender del PC... para mi es un avance, un logro :)

Incluso si funciona estoy pensando en soldar un Arduino Nano a una shield protoboard y conectarla directamente a la iceZUM Alhambra mediante el SPI... así ya tenemos el uC que pedías para controlar la FPGA... :)

Casualmente, mira lo que estuve bocetando el finde pasado...

jajajajajajaja, ¿No puedes esperar a la ICEStick que compraste en Mouser? jajajajajaja
Distingo la iCE40HK... ¿Lo otro es un micro? ¿haciendo de Arduino? jajajaja
¿La piensas construir de verdad? ¡Avísame que yo quiero una! :)

 

¿No va a enlentecer la compresión demasiado el cambio de imágenes?¿No complicará este cambio cuando se quiera hacer desde la propia FPGA sin intervención de un uC externo? ¿Con la de sitio que hay en la memoria es necesario?¿Conveniente crear una fuente de posibles errores?

El tiempo de descompresión de un algoritmo basado de tokens es menor incluso que el de lectura del mismo contenido. Lo primero que lees es una tabla de una columna y después una cadena de índices. Por cada índice escribes la línea correspondiente de la tabla. Una vez cargado el diccionario dentro de la FPGA, consultar y leer en paralelo cada línea de la tabla es más rápido que leer equivalente en serie de la flash.

Sí, pero nada más la tabla consume recursos de la FPGA...¿los LUTs de cada CBL?¿o quizás otros bloques de RAM? Ya por curiosidad... ¿Sabes si se puede elegir al sintetizar dónde poner dicha tabla? Lo que es seguro es que con la iCE40 andamos faltos de todo... :(

 
En cuanto a la complejidad, la compresión si tiene un requerimiento de memoria mayor. Posiblemente difícil de implementar en la FPGA, pero posible en Arduino: http://www.cbloom.com/src/index_lz.html En cualquier caso, ni siquiera es necesario comprimir en el Arduino, ya que en principio lo hará go-icemulti.

Mi interés principal es probar a implementar un algoritmo de descompresión lossless en la FPGA. Aunque los de este tipo no son útiles para otro tipo de aplicaciones que desarrollo, en este caso parece que funcionan muy bien (3% del tamaño original es brutal). Por ello, me sirve como excusa para i) ver qué limitaciones tiene el toolchain libre en un diseño que no sea un toy-example ii) estudiar cómo de compacto puede ser un bloque de decompresión hardware, y iii) disponer de un módulo que pueda adaptar/reutilizar.

Ahora sí le veo la utilidad... Si te sirve como excusa para hacer todas esas cosas... por mi perfecto... espero aprender de todo ello, todo lo que pueda y todo lo que me dejes... Con tu permiso, claro... :D
 

A mayores, aunque utilicemos la flash por ser lo que tenemos disponible, no es el dispositivo más adecuado para andar reescribiendo casi continuamente (tiene un límite de 100.000 borrados por subsector). No es grave, porque cuesta menos de un euro y es un chip de ocho patas muy fácil de cambiar. Pero lo suyo sería utilizar una SRAM, que también las hay disponibles por SPI. Lo que pasa es que son más caras y no están disponibles en tamaños tan grandes. En este contexto sí que la complejidad adicional se ve compensada por la funcionalidad añadida.

• Si se ejecuta desde la FPGA, hay que leer la imagen, descomprimirla, escribirla y después resetearse (volviendo a leerla). Es más lento, pero tiene el potencial de disponer de miles de circuitos sin necesidad de ninguna CPU externa.

¿Quién descomprimiría?¿La propia FPGA?¿No consumiría muchos recursos? Mira que hablamos de la 1K... :)
 

Como he comentado, ahí está el reto. Todo lo anterior son los preparativos :D

Desde luego es un reto, de eso no hay duda... :)

 

 

¡Perfecto! Pero el icemulti ya guarda más de una imagen y únicamente hay que cambiar una constante... lo hace (muy ineficientemente, pero lo hace...)
¿Cómo tienes pensado acceder a esa metainformación?¿Desde la propia FPGA?¿Desde el PC?

Es cierto que lo hace en tu versión modificada (no en la distribución binaria, o la que podría incluir apio). Pero, al no estar pensada para ello, no es capaz de diferenciar entre imágenes direccionables y las de reserva. Eso es lo que considero la contribución. La implementación concreta puede variar.

Por el momento no he profundizado. En principio, no es para utilizarse en tiempo de ejecución, sino para poder relacionar un bitstream con sus fuentes:

Si yo te paso un pack con cincuenta imágenes y un manual de usuario, es posible que en algún momento quieras ver las fuentes y puede que hacer alguna modificación. Te puedo dar una lista ordenada de las imágenes, y decirte donde encontrar las fuentes. Hasta aquí no hay problema.

Ahora, tú reempaquetas todas las imagenes y la que has modificado en un nuevo pack, y los distribuyes. Si un usuario se descarga el mío original y el tuyo, ¿cómo puede compararlos? No es razonable que tenga que andar com hexdumps para ver las diferencias. Además, si por error se baja mi documentación y no la tuya, las fuentes que mire no se corresponderán con el bitstream.

Por otro lado, un tercero puede coger sólo la mitad del pack y juntarlo con otro que tenga, reordenando las imágenes además. Cómo ves, se complica. Sin embargo, si cada imagen tiene asociada una cadena única como la propuesta, se pueden distribuir los bitstream por un lado (empaquetados o de forma individual), las fuentes por otro, y la documentación aparte.

Esto no es nuevo. Así funciona el mercado de IP-cores. El estándar que se utiliza es IP-XACT, un mastodonte basado en XML. La idea es desplegar una estructura mínima y funcional, pero que respete la esencia de IP-XACT. De forma que, conforme crezca en complejidad, los cambios requieran añadir información, campos, parámetros, etc. pero que no sea necesario cambiar la arquitectura del sistema (léase, evitar reescribir las herramientas).

¡Sería genial disponer de esa herramienta de forma libre!
Si esa es tu idea me apunto... aunque no se me ocurre en qué podría ayudar...
ya me está costando grabar una simple flash... jajajajajaja :)

El proyecto es estupendo... ¿Pero crees que es necesario acceder a esos bitstream comprimidos cuando ya disponemos de las fuentes Verilog y del software libre necesario para que cualquiera pueda generarlos?¿La idea sería conectar la placa con la FPGA a un puerto ethernet sin necesidad del PC ni de la toolchain de icestorm? ¿Para qué?

Deducirás de la explicación anterior que la idea es más como los binarios en software. ¿Por qué utilizar apio en lugar de compilar el toolchain en tu ordenador? Principalmente, por tiempo. Si yo sólo quiero probar un circuito y ya está sintetizado para mi placa, me lo bajo, miro en la documentación cómo tengo que conectarla, y listo. Si después quiero modificar algo, ya iré a las fuentes.

Me gusta la idea... si lo asocio con mi experiencia en el software libre (GNU/Linux)... nunca me pareció ágil lo de Gentoo... para probar un programa tenías que compilarlo todo desde cero... y luego lo ejecutabas y resulta que el programa era una decepción o no era o hacía lo que tú pensabas... el disco duro lleno de bibliotecas que no ibas a utilizar jamás... :(
Debian en el sentido contrario me cautivó., te bajas por separado ejecutable y fuente. :)
 

En cuanto a Ethernet, personalmente no creo que las FPGAs se lleven bien con ello. Se puede hacer, pero es un tipo de código que no es adecuado para implementarlo en hardware, por su irregularidad. En todo caso, incluir una CPU blanda, eso sí es habitual y útil. Pero yo no estaba pensando en nada de eso. Metainformación, la parte importante es "meta".

Sí, yo pensé que te referías a que la FPGA se conectaba a Internet para descargar los binarios directamente del repositorio... pero está claro que se necesitaría un equipo externo para gestionar estas imágenes binarias por la red y luego descargar las elegidas en la flash conectada a la FPGA.
 

 

Ya me dices cuales son tus ideas al respecto...  :)

Espero haberme explicado un poco mejor ;)

Siempre te explicas bien, pero yo tengo que releer y procesar... y entre lectura y relectura, a veces, me bloqueo... ;)

Saludos

Igualmente.

[1138-4EB]

Buenos días Juanma!

 

Sí, la de Micron es la más completita... pero hay algún otro... ahora no recuerdo los otros... pero lo tengo en el git del equipo, lo miro, te lo digo y lo subiré al github para que sirva de documentación (por cierto, ya creé el proyecto en mi github, pero no le he dado mucha publicidad porque aún no hay mucho que contar y está un poco desordenado. Si por casualidad en el README.md o en cualquier otro fichero cometo alguna barrabasada o imprecisión encantado de corregir (un pull-request y listo... :-D).

He echado un ojo, y no hay ninguna barrabasada ;). Sólo tres detalles:

• Los dos enlaces de final no son correctos. No existe 'github.com/juanmard/icezum/CoolBoot', sí 'github.com/juanmard/icezum/tree/master/ColdBoot'
• No es si es legal que tengas alojados en el repositorio documentos con copyright. Yo por si acaso suelo subir un fichero de texto con una lista de enlaces donde obtener los documentos, pero los PDF en sí los tengo sólo en local. A mayores, a Git no le sienta nada bien que haya PDFs en el repo.
• 'necesita de una PROM (Programable ROM, chip tipo flash)'. Estrictamente, no necesita 'una' tipo flash. Necesita una PROM, y en el caso de la Alhambra es tipo flash. El cambio más fácil es que sustituyas 'una' por 'la', en referencia concreta a la de la Alhambra. Pero dejo a tu criterio cómo hacer la distinción/aclaración.
  

¡Otra prueba que no se me había ocurrido! Me incrementas el SAV por momentos, no sé si aguantaré todo el fin de semana... ¡¡Hay que ponerlo a funcionar con el Arduino y hacer la iceZUM Alhambra independiente ya!! jajajaja

Con Verilog-VHDL puedes hacer un modelo de la Alhambra y simularlo todo aunque sea fin de semana...

Es broma. Ni se te ocurra :P. Pero como concepto es técnicamente posible: http://www.freemodelfoundry.com/whatsnew.php
 

jajajajajajaja, ¿No puedes esperar a la ICEStick que compraste en Mouser? jajajajajaja
Distingo la iCE40HK... ¿Lo otro es un micro? ¿haciendo de Arduino? jajajaja
¿La piensas construir de verdad? ¡Avísame que yo quiero una! :)

¡El pedido me llegó el lunes-martes! Digamos que la lié un poco. La iCEstick eran 22€, y los gastos de envío costaban otro tanto. Como a partir de 50€ el envío era gratis, cogí dos, un par de memorias flash (64 y 128 Mb, 3€ las dos) y una FPGA HX4K (6€). Bueno, eso pensé, pero lo hice por la noche y a la mañana siguiente me di cuenta de que había pedido una HX1K :S. Hablé con ellos por teléfono, pero no podían cambiar el componente. Amablemente me indicaron que podía coger la HX4K y me la enviaban gratis. Así que eso hice. Total, tengo 2 icestick, una HX1K suelta, otra HX4K suelta y dos memorias sueltas. Demasiado material para tan poco PCB :D. Una de esas memorias era para sustituir la de una de las icestick, y la idea era sustituir la HX1K por la HX4K. Pero si lo hago, me quedo con dos HX1K sueltas, una memoria de 32Mb y la otra de 64 o 128. Así que, por qué no hacer un par de PCBs sencillos, dejar las icesticks intactas y hacer las pruebas directamente con el material restante. Las dos parejas de FPGAS y memorias por 15€, bien merecen jugársela a hacer algo mal.

La imagen anterior son dos PCBs diferentes. Y básicamente es una Alhambra v1.1 partida en cuatro:

• Potencia/alimentación
• FTDI + USB
  
• Conversores de tensión 3,3v-5v
• FPGA + Flash
  

La parte FTDI + USB desaparece directamente y la de potencia/alimentación no está en ese dibujo.

Lo que ves a la derecha es una 'shield' para pinchar directamente un Arduino Nano. Algo como esto: http://ep.yimg.com/ca/I/yhst-27389313707334_2252_106614573 Pero con tiras de pines, en lugar de los conectores con tornillo. Los cuatro integrados son los conversores de tensión 3,3v-5v. Tiene más que la Alhambra y con alguna salida adicional, para obtener un total de 38 conexiones a la FPGA. El conector CONN_2x20 que está en la mitad inferior, en horizontal. Además, en la parte inferior, un conector para recibir 3,3v, 5v y GND, interruptor para encender/apagar, y dos LEDs para indicar si las dos líneas de alimentación están bien. Opcionalmente, se pueden conectar dos Arduino Nano, utilizando uno de los laterales de cada uno.

En la parte central está la placa de la FPGA + Flash. En la parte superior derecha se ve el conector CONN_2x20 al que iría conectada la 'shield'. En la parte central derecha, ocho LEDs de propósito general, el conector de alimentación (1,2v, 3,3v y GND), el interruptor, y dos LEDs para indicar el estado de la alimentación. Debajo, los conectores de 6 y 2 pines que están pegados, son los de programación SPI. A diferencia de la Alhambra, los pines CS de la Flash y SS de la FPGA no están conectados en la placa. El conector de dos pines es un jumper por si se quiere hacer. Hay dos LEDs justo debajo del conector de 6, para indicar si se está programando la FPGA, la Flash o ambas. El conector de cuatro son CBSEL0, CBSEL1, CDONE y CRESET. A su izquierda, la Flash y el circuito de reset. Debajo del todo, un conector de 14 pines conectados directamente a la FPGA. Para, por ejemplo, conectar todos los pines digitales de otro Arduino Nano (a 3,3v). Se puede meter el Nano directamente, sin cable, aunque perdemos D13. Además, uno de esos 14 pines está rutado a una entrada/salida de las líneas especiales de reloj de la FPGA. En la parte central izquierda, el botón de reset, y un conector de ocho pines, que va a las ocho líneas especiales de reloj de la FPGA. Por último, en la parte superior izquierda, está el reloj en sí, y en la capa bottom otro conector CONN_2x20 que provee 38 conexiones directas a la FPGA (sin conversores de tensión intermedios).

Los tres conectores adicionales a la izquierda son para proveer puntos de alimentación al usuario, pero irán en la placa de alimentación. Lo otro es un rotatory encoder con pulsador. Iba a meterlo en la placa central, pero es enorme, así que se quedará aparte. Total, son tres conexiones nada más.

¿Fabricarlo? Lo veo difícil. Es más un proyecto para cacharrear con Kicad y ver hasta dónde puedo llegar. Una prueba de concepto. Lo que he hecho ha sido a partir del diseño de 4 capas recomendado por Lattice. Pero creo que la elección de esos conectores es demasiado ambiciosa. En general todo está excesivamente pegado (fíjate que la placa de la FPGA es de menos de 4,5cm x 4,5cm). No tengo experiencia rutando líneas de alimentación debidamente. Y tengo varias dudas importantes en lo que respecta a la conexión de múltiples maestros SPI, además de lo que sería la placa de alimentación en sí. Pero, quién sabe, a medio plazo, si va cogiendo mejor pinta, por qué no hacer un par de prototipos. La idea de conectar tres Arduino Nano y poder experimentar con computación paralela y coejecución de CPUs + aceleradores hardware desde luego es muy tentadora. El rendimiento sería nefasto, pero todo hardware """libre""".
 

Sí, pero nada más la tabla consume recursos de la FPGA...¿los LUTs de cada CBL?¿o quizás otros bloques de RAM? Ya por curiosidad... ¿Sabes si se puede elegir al sintetizar dónde poner dicha tabla? Lo que es seguro es que con la iCE40 andamos faltos de todo... :(

Los algoritmos de compresión permiten escoger, dentro de unos límites, muchas entradas muy cortas o pocas pero más largas. Dependiendo del resultados, será mejor en LUTs o en BRAM. De todas formas, serviría con un solo bloque BRAM. Además, no tiene que estar reservado exclusivamente para este propósito: se utiliza por el circuito que esté configurado y, cuando se vaya a cambiar de imagen, se aprovecha temporalmente.

Sí, se puede elegir dónde ponerla. Los sintetizadores suelen hacerlo de forma automática:

• Si describimos una memoria que responda en el mismo ciclo, o que tenga más puertos de los que soportan las BRAM, se sintetiza como LUTs.
• Si describimos una memoria cuyo modelo se pueda implementar en una BRAM, pero es de tamaño reducido, se sintetiza como LUTs.
• El resto se sintetizan como BRAM.

Luego, cada sintetizador provee directivas para especificar que una memoria pequeña queremos meterla en BRAM, o que una grande queremos que se haga mediante LUTs.
 

¡Sería genial disponer de esa herramienta de forma libre!
Si esa es tu idea me apunto... aunque no se me ocurre en qué podría ayudar...
ya me está costando grabar una simple flash... jajajajajaja :)

Cada cual a su ritmo y en el ámbito que le es conocido. Créeme que si yo me pongo ahora a programar la Flash, me va a costar lo mismo o más que a ti. Aunque sé cómo tienen que funcionar las cosas, no he escrito nunca la secuencia concreta de instrucciones/comandos. Te veo mucho más hábil/animado para experimentar aunque no siempre tengas muy claro el resultado. A mí me cuesta mucho darle a programar, antes de estar seguro de saber qué va a pasar.

En el tema de los IP-cores, poco hay que hacer aquí. Esperar a que Jesús pase por el otro hilo para ver si hay alguna posibilidad de llegar a un entendimiento sobre el tamaño y formato del hash. Si no, simplemente habrá dos formatos paralelos. A partir de ahí, se podría hacer un "empaquetador": le das el código en verilog y las documentación en formato Markdown, y te genera un tar.gz con las fuentes, el o los bitstream y un PDF que incluye la documentación y el código comentado. Adicionalmente, puede generar una página web de cada componente en el sistema. No te asustes, que todo eso ya está hecho. Sólo hay que integrar Doxygen, Pandoc, Hugo u otro similar.

Puede que ponernos de acuerdo también en un fichero de repositorios. Un JSON que pueda cargar cualquier aplicación y donde encuentre las URL de repositorios con los tar.gz. He dicho que uno o varios bitstream, porque el paquete puede incluir bitstreams para varias placas. Así, se podría añadir un travis.yml, que dado un nuevo diseño y la documentación, sintetice y genere bitstreams para un conjunto de placas. Ese travis puede en realidad ejecutar un contenedor de docker, de forma que el repositorio no tendría que alojar los bitstream, porque el usuario podría lanzar el mismo contenedor y que se le generen de forma transparente.

Adicionalmente, hay varios repositorios libres de diseños HDL (OpenCores, LibreCores, FreeRangeFactory...). Se podrían implementar getters para ellos. De forma que la URL se añada con algún atributo para saber que hay que desempaquetar las fuentes de forma diferente, y puede que añadir las constraints de asociación de pines físicos.

Ten en cuenta que estoy hablando de Verilog en todo momento. No sé cómo encajaría en icestudio, con el formato actual de ICE.

En cualquier caso, todo esto es software, comunidad y cultura de la remezcla. A nivel técnico lo único que nos interesa en este hilo es incluir un identificador "único" en la flash junto a cada puntero.
 

Me gusta la idea... si lo asocio con mi experiencia en el software libre (GNU/Linux)... nunca me pareció ágil lo de Gentoo... para probar un programa tenías que compilarlo todo desde cero... y luego lo ejecutabas y resulta que el programa era una decepción o no era o hacía lo que tú pensabas... el disco duro lleno de bibliotecas que no ibas a utilizar jamás... :(
Debian en el sentido contrario me cautivó., te bajas por separado ejecutable y fuente. :)

Me gusta la analogía. El objetivo es Arch. Hay partes precompiladas (el toolchain y post-sintesis) y partes en fuentes (pre-sintesis). Tú puedes descargarte los bitstream, si existen. Si no, puedes bajar el netlist post-sintesis y hacer solo el place and route. O, si quieres, puedes hacerlo todo desde las fuentes, lo que incluye cambiar la funcionalidad.

En cuanto a tener el disco duro lleno de bibliotecas... Juanma, te presento a Docker. Vais a tener una relación muy larga, así que empezad con tranquilidad. Os muestro el primer paso:

sudo apt-get install docker-ce
sudo docker run --rm -it fedora bash

Sí, efectivamente, has ejecutado una ""máquina virtual"" de Fedora y estás dentro. Haz 'dnf update', utiliza herramientas que sólo estén en Fedora. Cuando te aburras, escribe 'exit', y volverás a tu Debian. Todo lo que hayas hecho ha desaparecido. Tu sistema "no sabe" que ha estado ejecutando Fedora, no hay ninguna librería instalada.

En otras palabras, docker te permite descargar en una "imagen" todas las librerías que le faltan a tu sistema para ejecutar cualquier cosa que quieras. Las descomprime en un proceso aislado que sólo ve ese sistema de archivos y no el de tu sistema real, y cuando te marchas desaparecen todas y sólo queda la "imagen" original. Esa imagen es un fichero comprimido de entre 2MB y 10GB, depende de qué es lo que haya en la imagen. Si la imagen se ha generado a través de un script, puedes ver exactamente qué órdenes se han utiliado. Ejemplo de la imagen que se utiliza para compilar GHDL en Ubuntu: https://hub.docker.com/r/ghdl/ghdl-tools/~/dockerfile/

Yo lo he utilizado, por ejemplo, para distribuir instalaciones de OpenFOAM. Tarda unas 6 horas en compilar, y necesitas 3GB de librerías. La imagen de docker ocupa 1.37GB (todavía estoy analizando cómo quitarle más) y está lista para usar. Lo que es más importante, cualquier usuario que la utilice estará exactamente en el mismo entorno, por lo que los "problemas" son directamente reproducibles.

Sí, estoy trabajado en cómo meter icestorm en docker. Es como Apio, pero sin compilación cruzada. El sistema se compila una sola vez.

Por cierto, utilizo docker a diario en Windows 10, para probar cosas en Fedora, Debian y Alpine Linux al mismo tiempo. Y las mismas imágenes de docker funcionan en una Raspberry Pi :D :D :D.

Tengo la sensación de que vas a encontrar entretenimiento hasta poder echar mano a la Alhambra....

Saludos

 

[1138-4EB]

Releyéndolo, parece contradictorio lo de fabricar o no el PCB. Uno voy a hacer para aprovechar el material. Pero no sé si será ese tan complejo e incompleto, o simplemente aprovecharé algún diseño como el de la Kéfir.

[Juanma Rico]

Buenas a todos,

Tengo esto un poco abandonado y es que estos días ando intentando sacar lo suficiente como para pagar la cuota de autónomo de este mes y no morir en el intento... :(

Gracias Unai por las correcciones, en cuanto me siente con tranquilidad lo corrijo todo y lo dejo limpito (entre otras cosas seguiré tu consejo de no dejar los PDF en github). Quiero subir también un Makefile o algo similar porque me he dado cuenta que ni hay documentación suficiente ni forma de probar fácilmente la cosa sin leer este hilo (que ya empieza a ser largo).

Hoy me he podido sentar un rato pero apenas he tenido tiempo para probar lo de generar la opción "-c" y ver si se desactiva el warmboot y aparece el coldboot. La prueba no ha sido satisfactoria, no me ha dado tiempo a comprobar demasiado... pero he visto que "-c" genera una imagen bin final totalmente distinta al generado para el warmboot con los mismos argumentos (demasiados cambios en demasiados bytes), no cambia únicamente el byte por 0x10, cambia muchos más... así que ni grabar la prueba en la iceZUM Alhambra me he atrevido.

Me queda por probar lo de leer y grabar un subsector (4KB) y ver si realmente es lo mínimo necesario para grabar los primeros 256 bytes del applet y así cambiar los vectores.

A ver si un próximo día puedo dedicarle más tiempo y avanzamos.
Saludos.


El sábado, 18 de marzo de 2017, 12:44:44 (UTC+1), 1138-4EB escribió:

Buenos días Juanma!

[1138-4EB]

Hola Juanma,

Creo que andamos parecido. A mí me petó Windows el lunes, y he estado intentando resituarme en un escritorio GNU/Linux. Tengo gráfica NVIDIA, wifi WN725N y un teclado donde Ctrl/Win/Alt funcionan como Shift (cuestión de driver, no arreglable con configuración)... Para más INRI, quería Enlightenment, porque ni KDE ni Gnome Shell me convencen. Total, que tras pasar por varias Arch y Debian, he acabado desesperado, con Fedora y XFCE, con drivers de NVIDIA, sin wifi y cambiando de teclado. Después me he acordado de por qué no tenía un linux funcional en este equipo...

Así que lo que queda de semana tengo que recuperar.

Me han respondido de Lattice explicándome cómo programar la placa con sus herramientas y por qué el scan no funciona con la icestick (supongo que tampoco con la Alhambra). Pero, lo dicho, tengo que terminar un par de cosas primero.

Quiero subir también un Makefile o algo similar porque me he dado cuenta que ni hay documentación suficiente ni forma de probar fácilmente la cosa sin leer este hilo (que ya empieza a ser largo).

Buena idea.
 

Hoy me he podido sentar un rato pero apenas he tenido tiempo para probar lo de generar la opción "-c" y ver si se desactiva el warmboot y aparece el coldboot. La prueba no ha sido satisfactoria, no me ha dado tiempo a comprobar demasiado... pero he visto que "-c" genera una imagen bin final totalmente distinta al generado para el warmboot con los mismos argumentos (demasiados cambios en demasiados bytes), no cambia únicamente el byte por 0x10, cambia muchos más... así que ni grabar la prueba en la iceZUM Alhambra me he atrevido.

Si puedes subir los bin en algún momento...
 
Saludos

[Juanma Rico]

Buenas Unai,

A mi ayer a última hora también me petó la impresora 3D y justo cuando más la necesitaba para un proyecto (por cierto, es la Y-Wing hija de la X-Wing, por tanto nieta de la R2D2. Me la ha cedido Daniel Casares "para que aprenda esto de la impresión 3D" y mientras tanto, la intente restaurar... osea que tiene historia la impresora... ¡y aún sigue imprimiendo! :D). Sospecho que tanto pete es la primavera que ya la ha traído El Corte Inglés y andan los circuitillos locos... jejejeeje :)

Aunque hoy tampoco tengo mucho tiempo, sí tengo el suficiente para adjuntar los bin, así que con el mensaje los llevas. Yo hice una comparativa rápida y las diferencias en los números de bytes distintos se dispararon.

Para generarlos estos fueron los comandos:

$ ./icemulti -p9 -o pack.bin counter8.bin led_on.bin pushbutton_and.bin  counter.bin shift4.bin blink.bin tones.bin counter.bin counter8.bin hardware.bin

$ ./icemulti -c -o pack_cb.bin counter8.bin led_on.bin pushbutton_and.bin  counter.bin shift4.bin blink.bin tones.bin counter.bin counter8.bin hardware.bin

Siempre, claro, con el icemulti modificado para compactar 10 imágenes.
A ver si puedes sacar alguna conclusión con ellos.

Saludos.

[1138-4EB]

Aupa Juanma,

Casi que prefiero un catarro y que los equipos funcionen... XD

Con respecto a los bitstream, buenas noticias. Salvo que la haya liado yo, has hecho la comparativa con algún programa que "acumula" las diferencias. Prueba esto:

meld <(hexdump -C pack.bin) <(hexdump -C pack_cb.bin)

Se abrirá una GUI, así que hazlo desde un escritorio. Alternativamente, puedes usar diff:

[user@localhost Downloads]$ diff <(hexdump -C pack.bin) <(hexdump -C pack_cb.bin)
1c1
< 00000000  7e aa 99 7e 92 00 00 44  03 04 6e 0c 82 00 00 01  |~..~...D..n.....|
---
> 00000000  7e aa 99 7e 92 00 10 44  03 00 01 60 82 00 00 01  |~..~...D...`....|

En cualquier caso:

7e aa 99 7e 92 00 00 44  03 04 6e 0c 82 00 00 01
7e aa 99 7e 92 00 10 44  03 00 01 60 82 00 00 01

En negrita lo que creo que es el coldboot, y en cursiva el puntero. Si generas pack con '-c -p9', deberían ser iguales salvo por ese bit.

Un saludo

[Juan Gonzalez Gomez]

Es plástico de mi plástico!!!!! 😀😀😀

--
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/2c47e0cd-76dc-4942-8d38-71f8f57049d3%40googlegroups.com.

[Juanma Rico]

¡Mira que eres cabrón! ¿No te he dicho que no tenía tiempo?
¡Hala, tú alimentando el SAV! jajajajajajaja :)

He tenido que hacer una prueba rápida, no quedaba otra... :)
Te contesto en tu mensaje.

El jueves, 23 de marzo de 2017, 11:39:39 (UTC+1), 1138-4EB escribió:

Aupa Juanma,

Casi que prefiero un catarro y que los equipos funcionen... XD

Con respecto a los bitstream, buenas noticias. Salvo que la haya liado yo, has hecho la comparativa con algún programa que "acumula" las diferencias. Prueba esto:

Lo hice con cmp porque no sabía comparar binarios con diff,... :(
¡Ahora ya puedo decir que sé! ¡gracias! :)

meld <(hexdump -C pack.bin) <(hexdump -C pack_cb.bin)

Se abrirá una GUI, así que hazlo desde un escritorio. Alternativamente, puedes usar diff:

[user@localhost Downloads]$ diff <(hexdump -C pack.bin) <(hexdump -C pack_cb.bin)
1c1
< 00000000  7e aa 99 7e 92 00 00 44  03 04 6e 0c 82 00 00 01  |~..~...D..n.....|
---
> 00000000  7e aa 99 7e 92 00 10 44  03 00 01 60 82 00 00 01  |~..~...D...`....|

Comprobados ambos, pero las diferencias son las mismas... solo que parece que con meld y diff se paran en la primera... ¿Puede ser?

Imagino que el tratamiento que hace icemulti es distinto según se incluya el parámetro "-c" o no.
 

En cualquier caso:

7e aa 99 7e 92 00 00 44  03 04 6e 0c 82 00 00 01
7e aa 99 7e 92 00 10 44  03 00 01 60 82 00 00 01

En negrita lo que creo que es el coldboot, y en cursiva el puntero. Si generas pack con '-c -p9', deberían ser iguales salvo por ese bit.

No, no es posible. Icemulti trata esos parámetros como parámetros excluyentes entre sí... :(
Te lanza esto:

 

$ ./icemulti -c -p9 -o pack_cbp.bin counter8.bin led_on.bin pushbutton_and.bin  counter.bin shift4.bin blink.bin tones.bin counter.bin counter8.bin hardware.bin
 
Error: Can't select power on reset boot image in cold boot mode

Aún así me he atrevido, he programado el pack_cb.bin en la iceZUM Alhambra sin borrar previamente el pack.bin grabado anteriormente y se queda "tostada" (los leds a medio encender y no responde al reset), imagino que el resto de diferencias, incluido el vector que cambia en el applet, hace estragos al no poder cambiar ceros por unos.

$ iceprog -n pack_cb.bin

En cuanto pueda pruebo lo de grabar los 4KB del subsector y si funciona, con eso sería suficiente para poder grabar los vectores modificados (y ya podríamos intentar integrarlo en apio), esta era una prueba interesante, pero tampoco aportaba mucho a la hora de conseguir el objetivo de ampliar las posibilidades de la placa.
 

Un saludo

Saludos.
 

[Juanma Rico]

¡Síiiiiiiii! jajajajajajaja  :)

Juan, me encantó descubrir esta foto tuya con Dani... ¡Historia pura!
A los que no lo pudimos vivir solo nos queda recordar... ¡Pero encantados de hacerlo!

Un saludo

[Juan Gonzalez Gomez]

jjajjaajajjaj En la prehistoria de la impresión 3D jjajajaj

¡Qué recuerdos!

Saludos, Juan

--

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/5ff74c8b-106f-4590-ab73-13c04f9c8e34%40googlegroups.com.

[Jesús Arroyo]

Sí, qué recuerdos!!

Me suena de algo esa foto, jejeje

[Unai Martinez]

¡Mira que eres cabrón! ¿No te he dicho que no tenía tiempo?
¡Hala, tú alimentando el SAV! jajajajajajaja :)

Me lo has puesto muy a huevo ;)

 

Comprobados ambos, pero las diferencias son las mismas... solo que parece que con meld y diff se paran en la primera... ¿Puede ser?

Depende de cómo tengas configurado meld y cómo llames a diff. A veces la configuración por defecto sólo muestra las diferencias. Por lo que no es que se paren, es que no hay más. En meld puedes indicarle si quieres que te muestre el contenido igual también.

 

No, no es posible. Icemulti trata esos parámetros como parámetros excluyentes entre sí... :(
Te lanza esto:

 

$ ./icemulti -c -p9 -o pack_cbp.bin counter8.bin led_on.bin pushbutton_and.bin  counter.bin shift4.bin blink.bin tones.bin counter.bin counter8.bin hardware.bin
 
Error: Can't select power on reset boot image in cold boot mode

Diría que se pueda abrir una issue para comentarle que no son excluyentes.

 

Aún así me he atrevido, he programado el pack_cb.bin en la iceZUM Alhambra sin borrar previamente el pack.bin grabado anteriormente y se queda "tostada" (los leds a medio encender y no responde al reset), imagino que el resto de diferencias, incluido el vector que cambia en el applet, hace estragos al no poder cambiar ceros por unos.

Un poquillo animal si que has sido. Efectivamente has escrito como puntero 0 una operación OR:

04 6e 0c
00 01 60

0000 0100 0110 1110 0000 1100
0000 0000 0000 0001 0110 0000

04 6F 6C

Y ese no es el inicio de ninguna imagen. Ten en cuenta que 046e0c es el inicio de la imagen p9 y 000160 es el inicio de la imagen p0. Pero el resultado de la OR de ambas esá entre p9 y p10.

Por otro lado, ten cuidado con utilizar 10 imágenes para hacer estas pruebas. Al hacerlo, estás utilizando un applet de más de 256 bytes, por lo que estás desplazando p0 hacia abajo. Si p1 no se mueve porque está alineada en un sector de 32KB, llegará un momento en que p0 no quepa. Compruébalo por si acaso. Los números están en este hilo. O usa 5-6 y así evitas problemas.

Cuando programas un bitstream generado con la opción -c, parece sensato pensar que la FPGA arranca directamente con la imagen indicada en la primera linea del applet. Es decir, en el primerísimo power on da igual qué este seleccionado en los pulsadores. Si es así, ahí tienes tu carga incompleta. Si no, no debería.

Saludos

[Juanma Rico]

Con un poco más de tiempo intento corregir los errores del proyecto de github y me leeo los mensajes con más detenimiento.

El sábado, 18 de marzo de 2017, 12:44:44 (UTC+1), 1138-4EB escribió:

Buenos días Juanma!

 

Sí, la de Micron es la más completita... pero hay algún otro... ahora no recuerdo los otros... pero lo tengo en el git del equipo, lo miro, te lo digo y lo subiré al github para que sirva de documentación (por cierto, ya creé el proyecto en mi github, pero no le he dado mucha publicidad porque aún no hay mucho que contar y está un poco desordenado. Si por casualidad en el README.md o en cualquier otro fichero cometo alguna barrabasada o imprecisión encantado de corregir (un pull-request y listo... :-D).

He echado un ojo, y no hay ninguna barrabasada ;). Sólo tres detalles:

• Los dos enlaces de final no son correctos. No existe 'github.com/juanmard/icezum/CoolBoot', sí 'github.com/juanmard/icezum/tree/master/ColdBoot'

Pensé el esquema de subdirectorios antes de crearlos, me di cuenta pero se me olvidó cambiar los enlaces (mi falta de experiencia en GitHub. Corregido.

• No es si es legal que tengas alojados en el repositorio documentos con copyright. Yo por si acaso suelo subir un fichero de texto con una lista de enlaces donde obtener los documentos, pero los PDF en sí los tengo sólo en local. A mayores, a Git no le sienta nada bien que haya PDFs en el repo.

Lista de enlaces creado en el README.md. He creado un .gitignore que filtre mis PDF locales, he borrado la caché (git rm --cached  doc/*.pdf), pero no consigo que se borren y dejen de estar visibles los ficheros en GitHub. Para investigar.

• 'necesita de una PROM (Programable ROM, chip tipo flash)'. Estrictamente, no necesita 'una' tipo flash. Necesita una PROM, y en el caso de la Alhambra es tipo flash. El cambio más fácil es que sustituyas 'una' por 'la', en referencia concreta a la de la Alhambra. Pero dejo a tu criterio cómo hacer la distinción/aclaración.
  

Corregido.
 

¡Otra prueba que no se me había ocurrido! Me incrementas el SAV por momentos, no sé si aguantaré todo el fin de semana... ¡¡Hay que ponerlo a funcionar con el Arduino y hacer la iceZUM Alhambra independiente ya!! jajajaja

Con Verilog-VHDL puedes hacer un modelo de la Alhambra y simularlo todo aunque sea fin de semana...

Es broma. Ni se te ocurra :P. Pero como concepto es técnicamente posible: http://www.freemodelfoundry.com/whatsnew.php

Debe ser complicado pero sería un buen aporte al proyecto, calmaría mucho SAV, desde luego solo tú podrías hacerlo... así que si te animas. :P
 

 

jajajajajajaja, ¿No puedes esperar a la ICEStick que compraste en Mouser? jajajajajaja
Distingo la iCE40HK... ¿Lo otro es un micro? ¿haciendo de Arduino? jajajaja
¿La piensas construir de verdad? ¡Avísame que yo quiero una! :)

¡El pedido me llegó el lunes-martes! Digamos que la lié un poco. La iCEstick eran 22€, y los gastos de envío costaban otro tanto. Como a partir de 50€ el envío era gratis, cogí dos, un par de memorias flash (64 y 128 Mb, 3€ las dos) y una FPGA HX4K (6€). Bueno, eso pensé, pero lo hice por la noche y a la mañana siguiente me di cuenta de que había pedido una HX1K :S. Hablé con ellos por teléfono, pero no podían cambiar el componente. Amablemente me indicaron que podía coger la HX4K y me la enviaban gratis. Así que eso hice. Total, tengo 2 icestick, una HX1K suelta, otra HX4K suelta y dos memorias sueltas. Demasiado material para tan poco PCB :D. Una de esas memorias era para sustituir la de una de las icestick, y la idea era sustituir la HX1K por la HX4K. Pero si lo hago, me quedo con dos HX1K sueltas, una memoria de 32Mb y la otra de 64 o 128. Así que, por qué no hacer un par de PCBs sencillos, dejar las icesticks intactas y hacer las pruebas directamente con el material restante. Las dos parejas de FPGAS y memorias por 15€, bien merecen jugársela a hacer algo mal.

Pues si lo llevas a cabo yo quiero ver al menos fotos de eso... :)
 

La imagen anterior son dos PCBs diferentes. Y básicamente es una Alhambra v1.1 partida en cuatro:

• Potencia/alimentación
• FTDI + USB
  
• Conversores de tensión 3,3v-5v
• FPGA + Flash
  

La parte FTDI + USB desaparece directamente y la de potencia/alimentación no está en ese dibujo.

¡Eso estaría genial! ¡Una iceZUM Alhambra por módulos! (los palacios Nazaríes, el palacio de Carlos V, la Alcazaba, la Medina, jardines del Generalife....) jajajajajaja

Lo que ves a la derecha es una 'shield' para pinchar directamente un Arduino Nano. Algo como esto: http://ep.yimg.com/ca/I/yhst-27389313707334_2252_106614573 Pero con tiras de pines, en lugar de los conectores con tornillo. Los cuatro integrados son los conversores de tensión 3,3v-5v. Tiene más que la Alhambra y con alguna salida adicional, para obtener un total de 38 conexiones a la FPGA. El conector CONN_2x20 que está en la mitad inferior, en horizontal. Además, en la parte inferior, un conector para recibir 3,3v, 5v y GND, interruptor para encender/apagar, y dos LEDs para indicar si las dos líneas de alimentación están bien. Opcionalmente, se pueden conectar dos Arduino Nano, utilizando uno de los laterales de cada uno.

En la parte central está la placa de la FPGA + Flash. En la parte superior derecha se ve el conector CONN_2x20 al que iría conectada la 'shield'. En la parte central derecha, ocho LEDs de propósito general, el conector de alimentación (1,2v, 3,3v y GND), el interruptor, y dos LEDs para indicar el estado de la alimentación. Debajo, los conectores de 6 y 2 pines que están pegados, son los de programación SPI. A diferencia de la Alhambra, los pines CS de la Flash y SS de la FPGA no están conectados en la placa. El conector de dos pines es un jumper por si se quiere hacer. Hay dos LEDs justo debajo del conector de 6, para indicar si se está programando la FPGA, la Flash o ambas. El conector de cuatro son CBSEL0, CBSEL1, CDONE y CRESET. A su izquierda, la Flash y el circuito de reset. Debajo del todo, un conector de 14 pines conectados directamente a la FPGA. Para, por ejemplo, conectar todos los pines digitales de otro Arduino Nano (a 3,3v). Se puede meter el Nano directamente, sin cable, aunque perdemos D13. Además, uno de esos 14 pines está rutado a una entrada/salida de las líneas especiales de reloj de la FPGA. En la parte central izquierda, el botón de reset, y un conector de ocho pines, que va a las ocho líneas especiales de reloj de la FPGA. Por último, en la parte superior izquierda, está el reloj en sí, y en la capa bottom otro conector CONN_2x20 que provee 38 conexiones directas a la FPGA (sin conversores de tensión intermedios).

Los tres conectores adicionales a la izquierda son para proveer puntos de alimentación al usuario, pero irán en la placa de alimentación. Lo otro es un rotatory encoder con pulsador. Iba a meterlo en la placa central, pero es enorme, así que se quedará aparte. Total, son tres conexiones nada más.

¿Fabricarlo? Lo veo difícil. Es más un proyecto para cacharrear con Kicad y ver hasta dónde puedo llegar. Una prueba de concepto. Lo que he hecho ha sido a partir del diseño de 4 capas recomendado por Lattice. Pero creo que la elección de esos conectores es demasiado ambiciosa. En general todo está excesivamente pegado (fíjate que la placa de la FPGA es de menos de 4,5cm x 4,5cm). No tengo experiencia rutando líneas de alimentación debidamente. Y tengo varias dudas importantes en lo que respecta a la conexión de múltiples maestros SPI, además de lo que sería la placa de alimentación en sí. Pero, quién sabe, a medio plazo, si va cogiendo mejor pinta, por qué no hacer un par de prototipos. La idea de conectar tres Arduino Nano y poder experimentar con computación paralela y coejecución de CPUs + aceleradores hardware desde luego es muy tentadora. El rendimiento sería nefasto, pero todo hardware """libre""".

Pues a compartir... seguro que alguien en el mundo que termina echándote una mano y se termina construyendo.
Quién sabe, igual el cacharreo con KiCAD termina dando sus frutos. ;-)

 

Sí, pero nada más la tabla consume recursos de la FPGA...¿los LUTs de cada CBL?¿o quizás otros bloques de RAM? Ya por curiosidad... ¿Sabes si se puede elegir al sintetizar dónde poner dicha tabla? Lo que es seguro es que con la iCE40 andamos faltos de todo... :(

Los algoritmos de compresión permiten escoger, dentro de unos límites, muchas entradas muy cortas o pocas pero más largas. Dependiendo del resultados, será mejor en LUTs o en BRAM. De todas formas, serviría con un solo bloque BRAM. Además, no tiene que estar reservado exclusivamente para este propósito: se utiliza por el circuito que esté configurado y, cuando se vaya a cambiar de imagen, se aprovecha temporalmente.

Sí, se puede elegir dónde ponerla. Los sintetizadores suelen hacerlo de forma automática:

• Si describimos una memoria que responda en el mismo ciclo, o que tenga más puertos de los que soportan las BRAM, se sintetiza como LUTs.
• Si describimos una memoria cuyo modelo se pueda implementar en una BRAM, pero es de tamaño reducido, se sintetiza como LUTs.
• El resto se sintetizan como BRAM.

Luego, cada sintetizador provee directivas para especificar que una memoria pequeña queremos meterla en BRAM, o que una grande queremos que se haga mediante LUTs.

¡¡Ufff!! Complejo para mi. ¿Sabes si yosys tiene estas opciones de elección de forma manual? Sería quizás interesante a la hora de optimizar otros proyectos libres.
 

 

¡Sería genial disponer de esa herramienta de forma libre!
Si esa es tu idea me apunto... aunque no se me ocurre en qué podría ayudar...
ya me está costando grabar una simple flash... jajajajajaja :)

Cada cual a su ritmo y en el ámbito que le es conocido. Créeme que si yo me pongo ahora a programar la Flash, me va a costar lo mismo o más que a ti. Aunque sé cómo tienen que funcionar las cosas, no he escrito nunca la secuencia concreta de instrucciones/comandos. Te veo mucho más hábil/animado para experimentar aunque no siempre tengas muy claro el resultado. A mí me cuesta mucho darle a programar, antes de estar seguro de saber qué va a pasar.

Animado sí, con tiempo escaso... también. Así que una cosa por otra, pero lo haremos, al final lo conseguiremos. :)
 

En el tema de los IP-cores, poco hay que hacer aquí. Esperar a que Jesús pase por el otro hilo para ver si hay alguna posibilidad de llegar a un entendimiento sobre el tamaño y formato del hash. Si no, simplemente habrá dos formatos paralelos. A partir de ahí, se podría hacer un "empaquetador": le das el código en verilog y las documentación en formato Markdown, y te genera un tar.gz con las fuentes, el o los bitstream y un PDF que incluye la documentación y el código comentado. Adicionalmente, puede generar una página web de cada componente en el sistema. No te asustes, que todo eso ya está hecho. Sólo hay que integrar Doxygen, Pandoc, Hugo u otro similar.

Desde luego sería genial poder elegir los IP-cores así y poder usarlos desde la flash... ya me empiezo a animar de nuevo. :)
 

Puede que ponernos de acuerdo también en un fichero de repositorios. Un JSON que pueda cargar cualquier aplicación y donde encuentre las URL de repositorios con los tar.gz. He dicho que uno o varios bitstream, porque el paquete puede incluir bitstreams para varias placas. Así, se podría añadir un travis.yml, que dado un nuevo diseño y la documentación, sintetice y genere bitstreams para un conjunto de placas. Ese travis puede en realidad ejecutar un contenedor de docker, de forma que el repositorio no tendría que alojar los bitstream, porque el usuario podría lanzar el mismo contenedor y que se le generen de forma transparente.

En esto me pierdo un poco, el formato json lo tengo oscuro y lo de travis.yml nunca lo había oído... pero más o menos te entiendo... docker funcionando como una especie de virtualización donde se generarían los bitstream dependiendo de la placa que se use y desde unos fuentes comunes, con lo que el repositorio únicamente debe tener las fuentes y no todos los bitstream para cada una de las placas... ¿Es eso?

Adicionalmente, hay varios repositorios libres de diseños HDL (OpenCores, LibreCores, FreeRangeFactory...). Se podrían implementar getters para ellos. De forma que la URL se añada con algún atributo para saber que hay que desempaquetar las fuentes de forma diferente, y puede que añadir las constraints de asociación de pines físicos.

Ok, esto si lo he entendido... aún tengo salvación. :)
 

Ten en cuenta que estoy hablando de Verilog en todo momento. No sé cómo encajaría en icestudio, con el formato actual de ICE.

En cualquier caso, todo esto es software, comunidad y cultura de la remezcla. A nivel técnico lo único que nos interesa en este hilo es incluir un identificador "único" en la flash junto a cada puntero.

Pero todo eso para no guardar en la flash el bitstream... osea que necesitamos una conexión al repositorio del bitstream, una comunicación exterior.... no sé, yo lo veo más como que te descargar el bitstream del repositorio y puedes usarlo sin necesidad de conexión externa, creo que es más útil disponer del bitstream completo en la flash.
 

[Juanma Rico]

Se me fue el dedo al botón de publicar... lo siento... sigo comentando en violeta.

El sábado, 18 de marzo de 2017, 12:44:44 (UTC+1), 1138-4EB escribió:

Ten en cuenta que estoy hablando de Verilog en todo momento. No sé cómo encajaría en icestudio, con el formato actual de ICE.

En cualquier caso, todo esto es software, comunidad y cultura de la remezcla. A nivel técnico lo único que nos interesa en este hilo es incluir un identificador "único" en la flash junto a cada puntero.

Pero todo eso para no guardar en la flash el bitstream... osea que necesitamos una conexión al repositorio del bitstream, una comunicación exterior.... no sé, yo lo veo más como que te descargar el bitstream del repositorio y puedes usarlo sin necesidad de conexión externa, creo que es más útil disponer del bitstream completo en la flash.
 

 

Me gusta la idea... si lo asocio con mi experiencia en el software libre (GNU/Linux)... nunca me pareció ágil lo de Gentoo... para probar un programa tenías que compilarlo todo desde cero... y luego lo ejecutabas y resulta que el programa era una decepción o no era o hacía lo que tú pensabas... el disco duro lleno de bibliotecas que no ibas a utilizar jamás... :(
Debian en el sentido contrario me cautivó., te bajas por separado ejecutable y fuente. :)

Me gusta la analogía. El objetivo es Arch. Hay partes precompiladas (el toolchain y post-sintesis) y partes en fuentes (pre-sintesis). Tú puedes descargarte los bitstream, si existen. Si no, puedes bajar el netlist post-sintesis y hacer solo el place and route. O, si quieres, puedes hacerlo todo desde las fuentes, lo que incluye cambiar la funcionalidad.

¡Eso sí! pero entonces no sé para qué necesito el UID del bitstream en la flash ocupando sitio... ya tengo el bitstream... ¿para evitar errores?

 

En cuanto a tener el disco duro lleno de bibliotecas... Juanma, te presento a Docker. Vais a tener una relación muy larga, así que empezad con tranquilidad. Os muestro el primer paso:

sudo apt-get install docker-ce
sudo docker run --rm -it fedora bash

Sí, efectivamente, has ejecutado una ""máquina virtual"" de Fedora y estás dentro. Haz 'dnf update', utiliza herramientas que sólo estén en Fedora. Cuando te aburras, escribe 'exit', y volverás a tu Debian. Todo lo que hayas hecho ha desaparecido. Tu sistema "no sabe" que ha estado ejecutando Fedora, no hay ninguna librería instalada.

Sí, con Docker me tuve que pelear para dar servicios con Discourse para pruebas del club (otro frente abierto que tengo) nunca lo he usado en este sentido que me comentas... el concepto de Docker es un concepto aún oscuro para mi (¿es una virtualización?¿no lo es?¿consume recursos?¿qué tipo de recursos?¿Menos?¿Más que una virtualización completa del sistema?), imagino que con el uso se me irá clarificando el concepto y lo usaré más frecuentemente. :)

En otras palabras, docker te permite descargar en una "imagen" todas las librerías que le faltan a tu sistema para ejecutar cualquier cosa que quieras. Las descomprime en un proceso aislado que sólo ve ese sistema de archivos y no el de tu sistema real, y cuando te marchas desaparecen todas y sólo queda la "imagen" original. Esa imagen es un fichero comprimido de entre 2MB y 10GB, depende de qué es lo que haya en la imagen. Si la imagen se ha generado a través de un script, puedes ver exactamente qué órdenes se han utiliado. Ejemplo de la imagen que se utiliza para compilar GHDL en Ubuntu: https://hub.docker.com/r/ghdl/ghdl-tools/~/dockerfile/

Interesante... veo que tú lo usas como "punto de restauración" o similar... ¿es así? :)
 

Yo lo he utilizado, por ejemplo, para distribuir instalaciones de OpenFOAM. Tarda unas 6 horas en compilar, y necesitas 3GB de librerías. La imagen de docker ocupa 1.37GB (todavía estoy analizando cómo quitarle más) y está lista para usar. Lo que es más importante, cualquier usuario que la utilice estará exactamente en el mismo entorno, por lo que los "problemas" son directamente reproducibles.

Otro uso muy interesante... para comprobar bugs de issues... :)
Lo de la mecánica de fluidos me interesa (otro de mis frentes abiertos...) si eso enlaza, enlaza... :)
 

Sí, estoy trabajado en cómo meter icestorm en docker. Es como Apio, pero sin compilación cruzada. El sistema se compila una sola vez.

Por cierto, utilizo docker a diario en Windows 10, para probar cosas en Fedora, Debian y Alpine Linux al mismo tiempo. Y las mismas imágenes de docker funcionan en una Raspberry Pi :D :D :D.

Tengo la sensación de que vas a encontrar entretenimiento hasta poder echar mano a la Alhambra....

jajajajajajaja, ya me ves... contestándote una semana después de que publicaras... pero aburrido no estoy nunca, eso te lo puedo asegurar, por opciones con las que entretenerse y aprender que no quede. :)

 

Saludos

Miles de saludos

 

[Unai Martinez]

Pensé el esquema de subdirectorios antes de crearlos, me di cuenta pero se me olvidó cambiar los enlaces (mi falta de experiencia en GitHub. Corregido.

 
Es bastante intuitivo y en general todo funciona como esperas. Pero las URL son una excepción. Hay que prestar atención cuando navegas. Especialmente, si quieres descargarte un fichero desde terminal, tienes que usar la versión "raw". Por ejemplo:

wget https://raw.githubusercontent.com/juanmard/FPGA-control-PID/master/README.md

Lista de enlaces creado en el README.md. He creado un .gitignore que filtre mis PDF locales, he borrado la caché (git rm --cached  doc/*.pdf), pero no consigo que se borren y dejen de estar visibles los ficheros en GitHub. Para investigar.

Tienes que "purgar" toda la historia (la de git, la de MundoReal todavía no se puede). Hay varias opciones:

http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository

En cualquier caso, debes tener en cuenta que al cambiar toda la historia en tu copia local, cuando te compares con el repo de Github tendrás dos versiones totalmente diferentes. No te dejará hacer "push" sin más. Y, si haces, "pull", te hará un "merge", por lo que estará todo por duplicado (habrá dos versiones de cada commit con un hash diferente). Para evitarlo, tienes que machacar el repo de GitHub:

git pusho rigin +master

Ese "+" le indica que te la trae al pairo lo que tenga. Que borre todo y copie tu versión de la historia (que es la limpia).

Un efecto colateral de estos "cambios de historia" es que a cualquier otro usuario que haya hecho un checkout, cuando haga fetch y status, le dirá que hay un motón de cambios por descargar. Si hace, pull, estaremos en las mismas de antes: con dos historias duplicadas en el mismo merge. Para evitarlo, tendrá que hacer un reset:

git reset --hard origin master

Por eso no es conveniente andar tocando la historia de Git. Pero en este caso, como acaba de nacer el repo, no hay problema.

Por otro lado, aprovechando que vas a andar con esto, igua quieres reconsiderar el nombre de otro repo. Has puesto "PID", pero luego en el README indicas la intención de investigar otros algoritmos de control. Creo que sería más prudente utilizar sólo FPGA y Control en el nombre.
 

Con Verilog-VHDL puedes hacer un modelo de la Alhambra y simularlo todo aunque sea fin de semana...

Es broma. Ni se te ocurra :P. Pero como concepto es técnicamente posible: http://www.freemodelfoundry.com/whatsnew.php

Debe ser complicado pero sería un buen aporte al proyecto, calmaría mucho SAV, desde luego solo tú podrías hacerlo... así que si te animas. :P

Nah, no tengo interés particular en implementar algo así. Es relativamente complejo y no tiene casi utilidad para mí. Una descripción completa de los LEDs, el ADC, los conversores de tensión, etc. sólo son de interés como entorno de verificación para quien desarrolle específicamente para la Alhambra. Mi objetivo es conocer la arquitectura de las iCE40, no trabajar sólo con una placa.
 

¡¡Ufff!! Complejo para mi. ¿Sabes si yosys tiene estas opciones de elección de forma manual? Sería quizás interesante a la hora de optimizar otros proyectos libres.

Lo comentamos con más detalle en: https://groups.google.com/forum/#!topic/fpga-wars-explorando-el-lado-libre/3b-OSWwPqTs
 
Básicamente, echa un ojo a las páginas 6-15 del documento 'Memory Usage Guide for iCE40 Devices': http://www.latticesemi.com/Products/FPGAandCPLD/iCE40.aspx

En esto me pierdo un poco, el formato json lo tengo oscuro y lo de travis.yml nunca lo había oído... pero más o menos te entiendo... docker funcionando como una especie de virtualización donde se generarían los bitstream dependiendo de la placa que se use y desde unos fuentes comunes, con lo que el repositorio únicamente debe tener las fuentes y no todos los bitstream para cada una de las placas... ¿Es eso?

Exactamente. Travis CI simplemente es un servicio gratuito para proyectos abiertos en GitHub, que te provee una máquina con Ubuntu para que ejecutes lo que quieras después de cada commit. Se entiende que lo que quieres es compilar y probar el repo.

Para utilizar travis no es necesario docker. Es una "máquina virtual", y puedes poner las órdenes en bash/dash como en Ubuntu/Debian. Sin embargo, yo lo único que hago en travis es lanzar un contenedor de docker y lo ejecuto todo ahí. Así, no hay ninguna diferencia entre lo que se prueba ahí y cuando yo ejecuto el contenedor de docker en local. Si no lo hiciera así, tendría que tener una instalación local exactamente igual que la de travis, para cuando haya problemas. Bueno, de hecho, te puedes bajar la VM de travis para VirtualBox: https://docs.travis-ci.com/user/ci-environment/
 

En cualquier caso, todo esto es software, comunidad y cultura de la remezcla. A nivel técnico lo único que nos interesa en este hilo es incluir un identificador "único" en la flash junto a cada puntero.

Pero todo eso para no guardar en la flash el bitstream... osea que necesitamos una conexión al repositorio del bitstream, una comunicación exterior.... no sé, yo lo veo más como que te descargar el bitstream del repositorio y puedes usarlo sin necesidad de conexión externa, creo que es más útil disponer del bitstream completo en la flash.

No, no, me he explicado mal. Guardamos en la flash el bistream (comprimido o no), el puntero y el hash. Las tres cosas. El hash no hace falta ni mirarlo por ahora para ninguna de las pruebas que hagamos. Pero en un futuro nos servirá como metadato. Simplemente es más fácil incluir ahora una previsión de espacio, que hacerlo todo corriendo y dentro de quince días tener que reescribirlo entero para añadir esa funcionalidad.

¡Eso sí! pero entonces no sé para qué necesito el UID del bitstream en la flash ocupando sitio... ya tengo el bitstream... ¿para evitar errores?

Es más rápido leer 8, 16, 32 o 64 bytes de UID que 1K o 32K que ocupa la imagen. Ahora estamos utilizamos flash y puede parecer irrelevante, pero con otras memorias poder identificar de forma única toda una imagen sólo con el UID es un ahorro de tiempo importante. Caso práctico:

Desde Arduino quiero escribir una nueva imagen en la flash (sin eliminar ninguna de las que ya están). Sin UID, la única forma es leer todos los bitstream y comparar cada uno con el que queremos escribir. Con UID, sólo leemos el primer sector y lo miramos como una tabla.
 

Sí, con Docker me tuve que pelear para dar servicios con Discourse para pruebas del club (otro frente abierto que tengo) nunca lo he usado en este sentido que me comentas... el concepto de Docker es un concepto aún oscuro para mi (¿es una virtualización?¿no lo es?¿consume recursos?¿qué tipo de recursos?¿Menos?¿Más que una virtualización completa del sistema?), imagino que con el uso se me irá clarificando el concepto y lo usaré más frecuentemente. :)

Es menos que una virtualización completa. En una máquina virtual el SO no ve el hardware real, sino lo que la máquina le dice que tiene. En este caso, el contenedor sí que ve tu hardware y lo usa directamente. Es como ponerle orejeras a un burro o caballo. Está andando por el mismo prado, pero evitas que vea todo aquello que no le concierne. Siguiendo con la analogía, en una máquina virtual añadirías una zanahora y una foto de fondo, para que el animal no sepa ni donde está en realidad.

Consume ligeramente más recursos que si se ejecutan las mismas intenciones directamente en tu terminal. Pero muchísimos menos que una máquina virtual. Consume principalmente RAM y procesador, pero también GPU, red, ... Depende de qué ejecutes en el contenedor. En general, puedes hacerte la idea de que va a consumir lo mismo que si se ejecutara directamente, sólo con un ligero incremento de RAM que depende del tamaño de la imagen (alpine 8MB, fedora y ubuntu debajo de 100MB).
 

Interesante... veo que tú lo usas como "punto de restauración" o similar... ¿es así? :)

No es que lo use así, es que así funciona XD. Tú tienes imágenes, que son esos "puntos de restauración". Para poder hacer cualquier cosa, tienes que generar un contenedor a partir de la imagen. Cuando terminas con el contenedor, puedes borrarlo, dejarlo en standby, o guardarlo como una (nueva) imagen.

La explicación es muy intuitiva si tienes en cuenta que cada "imagen" es como un repositorio de git. Las imagénes están compuestas por capas, y guando guardas un contenedor lo que haces es un commit en la imagen. Por lo tanto, los contenedores son tu directorio de trabajo, y las imagenes la carpeta .git. Además, también existe docker-hub, por lo que puedes hacer push de tus imágenes. Exactamente igual que git, otra vez.

Hay una diferencia muy importante, eso sí: las imágenes no pueden tener mas de 64 o 128 capas (no me acuerdo exactamente). Tampoco es mucho problema, porque se puede hacer squash de varias capas para unirlas en una solo.
 

 Yo lo he utilizado, por ejemplo, para distribuir instalaciones de OpenFOAM. Tarda unas 6 horas en compilar, y necesitas 3GB de librerías. La imagen de docker ocupa 1.37GB (todavía estoy analizando cómo quitarle más) y está lista para usar. Lo que es más importante, cualquier usuario que la utilice estará exactamente en el mismo entorno, por lo que los "problemas" son directamente reproducibles.

Otro uso muy interesante... para comprobar bugs de issues... :)
Lo de la mecánica de fluidos me interesa (otro de mis frentes abiertos...) si eso enlaza, enlaza... :)

Mi usuario en docker-hub es https://hub.docker.com/r/11384eb
Y esta es la imagen concreta con OpenFOAM: https://hub.docker.com/r/11384eb/gea-waves/~/dockerfile/
Suponiendo que estés en la carpeta de un caso, puedes descargarla y usarla con:

$ docker pull 11384eb/gea-weaves
$ docker run --rm -itv $(pwd):/work 11384eb/gea-weaves bash
root@containerid# blockMesh
root@containerid# interFoam

Donde sustituyes blockMesh e interFoam por las instrucciones concretas para el mallado y solver que quieras usar.
La imagen creo que no tiene ni los ejemplos. Por lo que deberás descargártelos por separado.
No obstante, si nunca has trabajado con OpenFOAM, la curva de aprendizaje tiene su gracia. Puedes empezar por: https://cfd.direct/openfoam/user-guide/
 

jajajajajajaja, ya me ves... contestándote una semana después de que publicaras... pero aburrido no estoy nunca, eso te lo puedo asegurar, por opciones con las que entretenerse y aprender que no quede. :)

Estoy acostumbrado a trabajar de forma bastante "asíncrona". ¡Una semana no es nada!

Saludos

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aN_vYtDCEyo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-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/ccc864c7-fee7-4406-bb61-7e6a11e27c40%40googlegroups.com.

[Unai Martinez]

Si usas docker desde MinGW en Windows 10, la orden de ejecución tiene un par de diferencias:

winpty docker run --rm -itv /$(pwd):/work 11384eb/gea-weaves bash



winpty hace falta para tener una shell interactiva. Y la barra antes del path, por las diferencias de formato entre mingw, powershell y linux.


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.

[1138-4EB]

Y otro fallo: la imagen correcta es 11384eb/of:41fed25slim

[1138-4EB]

Juanma, adjunto una captura de pantalla con tres contenedores docker y un monitor de sistema.

• En la parte inferior izquierda se está compilando icestorm sobre alpine linux.
• En la parte inferior derecha, los mismo en un contenedor Ubuntu.
• En la parte central derecha, lo mismo en fedora.
• En la parte superior, glances muestra el proceso "clang-3.9", que es el que más esá recursos consumiendo. Aparece como si estuviera en local, pero en realidad se corresponde con uno de los contenedores.
• Todo esta ejecutándose en una máquina con Arch, pero sería igual en cualquier otra.

Como ves, el consumo de memoria es ridículo para estar ejecutando 3 "máquinas virtuales".

[Juanma Rico]

Buenas, algo rápido en esta mañana...

El domingo, 26 de marzo de 2017, 3:20:18 (UTC+2), 1138-4EB escribió:

Pensé el esquema de subdirectorios antes de crearlos, me di cuenta pero se me olvidó cambiar los enlaces (mi falta de experiencia en GitHub. Corregido.

 
Es bastante intuitivo y en general todo funciona como esperas. Pero las URL son una excepción. Hay que prestar atención cuando navegas. Especialmente, si quieres descargarte un fichero desde terminal, tienes que usar la versión "raw". Por ejemplo:

wget https://raw.githubusercontent.com/juanmard/FPGA-control-PID/master/README.md

Lista de enlaces creado en el README.md. He creado un .gitignore que filtre mis PDF locales, he borrado la caché (git rm --cached  doc/*.pdf), pero no consigo que se borren y dejen de estar visibles los ficheros en GitHub. Para investigar.

Tienes que "purgar" toda la historia (la de git, la de MundoReal todavía no se puede). Hay varias opciones:

http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository

En cualquier caso, debes tener en cuenta que al cambiar toda la historia en tu copia local, cuando te compares con el repo de Github tendrás dos versiones totalmente diferentes. No te dejará hacer "push" sin más. Y, si haces, "pull", te hará un "merge", por lo que estará todo por duplicado (habrá dos versiones de cada commit con un hash diferente). Para evitarlo, tienes que machacar el repo de GitHub:

git push origin +master

Ese "+" le indica que te la trae al pairo lo que tenga. Que borre todo y copie tu versión de la historia (que es la limpia).

Un efecto colateral de estos "cambios de historia" es que a cualquier otro usuario que haya hecho un checkout, cuando haga fetch y status, le dirá que hay un motón de cambios por descargar. Si hace, pull, estaremos en las mismas de antes: con dos historias duplicadas en el mismo merge. Para evitarlo, tendrá que hacer un reset:

git reset --hard origin master

Por eso no es conveniente andar tocando la historia de Git. Pero en este caso, como acaba de nacer el repo, no hay problema.

Listo, gracias a los enlaces que me pasaste y sobretodo a la opción "+" (opción "me la trae al pairo" a partir de ahora. ;-)) en la rama master he limpiado el proyecto en github. Siento si alguien hizo un clone del proyecto y ahora tiene que hacer un hard-reset, inconvenientes de dejar una herramienta tan potente en manos de un novato como yo... :)
 

Por otro lado, aprovechando que vas a andar con esto, igua quieres reconsiderar el nombre de otro repo. Has puesto "PID", pero luego en el README indicas la intención de investigar otros algoritmos de control. Creo que sería más prudente utilizar sólo FPGA y Control en el nombre.

Sí, Unai, me dí cuenta cuando estaba redactando el README.md, pero no encontré como cambiar el nombre del proyecto. Imagino que habrá que hacer otro nuevo con otro nombre y clonar. Investigo por Google y lo corrijo el próximo día.

 

Con Verilog-VHDL puedes hacer un modelo de la Alhambra y simularlo todo aunque sea fin de semana...

Es broma. Ni se te ocurra :P. Pero como concepto es técnicamente posible: http://www.freemodelfoundry.com/whatsnew.php

Debe ser complicado pero sería un buen aporte al proyecto, calmaría mucho SAV, desde luego solo tú podrías hacerlo... así que si te animas. :P

Nah, no tengo interés particular en implementar algo así. Es relativamente complejo y no tiene casi utilidad para mí. Una descripción completa de los LEDs, el ADC, los conversores de tensión, etc. sólo son de interés como entorno de verificación para quien desarrolle específicamente para la Alhambra. Mi objetivo es conocer la arquitectura de las iCE40, no trabajar sólo con una placa.

Pues anímate con el modelo de simulación de la iCE40, sería rizar el rizo... jejejejeje :)
No, es broma, es para picarte.... únicamente por puro interés personal y egoismo, estoy seguro que ver un modelo de simulación de un bus compartido hecho por ti en Verilog me ayudaría en mi proyecto del C4004... me quedé estancado simulando el bus por no sé qué tema de como trata yosys la definición del estado de impedancia en los inout o qué sé yo... Imagínate... no sé exactamente cúal es el problema... ¡como para encontrar la solución! jejejejejejeje
 

 

¡¡Ufff!! Complejo para mi. ¿Sabes si yosys tiene estas opciones de elección de forma manual? Sería quizás interesante a la hora de optimizar otros proyectos libres.

Lo comentamos con más detalle en: https://groups.google.com/forum/#!topic/fpga-wars-explorando-el-lado-libre/3b-OSWwPqTs
 
Básicamente, echa un ojo a las páginas 6-15 del documento 'Memory Usage Guide for iCE40 Devices': http://www.latticesemi.com/Products/FPGAandCPLD/iCE40.aspx

Ya tengo que dejarlo por hoy... el resto lo miro y lo comento y te pregunto otro día que tenga más tiempo, contigo son muchas cosas y conceptos que aprender y me gusta hacerlo tranquilamente... :)

Saludos y gracias.

 

[1138-4EB]

Sí, Unai, me dí cuenta cuando estaba redactando el README.md, pero no encontré como cambiar el nombre del proyecto. Imagino que habrá que hacer otro nuevo con otro nombre y clonar. Investigo por Google y lo corrijo el próximo día.

¡Me la trae al pairo! Tu opción favorita a partir de ahora. Cuidado con abusar de ella. Pero en este caso:

• Git no tiene noción de "nombre del proyecto", el nombre se lo da la carpeta en la que se encuentre ".git".
• Por lo tanto, para cambiar el nombre a tu proyecto en local, renombra la carpeta.
  
• Después, ve a GitHub y crea un proyecto nuevo. Da lo mismo que lo hagas en blanco, o añadas un README inicial. Lo único que te interesa es que te va a generar una URL del tipo github.com/juanmard/nuevorepo.
• En tu carpeta local añade un nuevo repo, o cambia "origin" para que apunte a la nueva URL (sólo una de las dos):
• git remote add nuevoremote https://github.com/juanmard/nuevorepo.git
• git remote set-url origin https://github.com/juanmard/nuevorepo.git
• Machaca la "breve" historia del repo recien creado (sólo una de las dos, dependiendo de lo que hagas en el paso anterior):
• git push nuevoremote +master
• git push origin +master
  

A partir de ahi, puedes comprobar a través del navegador que los dos repos en GitHub tienen la misma historia, y borrar el viejo. Si has renombrado origin, no tienes que hacer nada más en local. Si has añadido "nuevoremote", lo más cómodo es que cambies la URL de origin ahora, y elimines el otro:

git remote remove nuevoremoe

 

Pues anímate con el modelo de simulación de la iCE40, sería rizar el rizo... jejejejeje :)
No, es broma, es para picarte.... únicamente por puro interés personal y egoismo, estoy seguro que ver un modelo de simulación de un bus compartido hecho por ti en Verilog me ayudaría en mi proyecto del C4004... me quedé estancado simulando el bus por no sé qué tema de como trata yosys la definición del estado de impedancia en los inout o qué sé yo... Imagínate... no sé exactamente cúal es el problema... ¡como para encontrar la solución! jejejejejejeje

Un bus compartido per sé no tiene ninguna complicación. Pero ¿qué bus? He ahí la gracia. ¿De qué protocolo se trata? ¿Es bidireccional? ¿Cuántos maestros hay? ¿Esclavos? 

[Juanma Rico]

Pues un pasito más... (un día con más tiempo miro con tranquilidad el tema del Docker)

El domingo, 26 de marzo de 2017, 18:08:09 (UTC+2), 1138-4EB escribió:

¡Me la trae al pairo! Tu opción favorita a partir de ahora. Cuidado con abusar de ella. Pero en este caso:

• Git no tiene noción de "nombre del proyecto", el nombre se lo da la carpeta en la que se encuentre ".git".
• Por lo tanto, para cambiar el nombre a tu proyecto en local, renombra la carpeta.
  
• Después, ve a GitHub y crea un proyecto nuevo. Da lo mismo que lo hagas en blanco, o añadas un README inicial. Lo único que te interesa es que te va a generar una URL del tipo github.com/juanmard/nuevorepo.
• En tu carpeta local añade un nuevo repo, o cambia "origin" para que apunte a la nueva URL (sólo una de las dos):
• git remote add nuevoremote https://github.com/juanmard/nuevorepo.git
• git remote set-url origin https://github.com/juanmard/nuevorepo.git
• Machaca la "breve" historia del repo recien creado (sólo una de las dos, dependiendo de lo que hagas en el paso anterior):
• git push nuevoremote +master
• git push origin +master
  

A partir de ahi, puedes comprobar a través del navegador que los dos repos en GitHub tienen la misma historia, y borrar el viejo. Si has renombrado origin, no tienes que hacer nada más en local. Si has añadido "nuevoremote", lo más cómodo es que cambies la URL de origin ahora, y elimines el otro:

git remote remove nuevoremoe

 

Listo, hemos aumentado la coherencia del proyecto... para futuras referencias ha quedado aquí.
Por cierto, el issue de Jesús se ha perdido (el commit no, pero el issue sí), habría que investigar como no perderlos. Para nota, otro día.
 

Un bus compartido per sé no tiene ninguna complicación. Pero ¿qué bus? He ahí la gracia. ¿De qué protocolo se trata? ¿Es bidireccional? ¿Cuántos maestros hay? ¿Esclavos? 

Pues la verdad Unai que no tengo ni idea del protocolo. Es el bus del primer microcontrolador comercial de Intel (C4004). Yo retomé un proyecto que encontré en OpenCores, intenté comunicarlo con su ROM y el registro de desplazamiento... pero el bus se me atragantó. El hilo es este. Estuve una temporada dándole vueltas, pero no conseguí encontrar el fallo. Tampoco sé mucho de Verilog, lo que he aprendido por aquí, así que se me hace cuesta arriba... además saber que no se puede probar en la placa por el tema de las puertas triestado también me desanimó un tanto... y con tantos frentes abiertos, al final lo tengo un poco abandonado.

Me animé a la aventura del conjunto msc-4 al implementar el Simplez-F y hacer un programilla para él en la iceZUM Alhambra y ver que el bootloader funcionaba con ese sencillo microcontrolador/microprocesador. Puede aportar algo al proyecto del Simplez-F de Obujuan y pensé que estaría chulo hacer lo mismo con uno real, el más sencillo que existiera en el mercado... y apareció el conjunto de chips msc-4, el primero comercial de la historia... pero atascado estoy.

Cuando cerremos el frente del Cold/Warm Boot (si se cierra algún día) intentaré retomarlo. Si alguien del grupo se anima y encuentra por casualidad el fallo, que avise, que seguro que me vuelvo a animar. :)

Saludos.

[1138-4EB]

Pues un pasito más... (un día con más tiempo miro con tranquilidad el tema del Docker)

Supongo que habrás visto en este hilo, que estoy retrasando ligeramente las pruebas de programación, para disponer de un entorno de desarrollo portable basado en docker. Está a puntito...
 

Listo, hemos aumentado la coherencia del proyecto... para futuras referencias ha quedado aquí.
Por cierto, el issue de Jesús se ha perdido (el commit no, pero el issue sí), habría que investigar como no perderlos. Para nota, otro día.

Cierto, se me olvido indicar que lo que estabas haciendo era sobre el repo, no sobre "los añadidos web" de GitHub. Ya lo siento, pero es que ni me fijé en que tenía una issue :S.
 

 Pues la verdad Unai que no tengo ni idea del protocolo. Es el bus del primer microcontrolador comercial de Intel (C4004). Yo retomé un proyecto que encontré en OpenCores, intenté comunicarlo con su ROM y el registro de desplazamiento... pero el bus se me atragantó. El hilo es este. Estuve una temporada dándole vueltas, pero no conseguí encontrar el fallo. Tampoco sé mucho de Verilog, lo que he aprendido por aquí, así que se me hace cuesta arriba... además saber que no se puede probar en la placa por el tema de las puertas triestado también me desanimó un tanto... y con tantos frentes abiertos, al final lo tengo un poco abandonado.

Me animé a la aventura del conjunto msc-4 al implementar el Simplez-F y hacer un programilla para él en la iceZUM Alhambra y ver que el bootloader funcionaba con ese sencillo microcontrolador/microprocesador. Puede aportar algo al proyecto del Simplez-F de Obujuan y pensé que estaría chulo hacer lo mismo con uno real, el más sencillo que existiera en el mercado... y apareció el conjunto de chips msc-4, el primero comercial de la historia... pero atascado estoy.

Cuando cerremos el frente del Cold/Warm Boot (si se cierra algún día) intentaré retomarlo. Si alguien del grupo se anima y encuentra por casualidad el fallo, que avise, que seguro que me vuelvo a animar. :)

La lógica parece bastante directa, pero como hay múltiples módulos interconectados hay que tener claro el mapa de memora. Como comentas, esperemos a cerrar algún otro frene primero ;)
 
En lo que a mí respecta: icecube2 y el programador ya están funcionando en Windows10. He podido encontrar el menú para hacer los packs y activar el coldboot con las herramientas oficiales. Sin embargo, en GNU/Linux tengo problemas con la licencia flexlm. Concretamente, el hostid que lee de forma automática no coincide con la MAC de mis tarjetas. Así que está instalado, pero no quiere ejecutarse :S. Por otro lado, no me he metido con los drivers hasta no tener el software listo.

En paralelo, como he comentado arriba, estoy terminando la imagen docker.

Cuando tenga los dos entornos de trabajo preparados, continuaré con las aportaciones específicas de aplicación: el cold/warm boot y go-icemulti.

Saludos.

Saludos
 

[Juanma Rico]

Buenas, comentarios rápìdos...

El martes, 28 de marzo de 2017, 15:28:06 (UTC+2), 1138-4EB escribió:

Pues un pasito más... (un día con más tiempo miro con tranquilidad el tema del Docker)

Supongo que habrás visto en este hilo, que estoy retrasando ligeramente las pruebas de programación, para disponer de un entorno de desarrollo portable basado en docker. Está a puntito...

Sí, me parece genial, le sigo la pista... Al leerte, este fin de semana me animé y empecé una instalación con Docker en mi equipo con Windows...
No tuve suerte, al parecer a Windows 7 Home no le gusta mucho la virtualización.



Intenté las docker-toolbox como dice el mensaje pero va demasiado lento y no consigo que tire ni los ejemplos.
 

 

Listo, hemos aumentado la coherencia del proyecto... para futuras referencias ha quedado aquí.
Por cierto, el issue de Jesús se ha perdido (el commit no, pero el issue sí), habría que investigar como no perderlos. Para nota, otro día.

Cierto, se me olvido indicar que lo que estabas haciendo era sobre el repo, no sobre "los añadidos web" de GitHub. Ya lo siento, pero es que ni me fijé en que tenía una issue :S.

Bueno, imagino que Jesús me perdonará por el issue perdido. :)
No entiendo como a los desarrolladores de github no se les ha ocurrido permitir clonar sus propios datos asociados al git... pero bueno, algún día, si hay más novatos manazas como yo y lo ven entonces necesario, lo desarrollarán. :)
 

 

 Pues la verdad Unai que no tengo ni idea del protocolo. Es el bus del primer microcontrolador comercial de Intel (C4004). Yo retomé un proyecto que encontré en OpenCores, intenté comunicarlo con su ROM y el registro de desplazamiento... pero el bus se me atragantó. El hilo es este. Estuve una temporada dándole vueltas, pero no conseguí encontrar el fallo. Tampoco sé mucho de Verilog, lo que he aprendido por aquí, así que se me hace cuesta arriba... además saber que no se puede probar en la placa por el tema de las puertas triestado también me desanimó un tanto... y con tantos frentes abiertos, al final lo tengo un poco abandonado.

Me animé a la aventura del conjunto msc-4 al implementar el Simplez-F y hacer un programilla para él en la iceZUM Alhambra y ver que el bootloader funcionaba con ese sencillo microcontrolador/microprocesador. Puede aportar algo al proyecto del Simplez-F de Obujuan y pensé que estaría chulo hacer lo mismo con uno real, el más sencillo que existiera en el mercado... y apareció el conjunto de chips msc-4, el primero comercial de la historia... pero atascado estoy.

Cuando cerremos el frente del Cold/Warm Boot (si se cierra algún día) intentaré retomarlo. Si alguien del grupo se anima y encuentra por casualidad el fallo, que avise, que seguro que me vuelvo a animar. :)

La lógica parece bastante directa, pero como hay múltiples módulos interconectados hay que tener claro el mapa de memora. Como comentas, esperemos a cerrar algún otro frene primero ;)
 
En lo que a mí respecta: icecube2 y el programador ya están funcionando en Windows10. He podido encontrar el menú para hacer los packs y activar el coldboot con las herramientas oficiales. Sin embargo, en GNU/Linux tengo problemas con la licencia flexlm. Concretamente, el hostid que lee de forma automática no coincide con la MAC de mis tarjetas. Así que está instalado, pero no quiere ejecutarse :S. Por otro lado, no me he metido con los drivers hasta no tener el software listo.

Es lo malo de estas barreras creadas para impedir el acceso a terceros mediante una licencia... que al final fallan y no te dejan acceder a ti mismo.
No tengo ni idea para qué flexlm y el hostid lee la MAC, pero según tengo entendido, cambiar la MAC con la que se identifica un dispositivo es relativamente fácil. ¿Y si cambias la MAC de las tarjetas a la MAC que te conviene? Lo lanzo como especulación...sin conocer realmente el problema en profundidad, imaginando además que ya lo habrás probado.
 

En paralelo, como he comentado arriba, estoy terminando la imagen docker.

Cuando tenga los dos entornos de trabajo preparados, continuaré con las aportaciones específicas de aplicación: el cold/warm boot y go-icemulti.

Perfecto, esperaré con impaciencia... pero ya, visto lo visto, no podré usarlo en mi equipo con Windows... ¿Para qué calentarme la cabeza? Volveré a mi sencillo Debian para usar e investigar sobre Docker.
 

Saludos.

Saludos
 

(Saludos)^3
 

[Unai Martinez]

Sí, me parece genial, le sigo la pista... Al leerte, este fin de semana me animé y empecé una instalación con Docker en mi equipo con Windows...
No tuve suerte, al parecer a Windows 7 Home no le gusta mucho la virtualización.

Intenté las docker-toolbox como dice el mensaje pero va demasiado lento y no consigo que tire ni los ejemplos.

Efectivamente, no funciona de forma "nativa" ni en Windows 7, ni tampoco en mi portátil con Windows 10 Home Edition. En esos casos hay que utilizar docker-toolbox, que en realidad lo que hace es instalar VirtualBox. Sinceramente nunca he querido probarlo así, porque ya sé de antemano que va a ser una patata.

De hecho, por lo anterior, durante dos años no le he dado uso a docker. Sin embargo, al última vez que instalé Windws 10 Pro en un equipo con HyperV vi que funcionaba de forma nativa, y realmente rápido (como cualquier otra aplicación).

Por lo tanto, para escritorios Windows será una alternativa extendida dentro de 2-5 años, cuando Windows 7 pase a deprecated.

No obstante, mi objetivo principal son plataformas GNU/Linux:

- SBCs tipo Rapberry Pi.

- Un único "servidor" corriendo CentOs que pueda estar en un aula y contra el que lancen las tareas de compilación los usuarios.

- Una LiveCD que cargue sólo el kernel, drivers ethernet/wifi y docker. Opcionalmente las X y drivers USB para placas.

Véase: https://github.com/jrruethe/debian-micro o https://github.com/identinetics/PVZDliveCD

 

Bueno, imagino que Jesús me perdonará por el issue perdido. :)
No entiendo como a los desarrolladores de github no se les ha ocurrido permitir clonar sus propios datos asociados al git... pero bueno, algún día, si hay más novatos manazas como yo y lo ven entonces necesario, lo desarrollarán. :)

 

Existir existe, lo que pasa es que no es parte de git. Eso se puede hacer mediante la API de GitHub: https://help.github.com/articles/backing-up-a-repository/

La solución no es tan directa como con el repo en sí. Hay multiples alternativas más o menos completas para facilitarlo. No obstante, nunca las he utilizado. La API de GitHub esta en mi TODO.

Es lo malo de estas barreras creadas para impedir el acceso a terceros mediante una licencia... que al final fallan y no te dejan acceder a ti mismo.

De hecho, la leyenda dice que del driver defectuoso de una impresora surgió GNU.

 

No tengo ni idea para qué flexlm y el hostid lee la MAC, pero según tengo entendido, cambiar la MAC con la que se identifica un dispositivo es relativamente fácil.

Digamos que toda la seguridad se basa en que te generan una licencia asociada a un UID, que puede ser una MAC o el del disco duro. Así es como "aseguran" que no vayas a utilizar la licencia en más de un equipo. Agárrate bien, porque esto no es algo exclusivo de Lattice, es un estándar en la industria: Altera, Xilinx, Mentor, Autodesk...

Es tan ridículo, que si tienes un fichero con 50 licencias flotantes, basta una sola MAC correcta para poder utilizar el programa en 50 máquinas a la vez. Para más INRI, la MAC está en plano en el fichero de licencia.

Muy guay todo, para herramientas que "cuestan" miles de euros.

 

¿Y si cambias la MAC de las tarjetas a la MAC que te conviene? Lo lanzo como especulación...sin conocer realmente el problema en profundidad, imaginando además que ya lo habrás probado.

 

Sí, la idea es sencilla, especialmente en GNU/Linux, pero en la práctica tiene su gracia. Tú puedes cambiar la MAC de tu tarjeta de red para todo el sistema, pero esto tiene el inconveniente de afectar a todas las aplicaciones. En casa no importa, pero en una empresa o universidad hacerlo puede dejarte sin red o que te llamen la atención los de redes. Más aún, no se puede hacer el mismo "truco" en más de un equipo.

Por lo tanto, lo ideal es cambiar la MAC sólo para un proceso. No he descubierto cómo hacerlo. No obstante, ¡docker al rescate! Uno de los parámetros que acepta docker es la MAC interna... ¡bingo! Arranco un contenedor de docker con la MAC que quiero, meto el servidor de licencias ahí y abro el puerto para que sólo sea visible en el host (no en todo internet).

DISCLAIMER: lo anterior es muy probable que incumpla las condiciones de la licencia del software que estés utilizando. Hazlo sólo si estás en condiciones de justificar por qué y cómo lo has hecho, en caso de problemas legales. Como indico a continuación, no es la solución ideal para este problema en particular, pero es útil si un servidor casca y hay que terminar un proyecto para mañana.

¿Por qué no quiero hacer lo anterior con Icecube2? Porque las herramientas oficiales y gratuitas deberían funcionar sin necesidad de hackearlas. No debería necesitar falsear la MAC porque me he registrado en la página y he generado dos licencias gratuitas: una para ethernet y otra para el wifi-USB. De hecho, he generado cuatro en total (otras dos para otros dos equipos Windows).

A mayores, los ficheros de licencia que facilita Lattice son standalone, por lo que no hay ningún servidor de licencias que ejecutar por separado. Las opciones que tengo son:

• Modificar el fichero de licencia para convertirlo al formato para un servidor, y ejecutar lmutil dentro de un contenedor con la MAC a medida. Straightforward, pero no me gusta más que como última opción.
• Extraer icecube2 junto con el fichero de licencia en un contenedor con la MAC a medida. Tengo que averiguar cómo compartir el servidor X del host con el contenedor para poder usarlo, ya que es un programa con GUI.
  
• Esto es posible que acabe haciéndolo para poder tener en la misma imagen icecube2 + programmer, posibemente junto con todo el toolchain libre.
• Podría distribuir el Dockerfile para que cada cual se construya la imagen para uso personal, pero no la imagen construida por razones evidentes.,
  
• Averiguar qué demonios está interpretando. Si ejecuto "lmutil hostid" la respuesta es ""MAC1 MAC2"". Por lo que tengo la sensación de que está cogiendo todo como una sola MAC, en lugar de darse cuenta de que hay un espacio y son dos. O debería ser "'MAC1' 'MAC2'".
• Podría generar la licencia para todo el churro, pero la página web de Lattice sólo permite doce caracteres en grupos de dos :S.
  

Todo lo anterior es desde Arch Linux. En Windows no he tenido ningún problema. La siguiente prueba la voy a hacer en Fedora (que es más parecido a RHEL, la distribución soportada oficialmente por Lattice).

Aunque este grupo esté centrado en herramientas libres, espero que las referencias anteriores sean de utilidad para quien quiera hacer vigilancia tecnológica.

Perfecto, esperaré con impaciencia... pero ya, visto lo visto, no podré usarlo en mi equipo con Windows... ¿Para qué calentarme la cabeza? Volveré a mi sencillo Debian para usar e investigar sobre Docker.

 

Esa es la actitud ;)

Saludos.

Saludos
 

(Saludos)^3
 

Salu2^{2^2}

[1138-4EB]

Hola Juanma,
 

Volveré a mi sencillo Debian para usar e investigar sobre Docker.

Un pasito más cerca:

docker run --rm -it \
> -v /tmp/.X11-unix/:/tmp/.X11-unix \
> -e DISPLAY=unix$DISPLAY \
> 11384eb/elide:alpine-run sh

Esa orden descarga '11384eb/elide:alpine-run', que es una imagen basada en Alpine Linux: https://hub.docker.com/r/11384eb/elide/tags/ 146M es la información que hay que descargar y una vez descomprimida ocupa 525M.

Contiene icestorm + arachne-pnr + yosys + iverilog + graphviz + gtkwave + python3 + tcl. Y todas sus dependencias, incluyendo gtk-2.0.

De hecho, las líneas 2-3 de la orden sólo son necesarias si quieres usar gtkwave. Para todas las demás aplicaciones basta con:

docker run --rm -it 11384eb/elide:alpine-run sh

He añadido más detalles en https://github.com/1138-4EB/elide

El siguiente paso es hacer funcionar la programación con iceprog desde dentro del contenedor. Después, probar icemulti.

Saludos

[Juanma Rico]

Gracias Unai,

Llevo unos días sin poder pasar por el laboratorio, estoy con otros proyectos y tan "liado" estoy que hasta el SAV lo tengo aletargado.
(Casi ni me atrevía a leer los mensajes del grupo por si me sube y alcanza saturación...  jajajajaja)

Pero veo que si no los leo con asiduidad se me acumula el trabajo... Esta tarde quería leer unos cuantos en media hora y ya llevo como tres horas leyendo y aún me quedan como nueve temas con novedades sin leer... (ya no te digo si quisiera hacer pruebas, comprobaciones y demás)  :(

Lo voy a tener que dejar por hoy... porque me estoy leyendo tus avances con Docker y noto como me sube "la bilirrubina"...  jejejeje

En cuanto tenga una tarde me pongo tranquilo con Docker en Debian (en Windows 7 Home es insufrible y abandoné) y te cuento y pregunto según me vaya la cosa. En la medida de lo posible (si el SAV me lo permite) seguiré leyendo tus avances. :-)

Saludos.

[Juanma Rico]

Hoy dispongo de algo de tiempo, voy a retomar las pruebas que tengo retrasadas en este hilo... ¡Unai me tienes a tope de deberes! jajajajaj  :-)

El sábado, 18 de marzo de 2017, 12:44:44 (UTC+1), 1138-4EB escribió:

Buenos días Juanma!

 

 Me gusta la idea... si lo asocio con mi experiencia en el software libre (GNU/Linux)... nunca me pareció ágil lo de Gentoo... para probar un programa tenías que compilarlo todo desde cero... y luego lo ejecutabas y resulta que el programa era una decepción o no era o hacía lo que tú pensabas... el disco duro lleno de bibliotecas que no ibas a utilizar jamás... :(
Debian en el sentido contrario me cautivó., te bajas por separado ejecutable y fuente. :)

Me gusta la analogía. El objetivo es Arch. Hay partes precompiladas (el toolchain y post-sintesis) y partes en fuentes (pre-sintesis). Tú puedes descargarte los bitstream, si existen. Si no, puedes bajar el netlist post-sintesis y hacer solo el place and route. O, si quieres, puedes hacerlo todo desde las fuentes, lo que incluye cambiar la funcionalidad.

En cuanto a tener el disco duro lleno de bibliotecas... Juanma, te presento a Docker. Vais a tener una relación muy larga, así que empezad con tranquilidad. Os muestro el primer paso:

sudo apt-get install docker-ce

Como te dije lo conozco, poco, pero ya me peleé con él... lo tuve que estudiar para levantar el servicio web basado en Discourse.
Veamos si sigue instalado...
 

sudo docker run --rm -it fedora bash

Sí, parece que funciona... solo tiene que descargarse la última imagen de Fedora.  :)

juanma@angora:~$ sudo docker run --rm -it fedora bash
[sudo] password for juanma:
Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
bc5187a39b05: Pull complete
Digest: sha256:b44cdaee0feafc85cab454e2023807f66725c727655b6bef260aa6d21dd2b068
Status: Downloaded newer image for fedora:latest
[root@dcc04513c67a /]#

 

Sí, efectivamente, has ejecutado una ""máquina virtual"" de Fedora y estás dentro. Haz 'dnf update', utiliza herramientas que sólo estén en Fedora. Cuando te aburras, escribe 'exit', y volverás a tu Debian. Todo lo que hayas hecho ha desaparecido. Tu sistema "no sabe" que ha estado ejecutando Fedora, no hay ninguna librería instalada.

[root@dcc04513c67a /]# dnf update
Fedora 25 - x86_64                              1.4 MB/s |  50 MB     00:37
Fedora 25 - x86_64 - Updates                    1.4 MB/s |  21 MB     00:14
Last metadata expiration check: 0:00:21 ago on Mon Apr  3 14:47:23 2017.
Dependencies resolved.
================================================================================
 Package                 Arch        Version                 Repository    Size
================================================================================
Upgrading:
 audit-libs              x86_64      2.7.4-1.fc25            updates      106 k
 gdbm                    x86_64      1.13-1.fc25             updates      154 k
 hawkey                  x86_64      0.6.4-2.fc25            updates       64 k
 nss                     x86_64      3.29.3-1.0.fc25         updates      860 k
 nss-softokn             x86_64      3.29.3-1.0.fc25         updates      385 k
 nss-softokn-freebl      x86_64      3.29.3-1.0.fc25         updates      225 k
 nss-sysinit             x86_64      3.29.3-1.0.fc25         updates       60 k
 nss-tools               x86_64      3.29.3-1.0.fc25         updates      502 k
 nss-util                x86_64      3.29.3-1.0.fc25         updates       83 k
 python3-hawkey          x86_64      0.6.4-2.fc25            updates       46 k
 tzdata                  noarch      2017b-1.fc25            updates      419 k
 vim-minimal             x86_64      2:8.0.514-1.fc25        updates      519 k

Transaction Summary
================================================================================
Upgrade  12 Packages

Total download size: 3.3 M
Is this ok [y/N]:

Y ahí están las actualizaciones... :-)
Ahora, de vuelta a casa... :-)

[root@dcc04513c67a /]# exit
exit
juanma@angora:~$

En otras palabras, docker te permite descargar en una "imagen" todas las librerías que le faltan a tu sistema para ejecutar cualquier cosa que quieras. Las descomprime en un proceso aislado que sólo ve ese sistema de archivos y no el de tu sistema real, y cuando te marchas desaparecen todas y sólo queda la "imagen" original. Esa imagen es un fichero comprimido de entre 2MB y 10GB, depende de qué es lo que haya en la imagen. Si la imagen se ha generado a través de un script, puedes ver exactamente qué órdenes se han utiliado. Ejemplo de la imagen que se utiliza para compilar GHDL en Ubuntu: https://hub.docker.com/r/ghdl/ghdl-tools/~/dockerfile/

Yo lo he utilizado, por ejemplo, para distribuir instalaciones de OpenFOAM. Tarda unas 6 horas en compilar, y necesitas 3GB de librerías. La imagen de docker ocupa 1.37GB (todavía estoy analizando cómo quitarle más) y está lista para usar. Lo que es más importante, cualquier usuario que la utilice estará exactamente en el mismo entorno, por lo que los "problemas" son directamente reproducibles.

Sí, estoy trabajado en cómo meter icestorm en docker. Es como Apio, pero sin compilación cruzada. El sistema se compila una sola vez.

Lo sigo, lo sigo... :)
Ahora me paso por el hilo donde lo estás desarrollando y hago las pruebas... 

Por cierto, utilizo docker a diario en Windows 10, para probar cosas en Fedora, Debian y Alpine Linux al mismo tiempo. Y las mismas imágenes de docker funcionan en una Raspberry Pi :D :D :D.

Tengo la sensación de que vas a encontrar entretenimiento hasta poder echar mano a la Alhambra....

Desgraciadamente, creo que te expliqué, en el portátil tengo Windows 7 Home y no me entra en modo Hyper-V, así que aquí estoy en el laboratorio con mi Debian donde tengo la Alhambra para hacer pruebas. :-)

Saludos

 

 
Saludos, sigo con los deberes atrasados... :)

[Juanma Rico]

El sábado, 18 de marzo de 2017, 12:49:50 (UTC+1), 1138-4EB escribió:

Releyéndolo, parece contradictorio lo de fabricar o no el PCB. Uno voy a hacer para aprovechar el material. Pero no sé si será ese tan complejo e incompleto, o simplemente aprovecharé algún diseño como el de la Kéfir.

Yo dispongo de diez placas de la eCow-Logic, que mandé fabricar en un alarde de locura a PCBway... tengo el listado del BOM que me envió Gwenael, pero ahí lo tengo y no encuentro lugar para pedirlo, tengo que sentarme, identificar los componentes mínimos necesarios (imagino que la ICE40HK, la PROM y los componentes que componen la alimentación) y pedir a Mouser o algún otro distribuidor los componentes... pero mi falta de experiencia en estas cosas y mi falta de tiempo me tienen bloqueado y ahí las tengo muertas de risa, así que si tú tienes chips solitarios sin placa a la que agarrarse y te animas a soldarlos en la eCow-Logic yo te ofrezco las que necesites como regalo. Solo tienes que decirme por privado donde tengo que mandarla y te la mando. Eso sí, el próximo libro que escribas me lo tienes que firmar... jajajajaja :)

[Juanma Rico]

Comentarios a otros párrafos que me quedaron pendientes de leer y comentar...

El domingo, 26 de marzo de 2017, 3:20:18 (UTC+2), 1138-4EB escribió:

Sí, con Docker me tuve que pelear para dar servicios con Discourse para pruebas del club (otro frente abierto que tengo) nunca lo he usado en este sentido que me comentas... el concepto de Docker es un concepto aún oscuro para mi (¿es una virtualización?¿no lo es?¿consume recursos?¿qué tipo de recursos?¿Menos?¿Más que una virtualización completa del sistema?), imagino que con el uso se me irá clarificando el concepto y lo usaré más frecuentemente. :)

Es menos que una virtualización completa. En una máquina virtual el SO no ve el hardware real, sino lo que la máquina le dice que tiene. En este caso, el contenedor sí que ve tu hardware y lo usa directamente. Es como ponerle orejeras a un burro o caballo. Está andando por el mismo prado, pero evitas que vea todo aquello que no le concierne. Siguiendo con la analogía, en una máquina virtual añadirías una zanahora y una foto de fondo, para que el animal no sepa ni donde está en realidad.

¿Y a ti te gustaba mi analogía de Gentoo? ¡Esta del burro es mucho mejor! jejejejeje :)
 

Consume ligeramente más recursos que si se ejecutan las mismas intenciones directamente en tu terminal. Pero muchísimos menos que una máquina virtual. Consume principalmente RAM y procesador, pero también GPU, red, ... Depende de qué ejecutes en el contenedor. En general, puedes hacerte la idea de que va a consumir lo mismo que si se ejecutara directamente, sólo con un ligero incremento de RAM que depende del tamaño de la imagen (alpine 8MB, fedora y ubuntu debajo de 100MB).
 

Interesante... veo que tú lo usas como "punto de restauración" o similar... ¿es así? :)

No es que lo use así, es que así funciona XD. Tú tienes imágenes, que son esos "puntos de restauración". Para poder hacer cualquier cosa, tienes que generar un contenedor a partir de la imagen. Cuando terminas con el contenedor, puedes borrarlo, dejarlo en standby, o guardarlo como una (nueva) imagen.

Yo los usaba, pero no sabía muy bien cómo y terminé llenando el disco duro de imágenes de prueba... entonces tuve que aprender a borrar las imágnes. :)
 

La explicación es muy intuitiva si tienes en cuenta que cada "imagen" es como un repositorio de git. Las imagénes están compuestas por capas, y guando guardas un contenedor lo que haces es un commit en la imagen. Por lo tanto, los contenedores son tu directorio de trabajo, y las imagenes la carpeta .git. Además, también existe docker-hub, por lo que puedes hacer push de tus imágenes. Exactamente igual que git, otra vez.

Hay una diferencia muy importante, eso sí: las imágenes no pueden tener mas de 64 o 128 capas (no me acuerdo exactamente). Tampoco es mucho problema, porque se puede hacer squash de varias capas para unirlas en una solo.
 

 Yo lo he utilizado, por ejemplo, para distribuir instalaciones de OpenFOAM. Tarda unas 6 horas en compilar, y necesitas 3GB de librerías. La imagen de docker ocupa 1.37GB (todavía estoy analizando cómo quitarle más) y está lista para usar. Lo que es más importante, cualquier usuario que la utilice estará exactamente en el mismo entorno, por lo que los "problemas" son directamente reproducibles.

Otro uso muy interesante... para comprobar bugs de issues... :)
Lo de la mecánica de fluidos me interesa (otro de mis frentes abiertos...) si eso enlaza, enlaza... :)

Mi usuario en docker-hub es https://hub.docker.com/r/11384eb
Y esta es la imagen concreta con OpenFOAM: https://hub.docker.com/r/11384eb/gea-waves/~/dockerfile/
Suponiendo que estés en la carpeta de un caso, puedes descargarla y usarla con:

$ docker pull 11384eb/gea-weaves
$ docker run --rm -itv $(pwd):/work 11384eb/gea-weaves bash
root@containerid# blockMesh
root@containerid# interFoam

Donde sustituyes blockMesh e interFoam por las instrucciones concretas para el mallado y solver que quieras usar.
La imagen creo que no tiene ni los ejemplos. Por lo que deberás descargártelos por separado.
No obstante, si nunca has trabajado con OpenFOAM, la curva de aprendizaje tiene su gracia. Puedes empezar por: https://cfd.direct/openfoam/user-guide/

Lo apunto en la lista TODO. La imagen ya he probado a descargarla y funciona, pero me he mirado el índice del User Guide que enlazas y me he puesto a temblar... :-)
 

 

jajajajajajaja, ya me ves... contestándote una semana después de que publicaras... pero aburrido no estoy nunca, eso te lo puedo asegurar, por opciones con las que entretenerse y aprender que no quede. :)

Estoy acostumbrado a trabajar de forma bastante "asíncrona". ¡Una semana no es nada!

;-)
 

Saludos

[Juanma Rico]

Nada, Unai... llevo un rato dándome cabezazos y no consigo hacerlo funcionar...
He intentado esto:

root@angora:/home/juanma# docker run -it 11384eb/elide:alpine-run sh

Unable to find image '11384eb/elide:alpine-run' locally
alpine-run: Pulling from 11384eb/elide
627beaf3eaaf: Pull complete
2ecf63fac97c: Pull complete
2fb5719e877e: Pull complete
bd3c3d6f4d50: Pull complete
b9ccce827f35: Pull complete
53db87e7ce2b: Extracting [==================================================>] 94.46 MB/94.46 MB
62a9c81ce64a: Download complete
docker: failed to register layer: ApplyLayer exit status 1 stdout:  stderr: write /usr/local/share/arachne-pnr/chipdb-8k.bin: read-only file system.
See 'docker run --help'.

Y como ves me dice que no tengo permisos de escritura...¿en la carpeta de arachne-pnr?  (lo intenté con sudo, pero ya desesperado me pasé a root... y nada). Lo extraño es que el error que da es al descomprimir... con lo que no me deja en local la imagen (a pesar de eliminar el --rm de docker).

root@angora:/home/juanma# docker images
REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app    latest              ddaa97973a08        3 months ago        1.71 GB
discourse/discourse    1.3.9               d2fbe0833acf        3 months ago        1.54 GB
samsaffron/docker-gc   latest              54ca424ca8d6        17 months ago       57.6 MB

Seguiré intentándolo... a ver si con un cabezazo más sale la cosa.

Saludos.

El jueves, 30 de marzo de 2017, 10:04:50 (UTC+2), 1138-4EB escribió: