[iceZUM Alhambra v1.1][SPI] Comunicando con nuestra flash (N25Q032A).

[Juanma Rico]

Buenas a todos,

Abro un nuevo tema para investigar las posibilidades del protocolo SPI en la iceZUM Alhambra (en mi caso la v1.1).
Como ya sabéis se basa en la FPGA de Lattice iCE40HX1k-TQ144 y su configuración proviene de una flash (N25Q032A) que vuelca los datos del bitstream en la CRAM de la FPGA mediante un protocolo/bus SPI.

Tal y como está construida nuestra placa, el bitstream que generamos con las herramientas del proyecto icestorm (el fichero final "bin") sigue el siguiente recorrido:

 Del PC (o Mac) usando iceprog y mediante conexión USB-RS232 -> Chip FTDI -> por SPI graba en la flash N25Q032A -> tras un reset (un cold/warm boot) -> acaba por SPI en la CRAM de la iCE40HX1k

En el proceso "cold/warm boot" la FPGA (según señales externas o internas) decide de qué zona de la flash va a obtener el bitstream para volcar en la CRAM y así configurarse (que no programarse).

La cuestión es que ya somos capaces de modificar el número de bitstreams que se pueden "cargar" en la FPGA y cual elegir actuando desde el PC y modificando el programa iceprog. (Ver el hilo de cold/warm boot).

Tras esto, el siguiente paso es actuar directamente sobre el SPI y saltarnos el FTDI y la dependencia del PC (o Mac) y hacerlo desde la FPGA grabando directamente sobre la flash la zona del applet que hace cambiar el bitstream elegido (también podríamos hacer un paso intermedio que es conectar un Arduino al SPI... pero creo que ya que estamos... el hacerlo sobre la propia FPGA le da mucha más posibilidades al sistema).

De todo esto ya habló Unai en el hilo referido y se llegaron a conclusiones interesantes y genéricas, pero quedaba por ver las posibilidades de nuestra FPGA y concretar en ella. Lo ideal es que ya existiera el módulo SPI en un módulo "hard IP core"... pero la cuestión es que por más que busco no encuentro que en nuestra iCE40HX se disponga de dicho módulo SPI para otro uso que no sea la programación del chip (ver Technical Note TN1248 tabla 1). Otros chips de la familia sí lo admiten (pero el nuestro no... nuestro "gozo en un pozo").

Así que habrá que sintetizar un módulo SPI para comunicar con la flash... pero surge otra duda... lo suyo sería usar en dicho módulo los pines ya conectados en nuestra tarjeta... ¿Se puede hacer?¿No afectaría al "boot" normal de la configuración de la FPGA?¿Cómo se hace? :)))

He estado buscando por este mismo grupo por si alguien hubiera desarrollado o estuviera trabajando en ese módulo y he encontrado alguna mención interesante de este tema, pero nada concreto. Lo más concreto que he encontrado está en este hilo donde Unai se pregunta por como conectar un Arduino directamente al bus SPI de la iceZUM Alhambra. Pero le surge un problema con los posibles cortocircuitos en el bus y no sé si ha conseguido finalmente solucionarlo (yo no puedo ayudarle en este caso porque no tengo ni idea del tema).

Sea como fuere intentaré en este hilo avanzar en este asunto, en principio de forma independiente al hilo del Cold/Warm Boot pero con idea y enfocado a modificar la flash (y sus vectores de carga) para finalmente unir los dos hilos en uno solo.

Si alguien estuviera interesado, supiera guiarme, darme pistas o incluso sintetizar el módulo SPI... sería perfecto. :)))

Saludos.

[Juanma Rico]

Buenas de nuevo,

Estoy buscando un core SPI y la idea es conectarlo a una UART para hacer unas primeras pruebas desde el PC.
La cuestión es que encontré el core SPI en Verilog y la UART en proyectos separados, ambos con la posibilidad de unirse por un bus Wishbone, en seguida pensé en un esquema como este:

Pero buscando un poco más he encontrado un core SPI-UART ya unido, directo... como no tengo experiencia me ha asaltado la duda...

¿Es muy difícil manejar un bus Wishbone?¿Da muchos problemas?¿Es mejor hacer las pruebas con SPI-UART o es quizás mejor hacerlo por separado para no hacer doble trabajo después y con la idea de poder conectar algo más al bus Wishbone y eliminar la UART del core si no hace falta?

Si alguien tiene experiencia en el bus Wishbone, su manejo en Verilog y me puede aconsejar le estaría tremendamente agradecido... :))

Saludos.

[Salvador Eduardo Tropea]

El 25/05/17 a las 13:17, Juanma Rico escribió:
[snip]

> De todo esto ya habló Unai en el hilo referido y se llegaron a
> conclusiones interesantes y genéricas, pero quedaba por ver las
> posibilidades de nuestra FPGA y concretar en ella. Lo ideal es que ya
> existiera el módulo SPI en un módulo "hard IP core"... pero la
> cuestión es que por más que busco no encuentro que en nuestra iCE40HX
> se disponga de dicho módulo SPI para otro uso que no sea la
> programación del chip (ver Technical Note TN1248 tabla 1). Otros chips
> de la familia

> <https://en.wikipedia.org/wiki/ICE_%28FPGA%29#iCE40_.2840_nm.29> sí lo

> admiten (pero el nuestro no... nuestro "gozo en un pozo").

Correcto, es una línea diferente a la HX.

> Así que habrá que sintetizar un módulo SPI para comunicar con la
> flash... pero surge otra duda... lo suyo sería usar en dicho módulo
> los pines ya conectados en nuestra tarjeta... ¿Se puede hacer?

Si.

> ¿No afectaría al "boot" normal de la configuración de la FPGA?

No.

> ¿Cómo se hace? :)))

De la forma más natural. Cuando la FPGA no está configurada (antes del
boot) esos pines se conectan al core SPI interno que configura la SRAM
interna. Cuando la FPGA se configura y "bootea" esos pines son lo que
uno le haya dicho en el HDL. Mi primer prueba del SPI de Lattuino fue
leer el ID de la memoria de configuración.

[snip]

> Si alguien estuviera interesado, supiera guiarme, darme pistas o
> incluso sintetizar el módulo SPI... sería perfecto. :)))

Estoy un poco tapado de cosas, pero te comento que el SPI del Lattuino
ya está portado a Verilog.

Saludos, Salvador

--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

[Salvador Eduardo Tropea]

El 25/05/17 a las 14:40, Juanma Rico escribió:

> ¿Es muy difícil manejar un bus Wishbone?

No, es muy simple.

> ¿Da muchos problemas?

Para nada.
Si no entiendo mal lo que necesitás es escribir un maestro WISHBONE.
La interconexión es muy simple.
Yo uso un script que la genera, aunque de momento solo soporta VHDL.
Me podría poner a ver si puedo hacer que genere Verilog, lo voy a
necesitar hacer de todas maneras.

> ¿Es mejor hacer las pruebas con SPI-UART o es quizás mejor hacerlo por
> separado para no hacer doble trabajo después y con la idea de poder
> conectar algo más al bus Wishbone y eliminar la UART del core si no
> hace falta?

No se muy bien que es lo que querés hacer, pero si la idea es luego
volar la UART yo diría que es mejor trabajar con los cores separados.

> Si alguien tiene experiencia en el bus Wishbone, su manejo en Verilog
> y me puede aconsejar le estaría tremendamente agradecido... :))

Yo siempre lo usé en VHDL, pero la idea base es la misma.
En la especificación explica como es un ciclo de lectura o escritura.

Adjunto una presentación simple que usé varias veces para explicar lo
básico.

[Juanma Rico]

¡Hola Salvador!

El viernes, 26 de mayo de 2017, 14:31:24 (UTC+2), Salvador Eduardo Tropea escribió:

El 25/05/17 a las 14:40, Juanma Rico escribió:
> ¿Es muy difícil manejar un bus Wishbone?

No, es muy simple.

¡Perfecto!

> ¿Da muchos problemas?

Para nada.
Si no entiendo mal lo que necesitás es escribir un maestro WISHBONE.
La interconexión es muy simple.
Yo uso un script que la genera, aunque de momento solo soporta VHDL.
Me podría poner a ver si puedo hacer que genere Verilog, lo voy a
necesitar hacer de todas maneras.

¡Genial!
 

> ¿Es mejor hacer las pruebas con SPI-UART o es quizás mejor hacerlo por
> separado para no hacer doble trabajo después y con la idea de poder
> conectar algo más al bus Wishbone y eliminar la UART del core si no
> hace falta?

No se muy bien que es lo que querés hacer, pero si la idea es luego
volar la UART yo diría que es mejor trabajar con los cores separados.

Sí, bueno... la idea era hacer unas pruebas básicas una vez sintetizado el módulo SPI y para ello pensé que lo más útil era sintetizar una UART y unirlo a él internamente para poder enviar valores de prueba (y recibirlos) del módulo SPI sin más que usar un terminal desde el PC.

La cuestión es que mientras esperaba respuesta del Wishbone me puse a mirar como estaba construido el SPI-UART que encontré y me dí cuenta que realmente se encuentran separados, lo único que los une es un registro de datos de 8 bits y un par de flags (que imagino que indican que los datos en el registro están disponibles). Además tiene unos ejemplos de loopback de prueba entre estos módulos que me vienen muy bien para aprender.

De hecho he conseguido que me sintetice sin errores y probarlos en la iceZUM Alhambra, pero no me salió lo que esperaba a la primera y este fin de semana no dispongo de la tarjeta para un par de pruebas que se me han ocurrido... :(((

Tengo que seguir haciendo pruebas para ver si lo descarto o no, porque además veo que no tiene la línea MISO y no sé si es necesaria para nuestra flash.
Otra cosa que veo es que usa un modo SPI llamado "Mode 0" (Mode 0 Positive Pulse. Latch, then Shift) que tampoco sé si es el correcto para nuestra flash... en fin, muchas cosas por investigar... :)))
 

> Si alguien tiene experiencia en el bus Wishbone, su manejo en Verilog
> y me puede aconsejar le estaría tremendamente agradecido... :))

Yo siempre lo usé en VHDL, pero la idea base es la misma.
En la especificación explica como es un ciclo de lectura o escritura.

Adjunto una presentación simple que usé varias veces para explicar lo
básico.

¡Guauuu! ¡Gracias! Ya lo tengo descargado... :))
El Wishbone habrá que entenderlo tarde o temprano y me viene genial estos apuntes... :))
¡¡Gracias!!

Saludos, Salvador
--

¡Saludos!

[Juanma Rico]

¡Buenas!

El viernes, 26 de mayo de 2017, 14:22:02 (UTC+2), Salvador Eduardo Tropea escribió:

El 25/05/17 a las 13:17, Juanma Rico escribió:
[snip]
> De todo esto ya habló Unai en el hilo referido y se llegaron a
> conclusiones interesantes y genéricas, pero quedaba por ver las
> posibilidades de nuestra FPGA y concretar en ella. Lo ideal es que ya
> existiera el módulo SPI en un módulo "hard IP core"... pero la
> cuestión es que por más que busco no encuentro que en nuestra iCE40HX
> se disponga de dicho módulo SPI para otro uso que no sea la
> programación del chip (ver Technical Note TN1248 tabla 1). Otros chips
> de la familia
> <https://en.wikipedia.org/wiki/ICE_%28FPGA%29#iCE40_.2840_nm.29> sí lo
> admiten (pero el nuestro no... nuestro "gozo en un pozo").


Correcto, es una línea diferente a la HX.

Sí, al final tuve que admitirlo... no quedaba nada claro en el datasheet, miré en su página oficial y tampoco... hasta que no encontré esos cuadros en la wikipedia y la aclaración final no me quedé convencido... posiblemente me aferraba demasiado en el deseo de que lo tuviera... :)))

> Así que habrá que sintetizar un módulo SPI para comunicar con la
> flash... pero surge otra duda... lo suyo sería usar en dicho módulo
> los pines ya conectados en nuestra tarjeta... ¿Se puede hacer?

Si.

> ¿No afectaría al "boot" normal de la configuración de la FPGA?

No.

> ¿Cómo se hace? :)))

De la forma más natural. Cuando la FPGA no está configurada (antes del
boot) esos pines se conectan al core SPI interno que configura la SRAM
interna. Cuando la FPGA se configura y "bootea" esos pines son lo que
uno le haya dicho en el HDL. Mi primer prueba del SPI de Lattuino fue
leer el ID de la memoria de configuración.

¡¡Ahhh!! Ok, es como una configuración por defecto (por omisión) donde las patillas externas están "conectadas" al módulo SPI interno (al que no podemos acceder como "hard ip core" en la familia HX) cuando la FPGA está sin alimentación y que una vez conectada y configurada (volcada la flash por esos pines a la CRAM mediante este módulo SPI) estos pines están disponibles para conectarlos a lo que le digamos... ¿Es eso correcto? :))
¿Eso se hace desde una SRAM?¿Se podría modificar esta SRAM "por defecto" de alguna manera?¿Está relacionado con lo que en el datasheet habla de "Internal Nonvolatile Configuration Memory (NVCM)"? Porque dice que se puede modificar, aunque una única vez... un peligro para tocar... :(((

[snip]
> Si alguien estuviera interesado, supiera guiarme, darme pistas o
> incluso sintetizar el módulo SPI... sería perfecto. :)))

Estoy un poco tapado de cosas, pero te comento que el SPI del Lattuino
ya está portado a Verilog.

¡¡Ya te digo que no me da tiempo ni en mirar tus avances en Verilog con el Lattuino!! jajajajajaj
¡¡Genial!! Lo voy a mirar... ¿Qué tipo de implementación es?¿Es compatible con la flash nuestra?¿usas por casualidad la flash externa como EEPROM del Lattuino?
¿Se podría usar? (Ya sabemos que como "memoria de programa" la cosa es lenta de usar... igual incluso la EEPROM del micro de Arduino es mucho más rápida... no sé).

¡¡Warning!! Idea descabellada: Es que se me está ocurriendo ahora mismo, mientras escribo esto, usar la flash externa como una especie de tarjeta SD... como la que se usa en las impresoras 3D con el SmartLCD... ¿No sería más eficiente disponer de un controlador "a medida" en la FPGA para este tipo de impresoras 3D que no necesitara de un microprocesador? La ventaja más inmediata que se me ocurre es que los motores paso a paso estarían controlados en tiempo real y en paralelo, así como sensores y demás... ¡¡hummmm!! puede ser interesante intentarlo... no debe ser muy difícil hacer un controlador paso a paso "hardware" (¿un registro de desplazamiento?)
¡Cerraríamos el círculo y uniríamos los dos mundos! jejejejeje :)))
 

Saludos, Salvador

Saludos y muchas gracias.
 

[Juanma Rico]

Bueno, hoy finalmente he echado un "ratillo" de laboratorio...
Al final estoy usando el módulo SPI para Lattuino de Salvador y el módulo UART que ya controlo del otro proyecto (una mezcla rara).

La cuestión es que estoy un poco bloqueado, en parte porque no sé muy bien como funcionan los módulos...
Os cuento... Mi idea es conectar el módulo SPI a los pines de la flash, para ello definimos en el fichero pcf lo siguiente:

set_io SCLK    70
set_io MOSI    67
set_io SSbar   71

Y en el fichero "top" se instancia (¿Se dice así?) el módulo SPI0.

    reg start=0;
    wire flash_ok;
    reg[7:0] data_spi, data_flash;
 
    SPI_Master  SPI0 (
    // System
    .clk_i(clk),
    .rst_i(btn1),   // El botón 1 resetea el SPI y la UART.
    .ena_i(1'b1),   // 2*SCK
    // Interface
    .start_i(start),
    .tx_i (data_spi),   // Byte que se transmite por el SPI a la flash.
    .rx_o (data_flash), // Byte que se obtiene de la flash.
    .busy_o(),
    .irq_o(flash_ok),
    .ack_i(),           // IRQ Ack (Esta señal no la uso... ¿es necesaria?)
    // Mode options     // Uso el modo 0.
    .cpol_i(1'b0),      // SCK value for idle
    .dord_i(1'b0),      // 1 LSB first
    .cpha_i(1'b0),      // 1 Trailing sample
    // SPI
    .sclk_o(SCLK),      // Conexiones externas con la flash.
    .miso_i(),
    .mosi_en_o(SSbar),
    .mosi_o(MOSI)
   );

Mi idea es la siguiente... lo que yo hago es enviar un carácter a la UART ("A"), ella la detecta y me devuelve una "K" de confirmación, al mismo tiempo envía el código 0x9F por SPI a la flash (Comando de lectura de ID) y si tengo el dato de la flash listo (flash_ok), lo mando a la UART al igual que hice con la "K"
Mientras, si no recibe la "A", la UART me hace eco del carácter enviado para saber que está funcionando... Os pongo el código:

    always @(posedge clk) begin
        if (data_out == "A") begin
            data_in <= "K";
            data_spi <= 8'h9F;
            start <= 1'b1;
        end
        else if (flash_ok) begin
            data_in <= data_flash;
            flash_ok <= 1'b0;
        end
        else begin
            data_in <= data_out;
        end
        got_data_in <= got_data_out;
    end

Pero claro,... no funciona, el eco me lo hace bien, la "K" me la muestra en consola, pero de la flash no recibo nada. :((
Y lo peor es que se me han acabado las ideas... ¿Alguien ve algo extraño en el código? ¿Se le ocurre alguna idea que pueda probar?

Saludos.

[Salvador Eduardo Tropea]

Hola Juanma!

El 27/05/17 a las 04:45, Juanma Rico escribió:

> Tengo que seguir haciendo pruebas para ver si lo descarto o no, porque
> además veo que no tiene la línea MISO y no sé si es necesaria para
> nuestra flash.

MISO es Master In Slave Out, si no está conectada no vas a poder leer
nada de la memoria.

> Otra cosa que veo es que usa un modo SPI llamado "Mode 0" (Mode 0
> Positive Pulse. Latch, then Shift) que tampoco sé si es el correcto
> para nuestra flash... en fin, muchas cosas por investigar... :)))

Fijate que en total son 4 modos (2 polaridades y 2 flancos)
Algunos dispositivos funcionan en 2 de los modos sin problemas.

Saludos, Salvador

--

[Salvador Eduardo Tropea]

El 27/05/17 a las 05:19, Juanma Rico escribió:

>
>
> ¡¡Ahhh!! Ok, es como una configuración por defecto (por omisión) donde
> las patillas externas están "conectadas" al módulo SPI interno (al que
> no podemos acceder como "hard ip core" en la familia HX) cuando la
> FPGA está sin alimentación y que una vez conectada y configurada
> (volcada la flash por esos pines a la CRAM mediante este módulo SPI)
> estos pines están disponibles para conectarlos a lo que le digamos...
> ¿Es eso correcto? :))

Si. Una vez configurada esos pines quedan libres.

> ¿Eso se hace desde una SRAM?

La SRAM es lo que le dice "CRAM", es la memoria de configuración.

> ¿Se podría modificar esta SRAM "por defecto" de alguna manera?¿Está

> relacionado con lo que en el datasheet habla de /"Internal Nonvolatile
> Configuration Memory (NVCM)"/? Porque dice que se puede modificar,

> aunque una única vez... un peligro para tocar... :(((

La NVCM es sólo para producción, es una memoria OTP (One Time Programming).

>
>
> [snip]
> > Si alguien estuviera interesado, supiera guiarme, darme pistas o
> > incluso sintetizar el módulo SPI... sería perfecto. :)))
>
> Estoy un poco tapado de cosas, pero te comento que el SPI del
> Lattuino
> ya está portado a Verilog.
>
>
> ¡¡Ya te digo que no me da tiempo ni en mirar tus avances en Verilog
> con el Lattuino!! jajajajajaj
> ¡¡Genial!! Lo voy a mirar... ¿Qué tipo de implementación es?¿Es
> compatible con la flash nuestra?

Soporta todos los modos SPI, por lo que si, es compatible.

> ¿usas por casualidad la flash externa como EEPROM del Lattuino?

No por ahora. Es un periférico que dejé de lado.

> ¿Se podría usar?

Si.

> (Ya sabemos que como "memoria de programa" la cosa es lenta de usar...
> igual incluso la EEPROM del micro de Arduino es mucho más rápida... no
> sé).

La EEPROM de los AVR no es nada rápida de escribir.

> *¡¡Warning!! Idea descabellada:* Es que se me está ocurriendo ahora

> mismo, mientras escribo esto, usar la flash externa como una especie
> de tarjeta SD... como la que se usa en las impresoras 3D con el

> /*SmartLCD*/... ¿No sería más eficiente disponer de un controlador "a

> medida" en la FPGA para este tipo de impresoras 3D que no necesitara
> de un microprocesador? La ventaja más inmediata que se me ocurre es
> que los motores paso a paso estarían controlados en tiempo real y en
> paralelo, así como sensores y demás... ¡¡hummmm!! puede ser
> interesante intentarlo... no debe ser muy difícil hacer un controlador
> paso a paso "hardware" (¿un registro de desplazamiento?)
> ¡Cerraríamos el círculo y uniríamos los dos mundos! jejejejeje :)))

Tengo un periférico WISHBONE que sirve para controlar motores paso a paso.
Si te interesa avisame.

Saludos, Salvador

[Salvador Eduardo Tropea]

El 27/05/17 a las 16:38, Juanma Rico escribió:

>
> Bueno, hoy finalmente he echado un "ratillo" de laboratorio...
> Al final estoy usando el móduloSPI para Lattuino de Salvador

> <https://github.com/INTI-CMNB/SPI_IP_Core/blob/50f831831788369ab9801ed6884bcf1973a7bd54/spi_master.v>
> y el módulo UART
> <https://github.com/aarzho/spi-uart-modules/blob/master/uart-bidirectional/uarttx.v>

> que ya controlo del otro proyecto (una mezcla rara).
>
> La cuestión es que estoy un poco bloqueado, en parte porque no sé muy
> bien como funcionan los módulos...
> Os cuento... Mi idea es conectar el módulo SPI a los pines de la

> flash, para ello definimos en el fichero /*pcf*/ lo siguiente:

>
> set_io SCLK 70
> set_io MOSI 67

Agregá:
set_io MISO 68

> set_io SSbar 71
>
> Y en el fichero "top" se instancia (¿Se dice así?)

Si.

> el módulo SPI0.
>
> reg start=0;
> wire flash_ok;
> reg[7:0] data_spi, data_flash;
>
> SPI_Master SPI0 (
> // System
> .clk_i(clk),
> .rst_i(btn1), // El botón 1 resetea el SPI y la UART.
> .ena_i(1'b1), // 2*SCK
> // Interface
> .start_i(start),
> .tx_i (data_spi), // Byte que se transmite por el SPI a la flash.
> .rx_o (data_flash), // Byte que se obtiene de la flash.
> .busy_o(),
> .irq_o(flash_ok),
> .ack_i(), // IRQ Ack (Esta señal no la uso... ¿es
> necesaria?)

Se usa para volver irq_o a 0.

> // Mode options // Uso el modo 0.
> .cpol_i(1'b0), // SCK value for idle
> .dord_i(1'b0), // 1 LSB first
> .cpha_i(1'b0), // 1 Trailing sample
> // SPI
> .sclk_o(SCLK), // Conexiones externas con la flash.
> .miso_i(),

Conectala a MISO

> .mosi_en_o(SSbar),

Hmmm ... esto no te va a servir para transferencias de más de 1 byte.
Esa línea es el OE de MOSI, por si es necesario compartir el bus.
En la práctica SS se maneja por fuera del core.
La idea es que "agrupa varias transferencias en 1".
Mirá el código sketch de más abajo.

Varios detalles:
1) Sin conectar MISO jamás vas a recibir algo.
2) La flash está en deep sleep (la pone la FPGA luego de configurarse)
si no le enviás 0xAB no se despierta.

Este es el código sketch que probé:

// inslude the SPI library:
#include <SPI.h>


// set pin 10 as the slave select for the digital pot:
const int slaveSelectPin = 10;

void setup() {
// set the slaveSelectPin as an output:
pinMode(slaveSelectPin, OUTPUT);
digitalWrite(slaveSelectPin, HIGH);
Serial.begin(115200);
// initialize SPI:
SPI.begin();
wakeUp();
delay(10);
}

void loop()
{
byte id[3];
digitalWrite(slaveSelectPin, LOW);
SPI.transfer(0x9F);
// Should be EF3013 for W25X40CL
id[0]=SPI.transfer(0);
id[1]=SPI.transfer(0);
id[2]=SPI.transfer(0);
digitalWrite(slaveSelectPin, HIGH);
Serial.print(id[0], HEX);
Serial.print(id[1], HEX);
Serial.println(id[2], HEX);
delay(1000);
}

La función wakeUp es:

void wakeUp()
{
// take the SS pin low to select the chip:
digitalWrite(slaveSelectPin, LOW);
SPI.transfer(0xAB);
// take the SS pin high to de-select the chip:
digitalWrite(slaveSelectPin, HIGH);

[Juanma Rico]

¡¡Guauuu!! Gracias Salvador, menudo empujón que me has dado... :))

Ya he estado haciendo pruebas con los cambios y comentarios que me sugeriste.
El flash_ok no consigo hacer que funcione... de momento estoy haciendo pruebas enviando caracteres a la UART. Ahora recibo bytes (creo) de la flash, pero no sé si son los correctos, el protocolo que sigo:

Envío una "A", lo que me devuelve una "K" de confirmación y envía a la flash el 0xAB para que la princesita (la flash) despierte del sueño profundo en el que ha caído por culpa de la bruja (FPGA)... Sinceramente no sabía que el cuento era así... :)))

Cuando veo la "K" por consola, le envío una "B", me devuelve una "k" e igualmente le envía a la flash un 0x9F para que se identifique (la princesa diga su nombre), como la bandera flash_ok parece no funcionar, le envío entonces una "C" y recibo lo que tenga en ese momento el registro conectado a rx_o (en mi caso data_flash) y lo envío por consola mediante la UART.

En teoría me debería salir algo como lo que le sale al iceprog:

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

Pero no... me sale algo como esto:

41 4B 42 6B 43 FF 43 9F 43 FF 43 FF 43 FF 43 FF 43  |  A K B k C . C . C . C . C . C
7F 43 FF 43 FF 43 9F 43 FF 43 FF                    |  . C . C . C . C . C

Muchos 0xFF, algún 0x9F y un 0x7F... No parece que esté haciendo lo correcto...
Así que no sé si estoy interpretando bien las señales que necesita el interface... pongo mi interpretación:

    // Interface
    .start_i(start),  // Esta señal de entrada imagino que es para activar el SPI.
                      // La defino como un "reg" la activo cuando quiero enviar un byte por SPI.
                      // Nunca la desactivo (presupongo que lo hace el módulo del SPI).

    .tx_i (data_spi), // Presupongo que es el byte que se le envía al SPI.
                      // Yo la defino como "reg[7:0]".

    .rx_o (data_flash), // Creo que es el byte que proviene del SPI.
                        // La defino como "reg[7:0]".

    .busy_o(),          // Imagino que es un flag de "ocupado recibiendo un byte" que se puede consultar.
                        // Yo no la defino.

    .irq_o(flash_ok),   // Imagino que es una señal que se activa cuando el rx_o del SPI está preparado.
                        // Tengo problemas con esta señal, no sé si definirla como "reg" o como "wire".
                        // Cuando me da error le cambio la definición y sintetiza pero
                        // en un "if" parece no funcionar.

    .ack_i(ack),        // Ok, es la señal que "rearma" la interrupción.
                        // No sé como definirla, me da errores en ambas "reg" y como "wire".

El resto de señales creo que no necesitan interpretación.
La cuestión es que no me va la lectura de la flash... :(((
Voy a intentar el sketch que me has puesto con el Lattuino a ver si soy capaz de sacar alguna conclusión.

¡¡Muchísiimas gracias de nuevo, Salvador!!

Saludos.

[Juanma Rico]

Nada Salvador...

El programa de ejemplo es muy grande para el Lattuino en la iceZUM Alhambra (1k).   :((((

Seguiré dando palos de ciego directamente con el módulo SPI...

Gracias. :)))

El lunes, 29 de mayo de 2017, 17:24:53 (UTC+2), Salvador Eduardo Tropea escribió:

Este es el código sketch que probé:

// include the SPI library:

[Goyo Serrano]

Este modulo SPI + UART se podría utilizar para dar vida al conversor AD de nuestra Alhambra? Habria que estudiarlo esa parte de la fuerza, tenemos a ese chips sin vida....

[Salvador Eduardo Tropea]

El 29/05/17 a las 16:18, Juanma Rico escribió:

>
> ¡¡Guauuu!! Gracias Salvador, menudo empujón que me has dado... :))
>
> Ya he estado haciendo pruebas con los cambios y comentarios que me
> sugeriste.

> El /*flash_ok */no consigo hacer que funcione... de momento estoy

> haciendo pruebas enviando caracteres a la UART. Ahora recibo bytes
> (creo) de la flash, pero no sé si son los correctos, el protocolo que
> sigo:
>
> Envío una "A", lo que me devuelve una "K" de confirmación y envía a la

> flash el 0xAB para que la /*princesita*/ (la flash) despierte del
> /*sueño profundo*/ en el que ha caído por culpa de la /*bruja*/

> (FPGA)... Sinceramente no sabía que el cuento era así... :)))

:-)))
A mi me dio bastante dolor de cabeza la princesita dormida cuando
modifiqué el flashrom. Hasta que vi bien lo que decía la datasheet de la
iCE40.

>
> Cuando veo la "K" por consola, le envío una "B", me devuelve una "k" e
> igualmente le envía a la flash un 0x9F para que se identifique (la

> princesa diga su nombre), como la bandera /*flash_ok*/ parece no

> funcionar, le envío entonces una "C" y recibo lo que tenga en ese

> momento el registro conectado a /*rx_o*/ (en mi caso /*data_flash*/) y

> lo envío por consola mediante la UART.
>

> En teoría me debería salir algo como lo que le sale al /*iceprog*/:

>
> flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x54 0x82 0x46 0x06 0x00
> 0x56 0x00 0x29 0x19 0x01 0x16 0xA4 0xB5
>
> Pero no... me sale algo como esto:
>

> *41 4B* *42 6B* 43 *FF* 43 *9F* 43 *FF* 43 *FF* 43 *FF* 43 *FF* 43 |
> *A K* *B k* C . C . C . C . C . C
> *7F* 43 *FF* 43 *FF* 43 *9F* 43 *FF* 43 *FF* | . C . C . C .

> C . C
>
> Muchos 0xFF, algún 0x9F y un 0x7F... No parece que esté haciendo lo
> correcto...
> Así que no sé si estoy interpretando bien las señales que necesita el

> /interface/... pongo mi interpretación:

>
> // Interface
> .start_i(start), // Esta señal de entrada imagino que es para
> activar el SPI.
> // La defino como un "reg" la activo cuando
> quiero enviar un byte por SPI.
> // Nunca la desactivo (presupongo que lo hace el
> módulo del SPI).

Es indispensable que la desactives, la idea es que start sea un pulso,
sería "arrancá". Si la dejas alta el core va a estar transmitiendo todo
el tiempo, ni bien termine va a ver que start está en 1 y va a volver a
transmitir lo que tenga en la entrada.

> .tx_i (data_spi), // Presupongo que es el byte que se le envía al SPI.
> // Yo la defino como "reg[7:0]".

Si, lo que esté ahí es lo que se envía.

> .rx_o (data_flash), // Creo que es el byte que proviene del SPI.
> // La defino como "reg[7:0]".

Si, tené en cuenta que en el SPI se recibe mientras se envía. No existe
"solo enviar" o "solo recibir".
Lo normal es enviar 0s cuando estás queriendo leer una respuesta.

> .busy_o(), // Imagino que es un flag de "ocupado recibiendo
> un byte" que se puede consultar.
> // Yo no la defino.

Si es algo así, aunque teniendo en cuenta lo que te digo arriba es
"transmitiendo un byte". Jamás deberías levantar start mientras busy sea 1.
Con tu mecanismo "manual" supongo que no es necesario que lo leas, pero
en cuanto quieras transmitir automáticamente vas a tener que leerlo.

> .irq_o(flash_ok), // Imagino que es una señal que se activa cuando
> el rx_o del SPI está preparado.

Si. La idea es que esto genere una interrupción a la CPU.

> // Tengo problemas con esta señal, no sé si definirla como "reg" o
> como "wire".
> // Cuando me da error le cambio la definición
> y sintetiza pero
> // en un "if" parece no funcionar.

De tu lado es un wire. La idea es que irq_o pasa a 1, vos leés el valor
que está en rx_o y avisás con ack (un pulso).

> .ack_i(ack), // Ok, es la señal que "rearma" la interrupción.
> // No sé como definirla, me da errores en
> ambas "reg" y como "wire".

Depende de como armes tu core. Con que dure un pulso de reloj alcanza.
Puede ser un reg. Lo más lógico es que armes una máquina de estados que:
1) Espera a recibir la orden de transmisión
2) Levante start
3) Baje start
4) Espere a que irq_o sea 1
5) Retire rx_o
6) Levante ack
7) Baje ack
8) Vuelva a 1

Esto se puede hacer con 2 estados:
IDLE, espera a que tenga que transmitir, mantiene ack en 0, si tiene que
transmitir levanta start
WAIT, mantiene start en 0, espera a que irq_o sea 1. Cuando irq_o es 1:
copia rx_o y levanta ack.

Acá start y ack son 2 FFs separados del FF que codifica el estado. Con
más estados serían cables.

> El resto de señales creo que no necesitan interpretación.
> La cuestión es que no me va la lectura de la flash... :(((

> Voy a intentar el */sketch/* que me has puesto con el */Lattuino/* a

> ver si soy capaz de sacar alguna conclusión.

Miralo bien, es importante lo que hace con SS. En tu caso SS bajaría a
0, mandás Wake-up, ponés SS en 1. Luego para leer el ID: bajás SS,
enviás 0x9F, enviás tantos 0s como bytes quieras leer del ID, subís SS

[Salvador Eduardo Tropea]

Si, además necesita el periférico SPI, que no está incluido, no entra.
La idea es que veas la secuencia en que se hacen las cosas.

El 29/05/17 a las 16:32, Juanma Rico escribió:
> Nada Salvador...
>
> El programa de ejemplo es muy grande para el /Lattuino/ en la /iceZUM
> Alhambra/ (1k). :((((

[Salvador Eduardo Tropea]

¿Qué A/D usan?
En la Kéfir uso un MCP3008, es SPI, pero siempre usé un core específico,
¿por qué? porque es muy pero muy simple implementarlo y porque las
transacciones óptimas no conviene hacerlas de a bytes. El A/D es de 10
bits y en cada lectura hay que seleccionar el canal y si se lo usa
diferencial o no.
En GitHub está el core para el MCP3008 y un ejemplo que lo usa para
hacer adquisiciones en forma continua y colocar algunos de los bits en
los LEDs. Es probable que con muy pocos cambios sirva para otros A/D que
son SPI.

El 30/05/17 a las 07:43, Goyo Serrano escribió:

> Este modulo SPI + UART se podría utilizar para dar vida al conversor
> AD de nuestra Alhambra? Habria que estudiarlo esa parte de la fuerza,
> tenemos a ese chips sin vida....
>
>
> El lunes, 29 de mayo de 2017, 21:32:13 (UTC+2), Juanma Rico escribió:
>
> Nada Salvador...
>

> El programa de ejemplo es muy grande para el /Lattuino/ en la
> /iceZUM Alhambra/ (1k). :((((
>
>
>

> --
> Has recibido este mensaje porque estás suscrito al grupo "FPGAwars:
> explorando el lado libre" de Grupos de Google.
> Para cancelar la suscripción a este grupo y dejar de recibir sus
> mensajes, envía un correo electrónico a
> fpga-wars-explorando-el...@googlegroups.com
> <mailto:fpga-wars-explorando-el...@googlegroups.com>.
> Para publicar en este grupo, envía un correo electrónico a
> fpga-wars-explora...@googlegroups.com
> <mailto:fpga-wars-explora...@googlegroups.com>.
> Visita este grupo en
> https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
> Para ver esta conversación en el sitio web, visita
> https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/22e629ac-3e3f-445b-96f3-b346bca7704c%40googlegroups.com
> <https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/22e629ac-3e3f-445b-96f3-b346bca7704c%40googlegroups.com?utm_medium=email&utm_source=footer>.
> Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Juanma Rico]

Buenas Salvador,

Según los papeles que tengo impresos y pegados por las paredes del taller (jejejejeje) es un ADS7924 y se comunica por I2C, no por SPI.

Para Goyo Serrano... hay unos cuantos de hilos en este mismo grupo donde se está intentando aprovechar este chip de la iceZUM Alhambra, el que veo que está más desarrollado y con más progresos es este. Échale un vistazo y nos cuentas. :))

Saludos.

[Juanma Rico]

Buenas Goyo,

Bueno, la parte de la UART es aprovechable siempre, con la ventaja de que tienes una conexión al exterior que te permite hacer muchas pruebas desde el PC (con la flexibilidad que esto conlleva), el tema está en el bloque SPI... el chip usa y está conectado para usar un protocolo I2C, así que imagino que necesitas sustituir la síntesis del bloque SPI por la síntesis de un bloque I2C.

En un mensaje de respuesta a Salvador he puesto el enlace a los avances en ese sentido,... pero releyendo tu pregunta me surge otra más general... aprovecho este mismo hilo para ver si alguien me puede contestar.

Normalmente, en los microcontroladores que he manejado, los pines del módulo I2C y de SPI son pines físicos compartidos, en principio son protocolos distintos... ¿Qué hace que normalmente se compartan sus pines?¿Tienen más cosas en común de lo que yo pienso?¿Hay algo en su core interno que pueda ser aprovechado de alguna u otra manera?¿O simplemente se aprovecha solo su conexión al exterior?

Saludos

[Juanma Rico]

¡Buenas Salvador!

El martes, 30 de mayo de 2017, 14:17:36 (UTC+2), Salvador Eduardo Tropea escribió:

El 29/05/17 a las 16:18, Juanma Rico escribió:
>
> ¡¡Guauuu!! Gracias Salvador, menudo empujón que me has dado... :))
>
> Ya he estado haciendo pruebas con los cambios y comentarios que me
> sugeriste.
> El /*flash_ok */no consigo hacer que funcione... de momento estoy
> haciendo pruebas enviando caracteres a la UART. Ahora recibo bytes
> (creo) de la flash, pero no sé si son los correctos, el protocolo que
> sigo:
>
> Envío una "A", lo que me devuelve una "K" de confirmación y envía a la
> flash el 0xAB para que la /*princesita*/ (la flash) despierte del
> /*sueño profundo*/ en el que ha caído por culpa de la /*bruja*/
> (FPGA)... Sinceramente no sabía que el cuento era así... :)))


:-)))
A mi me dio bastante dolor de cabeza la princesita dormida cuando
modifiqué el flashrom. Hasta que vi bien lo que decía la datasheet de la
iCE40.

¡Desde luego! Yo te lo agradezco, me has evitado muchos cabezazos... Si no me lo llegas a indicar no lo hubiese imaginado... De hecho he estado "toqueteando" el iceprog como sabes y ni lo había visto. :)))

Ya lo he mirado con más calma y efectivamente en iceprog también despierta a la princesita... aunque usa un término más suave... él simplemente la "espabila"... jejejejeje :))

void flash_power_up()
{
    uint8_t data[1] = { 0xAB };
    set_gpio(0, 0);
    xfer_spi(data, 1);
    set_gpio(1, 0);
}

Perfecto, esa señal de start_i era una de mis dudas... ya sabiéndolo pondré más cuidado al usar esta señal y muy posiblemente este sea uno de los motivos por los que no me va el módulo.
 

>     .tx_i (data_spi), // Presupongo que es el byte que se le envía al SPI.
>                       // Yo la defino como "reg[7:0]".


Si, lo que esté ahí es lo que se envía.

Era como yo pensaba entonces... ¿Hay algún problema con que no se ponga a cero cuando estás leyendo?
Lo digo porque estudiando tu código en el sketch para Lattuino (como sabes no puedo probarlo... :((( ), veo que para leer transmites un cero... mi pregunta es esa... ¿Para leer necesito transmitir un cero o puedo dejar el valor que haya que no afecta a la lectura?

>     .rx_o (data_flash), // Creo que es el byte que proviene del SPI.
>                         // La defino como "reg[7:0]".

Si, tené en cuenta que en el SPI se recibe mientras se envía. No existe
"solo enviar" o "solo recibir".
Lo normal es enviar 0s cuando estás queriendo leer una respuesta.

jajajajaja, me leíste el pensamiento... :)))
Reitero la pregunta... ¿Es obligatorio enviar ceros para leer?¿O simplemente con no enviar un byte de comando es suficiente?

> .busy_o(),          // Imagino que es un flag de "ocupado recibiendo
> un byte" que se puede consultar.
>                         // Yo no la defino.

Si es algo así, aunque teniendo en cuenta lo que te digo arriba es
"transmitiendo un byte". Jamás deberías levantar start mientras busy sea 1.
Con tu mecanismo "manual" supongo que no es necesario que lo leas, pero
en cuanto quieras transmitir automáticamente vas a tener que leerlo.

Vaya, leyendo este párrafo me doy cuenta que no lo tenía tan claro como pensaba... entonces "start_i" activa no solo la lectura sino la escritura... todo a la vez. No es únicamente una señal para indicar que el envío del tx_o está listo. Ok, entendido. :))
 

> .irq_o(flash_ok),   // Imagino que es una señal que se activa cuando
> el rx_o del SPI está preparado.

Si. La idea es que esto genere una interrupción a la CPU.

Perfecto.
 

> // Tengo problemas con esta señal, no sé si definirla como "reg" o
> como "wire".
>                         // Cuando me da error le cambio la definición
> y sintetiza pero
>                         // en un "if" parece no funcionar.

De tu lado es un wire. La idea es que irq_o pasa a 1, vos leés el valor
que está en rx_o y avisás con ack (un pulso).

Osea, no "rearmas" la interrupción como yo pensaba. En las interrupciones de los micros que he tenido que programar en ensamblador (hace muchos años) lo que se hacía era forzar a la misma señal irq_o al valor contrario con la que se activaba y al final del bloque de código, con esto se evitaba que una misma interrupción saltara dos veces... veo que no es el caso... ¡apuntado! :))
 

> .ack_i(ack),        // Ok, es la señal que "rearma" la interrupción.
>                         // No sé como definirla, me da errores en
> ambas "reg" y como "wire".

Depende de como armes tu core. Con que dure un pulso de reloj alcanza.
Puede ser un reg. Lo más lógico es que armes una máquina de estados que:
1) Espera a recibir la orden de transmisión
2) Levante start
3) Baje start
4) Espere a que irq_o sea 1
5) Retire rx_o
6) Levante ack
7) Baje ack
8) Vuelva a 1

Esto se puede hacer con 2 estados:
IDLE, espera a que tenga que transmitir, mantiene ack en 0, si tiene que
transmitir levanta start
WAIT, mantiene start en 0, espera a que irq_o sea 1. Cuando irq_o es 1:
copia rx_o y levanta ack.

Acá start y ack son 2 FFs separados del FF que codifica el estado. Con
más estados serían cables.

Sí, me voy a tener que pasar a la máquina de estados en algún momento... por ahora la máquina de estados soy yo, un papel con la secuencia y los caracteres ASCII que envío desde la consola del PC al bloque de la UART que sintetizo en la FPGA... :))) pero sí, en algún momento tendré que repensar y generar la FSM. Soy un bebé en esto... pasito a pasito que sino me caigo... :)))
 

> El resto de señales creo que no necesitan interpretación.
> La cuestión es que no me va la lectura de la flash... :(((
> Voy a intentar el */sketch/* que me has puesto con el */Lattuino/* a
> ver si soy capaz de sacar alguna conclusión.

Miralo bien, es importante lo que hace con SS. En tu caso SS bajaría a
0, mandás Wake-up, ponés SS en 1. Luego para leer el ID: bajás SS,
enviás 0x9F, enviás tantos 0s como bytes quieras leer del ID, subís SS

Otro fallo de concepto, yo pensaba que SSbar debía estar LOW todo el tiempo como habilitando la flash continuamente (está ella sola)... este puede ser otro importante punto donde se producen los errores de lectura. :)))
 

Saludos, Salvador

Saludos y muchísimas gracias, al final con tantas explicaciones conseguirás que, tan torpe como soy, sea capaz de leer la flash y todo... :)))
 

[Juanma Rico]

Buenas Salvador,

Sí, no entra casi nada en la iCE40HX-1k...¡Que malo eres! nos pones delante la zanahoria del Lattuino y vemos como con desesperación no llegamos a ella....¿Seguro que no se puede usar una DRAM externa o algo similar con la suficiente velocidad como para que sirva de memoria principal al AVR y meterle un "chute" de memoria a la iceZUM Alhambra? :)))

¡al final vas a hacer que me tenga que construir la Kéfir-8k! jajajajajaja :))

Por otra parte...
Sí, estuve echando un vistazo a la secuencia y encontré varios fallos en mi forma de pensar el protocolo (seguramente por mi falta de práctica en el SPI... creo que mi mente está más hecha al I2C).

Así que con esto y lo que me has comentado en el mensaje anterior de las señales del "Interface" del bloque SPI_master.v espero poder ya centrar el problema.... Por cierto... ¿Este interface del módulo SPI es un interface propio? He estado buscando por el proyecto de github y no he encontrado ninguna referencia al mismo (igual no he buscado bien).

Y hablando del tema... ¿Me permites una sugerencia? Los que no conocemos mucho los lenguajes HDL nos es difícil pensar en él (tenemos tendencia a ver el código como secuencial) y como imagino que harás pruebas de simulación con los bloques... ¿No sería una buena idea subir unas imágenes de capturas con la secuencia de las señales en simulación?

A mi personalmente me aclararía mucho (soy eminentemente visual, lo tengo que dibujar todo) e imagino que siempre viene bien tener todas las señales de los procesos básicos en una imagen, no tienes que leer código y la mente no se te dispersa en la secuencia el mismo. Por supuesto es una sugerencia... creo que didácticamente sería una herramienta útil para comprobar el funcionamiento de un bloque. :)))

Saludos.

[Jose Pico]

Hola Juanma:

en http://opencores.org/projects

he visto que hay una cantidad inmensa de cores a nuestra disposición listos para ser probados ( muchos de ellos en verilog ),

a ver si tengo tiempo  y puedo convertir alguno de ellos en módulos de Icestudio para que sean fáciles de usar ( UARTs,SPIs,I2C estos serían increíbles y nos darían mucha

vidilla ) 

Saludos y menuda currada te estás pegando.

[Juanma Rico]

Hola José,

Lo primero pedirte disculpas por tener abandonado en el proyecto del PID, veo que en ese hay muchas personas que te pueden ayudar, pero también veo que el proyecto del Warm/Cold Boot estaba parado y solo estoy yo y... pocos más... Unai está desaparecido... :-P (Espero esté bien).

La cuestión es que (gracias al empuje de Salvador y su Lattuino) he retomado el tema porque me gustaría cerrar el círculo de esta posibilidad que nos brinda nuestra placa. La placa tiene un chip FPGA limitado y hay que estrujarlo al máximo y con ello los chips que le rodean... eso si queremos que sea una placa competitiva y poder usarla a tope... para ello hay que poder acceder directamente a la flash desde la FPGA y, como no dispone de ello en el hard-core (otra limitación, en este caso de la familia HX), sintetizar y saber controlar un módulo SPI... en ello estamos. :)))

Una vez controlado el acceso a flash ya se podrá usar, no solo para el sistema Warm/Cold Boot, sino para guardar cualquier tipo de información (se me ocurre en el proyecto del PID poder guardar un histórico de señales o parámetros "no volátiles" de sintonización que se necesiten... y miles de otros circuitos que seguro necesitarán de una memoria no volatil...).

Respecto a OpenCores... sí, tienes razón hay muchos módulos en Verilog (y algunos muy interesantes), el tema está en que si usas icestudio pocas ventajas vas a tener.

Icestudio (a mi entender) tiene ese problema, fallo, handicap, limitación... como quieras llamarlo, es una cuestión de concepto... y es que reutilizar código de terceros que no estén hechos en icestudio es complicado (no se diseñó para eso), lo único que puedes hacer es encerrarlo en una cajita y volcar el código en un bloque de código... pero poco más... y a partir de ahí tienes que seguir usando icestudio, no puedes volver atrás (al menos no fácilmente)... y sinceramente, no sé si el esfuerzo merece la pena (al menos en fases de pruebas), ya bastantes problemas te da echar a andar un módulo que no has hecho tú y "simplemente" hay que comprenderlo un poco y copiar un fichero para sintetizarlo (Jesús no estaría de acuerdo conmigo, claro... :))) ).

Pero no quiero desanimarte, si tú usas icestudio y te ves con ánimo, adelante. Imagino que ese bloque que adaptes, si funciona, lo terminarán usando otros muchos usuarios de icestudio.
Icestudio es una herramienta que, de alguna u otra forma, también puede potenciar nuestra placa... y más ahora que van a haber como 250 nuevos propietarios de una recién salida de fábrica. :)))
Imagínate si tu esfuerzo sirve para que estos 250 no tengan que pelearse con un módulo SPI y simplemente utilizarlo uniendo líneas con otros módulos que ellos hayan creado y que esos nuevos los pongan a disposición de los demás... Icestudio se llenaría de módulos en muy poco tiempo...  es para estar orgulloso... yo lo estaría. :)))

Saludos, gracias y ánimo.

[Jose Pico]

El miércoles, 31 de mayo de 2017, 8:33:03 (UTC+2), Juanma Rico escribió:

Hola José,

Lo primero pedirte disculpas por tener abandonado en el proyecto del PID, veo que en ese hay muchas personas que te pueden ayudar, pero también veo que el proyecto del Warm/Cold Boot estaba parado y solo estoy yo y... pocos más... Unai está desaparecido... :-P (Espero esté bien).

   No hay nada porque disculpar, todos vamos liadísimos y tenemos muy buenas intenciones, los que nos falata es tiempo. jejejejejej!

   Yo mismo lo tengo también parado porque necesito también que los datos que recibo del exterior los pueda almacenar o enviar  por i2c/uart..etc a alg-un sitio donde visualizar

   por ejemplo la cuenta del encoder.

   De hecho realicé un pequeño módulo de tx de uart que parece que funciona pero que es aún muy simple ya que envía sólo un caracter de 8 bits y me gustaría que tuviera una 

   FIFO o pequeño buffer donde poder enviar los datos y estos se enviasen conforme el puerto está disponible.

   En el fondo nada está parado, todo está ahí en un proceso encadenado que de repente puede explotar... jjejejjje

   Veo muy interesante cualquier módulo i2c,spi,UART. jejeje

   Unai es otro fiera !  Seguro que está bien y muy liado también 

   Ánimo y sigue así!

La cuestión es que (gracias al empuje de Salvador y su Lattuino) he retomado el tema porque me gustaría cerrar el círculo de esta posibilidad que nos brinda nuestra placa. La placa tiene un chip FPGA limitado y hay que estrujarlo al máximo y con ello los chips que le rodean... eso si queremos que sea una placa competitiva y poder usarla a tope... para ello hay que poder acceder directamente a la flash desde la FPGA y, como no dispone de ello en el hard-core (otra limitación, en este caso de la familia HX), sintetizar y saber controlar un módulo SPI... en ello estamos. :)))

   Salvador es otro fiera!  

Una vez controlado el acceso a flash ya se podrá usar, no solo para el sistema Warm/Cold Boot, sino para guardar cualquier tipo de información (se me ocurre en el proyecto del PID poder guardar un histórico de señales o parámetros "no volátiles" de sintonización que se necesiten... y miles de otros circuitos que seguro necesitarán de una memoria no volatil...).

Respecto a OpenCores... sí, tienes razón hay muchos módulos en Verilog (y algunos muy interesantes), el tema está en que si usas icestudio pocas ventajas vas a tener.

Icestudio (a mi entender) tiene ese problema, fallo, handicap, limitación... como quieras llamarlo, es una cuestión de concepto... y es que reutilizar código de terceros que no estén hechos en icestudio es complicado (no se diseñó para eso), lo único que puedes hacer es encerrarlo en una cajita y volcar el código en un bloque de código... pero poco más... y a partir de ahí tienes que seguir usando icestudio, no puedes volver atrás (al menos no fácilmente)... y sinceramente, no sé si el esfuerzo merece la pena (al menos en fases de pruebas), ya bastantes problemas te da echar a andar un módulo que no has hecho tú y "simplemente" hay que comprenderlo un poco y copiar un fichero para sintetizarlo (Jesús no estaría de acuerdo conmigo, claro... :))) ).

   Bueno ! la verdad es que a mí me ha captado Icestudio, es una herramienta que está realizada de una forma visual y que yo le veo muchas posibilidades.

   Yo soy un seguidor de Jesús a muerte! jjejeejjjejej

   Sin ella seguramente no estaría aquí  o por lo menos para lanzarme en el conocimento FPGA, luego nunca se sabe.

   Arduino tampoco tenía las librerias que tiene al inicio y hoy las usan niños sin saber bien lo que lleva en sus tripas.

  Icestudio lo veo parecido. 

   En cuanto crezca el número de Módulos, crecerá exponencialmente su uso....jjejjejeje

  

Pero no quiero desanimarte, si tú usas icestudio y te ves con ánimo, adelante. Imagino que ese bloque que adaptes, si funciona, lo terminarán usando otros muchos usuarios de icestudio.
Icestudio es una herramienta que, de alguna u otra forma, también puede potenciar nuestra placa... y más ahora que van a haber como 250 nuevos propietarios de una recién salida de fábrica. :)))
Imagínate si tu esfuerzo sirve para que estos 250 no tengan que pelearse con un módulo SPI y simplemente utilizarlo uniendo líneas con otros módulos que ellos hayan creado y que esos nuevos los pongan a disposición de los demás... Icestudio se llenaría de módulos en muy poco tiempo...  es para estar orgulloso... yo lo estaría. :)))

   Yo soy cabezón pero voy despaciooooo.

   Saludos y a seguir así

[Jesús Arroyo]

Buenas,

Comento mi opinión en el tema:

Los proyectos de Icestudio son reutilizables al tratarse de un formato abierto. Puedes utilizarlos directamente como bloques en Icestudio, lo más normal, pero también puedes exportar el código verilog y utilizarlo como módulo en otro código verilog. De hecho siempre podemos desarrollar compiladores que conviertan los .ice a nuevos formatos según las necesidades que surjan, por lo que siempre podremos reutilizar ese trabajo. Y si por alguna razón quieres utilizar directamente el código en verilog "original" lo descargas de Opencores. Tienes todas las opciones.

Para implementar un bloque de Icestudio puedes hacerlo directamente copiando el código del módulo en un bloque e incluyendo los submódulos (si existen) en un fichero .v (// @include math.v). Esta sería la forma más rápida de implementarlo y aporta mucho valor ya que cualquiera puede utilizar este bloque "as-is". Pero existe una opción más interesante y es implementarlo mediante otros bloques lo cual a su vez incrementa el poder didáctico del proyecto.

Los editores gráficos permiten acercar el conocimiento ya que no tienen la "barrera" de un lenguaje de programación para poder transmitir la información de un diseño. De hecho en las charlas con la IceZUM Alhambra ya no enseñamos código verilog puesto que un esquema visual transmite más. Es un lenguaje si quieres "más natural" y creo que eso es una fortaleza a la hora de aprender y enseñar electrónica digital. Pero además también es compatible con el código HDL (verilog). Por lo tanto, aporta más ventajas que inconvenientes.

Así que como siempre os animo a seguir contribuyendo al patrimonio y aprendiendo en el camino :)

Un saludo.

[Juanma Rico]

Sabía yo que Jesús saltaba... jajajajajaja
Es su criatura y es normal... :))))

¡¡Naaaaaaahhhh!!! No me interpretes mal Jesús, yo estoy encantado con iceStudio (Software libre... ¡Por Dios!¡Faltaría más!) pero para pruebas de bloques de terceros que estoy haciendo "a bajo nivel" (por decirlo de alguna forma), me es muy costoso usar iceStudio, me ha pasado tener muchas pruebas hechas y tener que rehacerlas por un cambio en la estructura... o antiguos esquemas que ya no puedo utilizar... es normal, es una herramienta en desarrollo.

Sin ir más lejos... Miquel me ha pasado un fichero "ice" de ACC0 para que lo revise y no he podido ejecutarlo, ni por curiosidad. El formato de Obijuan que está en github me avisa de que es antiguo y me da un error "incomprensible" de falta de un módulo con un ID que no hay quién lo encuentre... Afortunadamente el error lo he localizado antes, en la compilación con yaYUL.

Es verdad que yo tenía una versión beta instalada... pero he actualizado y me ha dado otro error y del que no puedo encontrar información si no es preguntándote a ti que eres el único que lo conoce... y claro, tú estás super-liado y yo también... al final...

Para pruebas... Ahí se queda el iceStudio, si lo que yo quiero es hacer pruebas con un módulo SPI casi mejor lo sintetizo desde consola (eso sí, uso apio... ;-))) ) que los errores que me dan son más genéricos y tengo Google y más gente a la que preguntar.

No dudes que en cuanto ya me funcione el módulo SPI lo intentaré meter en un bloque, es más, si existiera en iceStudio ya lo estaría utilizando para probar con la flash... a mi también me gustan las herramientas visuales, no soy experto ni extremista del código HDL en ese sentido, pero José quiere "probar" bloques de terceros que no están preparados para iceStudio y nunca ha utilizado... simplemente le advierto de que además de con el bloque tendrá que pelearse con los errores de iceStudio...

Ya que has saltado aprovecho y te adjunto los dos errores que me han dado al intentar poner al Apollo en dirección a la Luna y en órbita a ella... :)))

Este con una versión de iceStudio-0.3.0-beta3

Busca tú ahora el módulo "main_v8e30f0_v1cfb82" cuando el que usa iceStudio no sabe ni que existe un fichero "main.v"... y el que lo sabe lo usa directamente... :))))

Y el mismo fichero, en el mismo subdirectorio con una versión de iceStudio-0.3.0-rc (actualizado) te lanza este...

A cual de los dos errores menos descriptivos (seguro que tú nada más verlos sabes lo que está pasando, claro).

Cuando sabes que el funcionamiento del módulo SPI de Salvador no depende de iceStudio y te encuentras con estos errores y que no sabes a quién preguntar... te animas a meterle mano a la consola y a Googlear y preguntas lo esencial a Salvador para por lo menos hacerlo funcionar...
Es solo cuestión de rentabilizar el tiempo de pruebas, solo eso.... :)))

Saludos Jesús

Pdta: Está pendiente de hablar de las imágenes de Warn Boot... habrá que ir pensando en pestañas para que en un mismo fichero "ice" entren varios circuitos... Como ves como último objetivo está el iceStudio...  :))

[Jesús Arroyo]

Nada, es símplemente por puntualizar. Más allá de que sea un proyecto mío o no quiero dejar constancia de opinión ;)

Con respecto a los problemas que indicas te comento:

• En Icestudio los proyectos antiguos se convierten al nuevo formato. En el caso del ACC lo suyo sería rediseñarlos para utilizar las nuevas features (buses, constantes, etc) pero el proyecto es funcional.
  
• A partir la versión Beta3 se añadieron capturas de errores tanto de bloques código como en bloques genéricos.
• En la versión RC hay un problema de aislamiento de apio. Este inconveniente aparece cuando por ejemplo tienes instalada la versión apio con apt-get. Lo que indica el error "no such option -p" es que se está utilizando el apio del sistema que es una versión anterior al requerido.

Estos problemas están solucionados en la versión de develop :D que pronto se convertirá en release. Si puedes probar esta versión y verificarlo sería genial. Adjunto captura.




Para todas las cosas "raras" de Icestudio podéis preguntarme siempre :-). Os recomiendo también probar la versión de develop por si el error ha sido solucionado.

Un saludo!


PD: muy interesante lo del WarnBoot. Habrá que pensar cómo incluir esta funcionalidad en el IDE. Pero insisto, lo ideal no es que todo se centralice en Icestudio. Simplemente he remarcado los puntos positivos que tiene el proyecto en mi opinión. Queda mucho por mejorar y nuevos proyectos que crear y para esto estamos aquí ;D

[Goyo Serrano]

Tienes razón, se conecta por I2C me había despistado, al leer tu post me vine arriba. Mirare a ver si puedo hacer algo, gracias.

[Juanma Rico]

Buenas Jesús,

Ya un poco para zanjar el tema...  ya que nos ponemos y desnudamos nuestras almas... :)))

Esta contestación que me has dado en menos de un minuto más me reafirma... ¿Cuanto tiempo me hubiera llevado a mi (con capturas o sin capturas de errores) saber que el error "no such option -p" de iceStudio se debe a una instalación de apio desde apt-get? Es más, si no estás tú para contestarme... ¿Podría haber llegado a averiguarlo en algún momento simplemente leyendo código? (Lo dudo...) ¿A quién podría preguntar para que me resolviera la duda en un minuto (o dos) si no es a ti?

Y eso nos lleva a un tema más profundo (desnudemos almas) y es que, para bien o para mal, con sus ventajas e inconvenientes, el proyecto iceStudio es (y entiéndase bien) "demasiado tuyo".

No es más que una opinión. algo para reflexionar... pero ... ¿Cuanto tiempo llevas desarrollándolo prácticamente en solitario? Según github como mínimo desde febrero de 2016... a lo largo de estos largos ya 15 meses (e igual me quedo corto) y a la velocidad que crece la comunidad... aún no veo a nadie, repito a nadie (ni siquiera a Obijuan) que pueda tomar el testigo del proyecto si tú algún día (¡Dios no lo quiera! :))) ) lo tuvieras que dejar.

Yo he sido testigo de intentos en esta misma lista de colaborar y de gente interesada en el proyecto... (yo mismo lo intenté en su día) y no digo "colaborar" en el sentido de dar tu opinión y decir "prefiero ese botón en verde", que tú lo modifiques (si estás de acuerdo con el color) y que luego aparezca su nombre en los agradecimientos, cosa que, por supuesto, siempre es de agradecer (mi nombre está, gracias :)) ), sino digo de personas que generen código integrable en el proyecto, que sean capaces de cambiar el color verde por ellos mismos, que generen otros colores, que no se frustren porque no pueden cambiar nada más que el color...

Los pocos intentos de que he sido testigo en esta lista de colaborar en este último sentido han empezado por dibujar en el explorador un cuadrado mediante NodeJS... es decir, a hacer lo que tú ya hiciste hace años... a repetir la curva de aprendizaje... sin aportar nada nuevo al proyecto (más que su interés, que no es poco), por supuesto hace tiempo que perdieron el interés...

En github en la rama develop, a día de hoy, hay 1093 commits (todos son tuyos, claro) los pull-request son 101 de los cuales son tuyos (auto-tuyos) más de la mitad (63), 4 de Obijuan y otros varios de otras personas... la mayoría son traducciones.

Y esto me da que pensar... ¡¡Hay pull-request de traducciones en vasco!!... es decir, hay gente interesada en colaborar y lo único que encuentran como salida a su interés es traducir del castellano al vasco... :(((

Es decir, hay interés en la heramienta y en aportar... pero no se puede, no más allá de una traducción, solo estamos traduciendo... no más allá de leer todo el código e intentar reproducir lo que tú ya has hecho... :(((

No sé porqué, no sé si es la combinación de código web con NodeJS, el servidor que hay que levantar para que aquello funcione... y nunca funciona... la complejidad y la dependencia del sistema... no soy programador profesional... pero en el grupo seguro que sí lo hay y se está desaprovechando su interés por aportar funcionalidad a la herramienta...

Igual hacen falta micro-tutoriales de cómo construir la herramienta,... igual hacen falta charlas dirigidas a programadores de software que puedan explorar la construcción de la herramienta en sí y cree interés por la tecnología que utiliza y las soluciones que tú has aportado en iceStudio... no sé, la cuestión es que vengo observando mucho interés en usarla y poco o nula posibilidad de desarrollarla... y la verdad es que es una pena.

A estas alturas del proyecto, si no se abordara esta cuestión, ya se haría inviable cualquier intento de colaborar (aún siendo experto en NodeJS). Creo que es algo por reflexionar.

No quiero que te lo tomes a mal Jesús, pero a mi me frustra no poder hacer intentos de integrar mi WarmBoot por mi mismo en iceStudio... y lo peor no es eso (que puede ser por mi ignorancia de la tecnología) es que no veo otra persona que no seas tú que lo pueda integrar.

Como digo es una opinión y estoy casi convencido (pondría la mano en el fuego ahora mismo...) de que no estás de acuerdo con ella y te vas a "rebotar". Pero era cuestión de desnudar almas... desnudas están. :))))

Saludos.

[Juanma Rico]

jajajajajajaja... "venirse arriba"... :)))

¿A quién no le ha pasado alguna vez? ¿Y lo bien que nos sentimos cuando "nos venimos arriba"? :)))
Si mi post ha servido para eso, estupendo, se te admite el despiste... :))
Hay que venirse arriba de vez en cuando... al ego hay que alimentarlo... :)))

Además, si consigues echar a andar el módulo de I2C... ¡Bienvenido sea el despiste!! jejejejeje

Saludos.

[Salvador Eduardo Tropea]

El 30/05/17 a las 13:51, Juanma Rico escribió:

>
>
> > .tx_i (data_spi), // Presupongo que es el byte que se le
> envía al SPI.
> > // Yo la defino como "reg[7:0]".
>
>
> Si, lo que esté ahí es lo que se envía.
>
> Era como yo pensaba entonces... ¿Hay algún problema con que no se
> ponga a cero cuando estás leyendo?

> Lo digo porque estudiando tu código en el /sketch/ para */Lattuino/*

> (como sabes no puedo probarlo... :((( ), veo que para leer transmites
> un cero... mi pregunta es esa... ¿Para leer necesito transmitir un
> cero o puedo dejar el valor que haya que no afecta a la lectura?

No debería afectar.

[snip]

>
>
> > .busy_o(), // Imagino que es un flag de "ocupado
> recibiendo
> > un byte" que se puede consultar.
> > // Yo no la defino.
>
> Si es algo así, aunque teniendo en cuenta lo que te digo arriba es
> "transmitiendo un byte". Jamás deberías levantar start mientras
> busy sea 1.
> Con tu mecanismo "manual" supongo que no es necesario que lo leas,
> pero
> en cuanto quieras transmitir automáticamente vas a tener que leerlo.
>
> Vaya, leyendo este párrafo me doy cuenta que no lo tenía tan claro
> como pensaba... entonces "start_i" activa no solo la lectura sino la
> escritura... todo a la vez. No es únicamente una señal para indicar
> que el envío del tx_o está listo. Ok, entendido. :))

El tema es que SPI es bidireccional siempre, siempre que se escribe se
lee, puede que lo que se lea sea basura, pero eso es otro tema ;-)

[snip]

>
> > // Tengo problemas con esta señal, no sé si definirla como "reg" o
> > como "wire".
> > // Cuando me da error le cambio la
> definición
> > y sintetiza pero
> > // en un "if" parece no funcionar.
>
> De tu lado es un wire. La idea es que irq_o pasa a 1, vos leés el
> valor
> que está en rx_o y avisás con ack (un pulso).
>
>
> Osea, no "rearmas" la interrupción como yo pensaba. En las
> interrupciones de los micros que he tenido que programar en
> ensamblador (hace muchos años) lo que se hacía era forzar a la misma

> señal /*irq_o*/ al valor contrario con la que se activaba y al final

> del bloque de código, con esto se evitaba que una misma interrupción
> saltara dos veces... veo que no es el caso... ¡apuntado! :))

En la práctica lo más probable es que la CPU que usaste tenga algo así
por debajo. La señal irq_o es la salida del flip-flop que indica
interrupción, ack es la señal que resetea el flip-flop.
Usualmente irq_o es lo que lees en algún bit de un registro de estado de
la CPU, ack puede que se genere escribiendo a ese bit o simplemente
retirando el dato disponible, o simplemente atendiendo la interrupción.

Ok.

> > El resto de señales creo que no necesitan interpretación.
> > La cuestión es que no me va la lectura de la flash... :(((
> > Voy a intentar el */sketch/* que me has puesto con el
> */Lattuino/* a
> > ver si soy capaz de sacar alguna conclusión.
>
> Miralo bien, es importante lo que hace con SS. En tu caso SS
> bajaría a
> 0, mandás Wake-up, ponés SS en 1. Luego para leer el ID: bajás SS,
> enviás 0x9F, enviás tantos 0s como bytes quieras leer del ID,
> subís SS
>
>
> Otro fallo de concepto, yo pensaba que SSbar debía estar LOW todo el
> tiempo como habilitando la flash continuamente (está ella sola)...
> este puede ser otro importante punto donde se producen los errores de
> lectura. :)))
>
>
> Saludos, Salvador
>
>
> Saludos y muchísimas gracias, al final con tantas explicaciones
> conseguirás que, tan torpe como soy, sea capaz de leer la flash y
> todo... :)))
>
>

:-)))) es como todo, una vez que lo haz hecho es fácil, antes ... difícil

Saludos, Salvador

[Jesús Arroyo]

Buenas Juanma,

Siento no responderte con la misma extensión:

Todo lo que comentas son obviedades: soy el principal contribuidor de Icestudio, que es un proyecto libre y cualquierla lo puede utilizar, modificar, preguntar, dar feedback y contribuir si quiere y puede. Como en todo proyecto libre. Desde luego algo hay que saber tanto para contribuir a un proyecto como para crear uno nuevo, eso es trivial.

Debido a mi naturaleza más práctica, me gustaría saber si has probado a sintetizar el ACC con Icestudio develop para verificar que está corregido el bug que comentabas antes.

Un saludo.

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

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

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ae6aed89-5ea9-46a0-b631-321701a4b2bc%40googlegroups.com.

[Juanma Rico]

Sí, lo he intentado... lo tenía muy abandonado (unos 211 commits abandonado)... he tenido que actualizar el proyecto en git (un pull sin problemas, algunos cambios que estaban en mi rama que no estaban en la develop... un checkout, un merge manual y listo).

Luego han aparecido errores de grunt:

>> Local Npm module "grunt-appimage" not found. Is it installed?
>> Local Npm module "grunt-contrib-jshint" not found. Is it installed?
>> Local Npm module "grunt-zip" not found. Is it installed?

Una búsqueda por Google y lo he solucionado instalándolos:

$ npm install grunt-appimage
$ npm install grunt-contrib-jshint
$ npm install grunt-zip

Finalmente he tenido que repetir la actualización con sudo por falta de permisos en ciertos subdirectorios:

$ sudo npm update -g

Lo he lanzado:

$ npm start

Se ha abierto el marco de la ventana del iceStudio, pero tras una media hora no se ha producido ningún cambio en la ventana, ningún mensaje de error en consola... y he cerrado finalmente la ventana de iceStudio. Hasta ahí he llegado... Espero te sea útil. :)))

Saludos.

[Salvador Eduardo Tropea]

Hola Juanma:

El 30/05/17 a las 14:12, Juanma Rico escribió:

>
> Buenas Salvador,
>
> Sí, no entra casi nada en la iCE40HX-1k...¡Que malo eres! nos pones

> delante la zanahoria del /Lattuino/ y vemos como con desesperación no

> llegamos a ella....¿Seguro que no se puede usar una DRAM externa o
> algo similar con la suficiente velocidad como para que sirva de
> memoria principal al AVR y meterle un "chute" de memoria a la iceZUM
> Alhambra? :)))

Eso resolvería el problema de la memoria de programa/RAM, pero no el de
los periféricos.

>
> ¡al final vas a hacer que me tenga que construir la Kéfir-8k!
> jajajajajaja :))

:-)))

>
> Por otra parte...
> Sí, estuve echando un vistazo a la secuencia y encontré varios fallos
> en mi forma de pensar el protocolo (seguramente por mi falta de
> práctica en el SPI... creo que mi mente está más hecha al I2C).

Lo más recomendable es que mires la hoja de datos de alguna de las
memorias. Suelen tener dibujada la secuencia en que se mueven las señales.

> Así que con esto y lo que me has comentado en el mensaje anterior de

> las señales del "/Interface/" del bloque *SPI_master.v* espero poder
> ya centrar el problema.... Por cierto... ¿Este /interface/ del módulo
> SPI es un /interface/ propio? He estado buscando por el proyecto de

> github y no he encontrado ninguna referencia al mismo (igual no he
> buscado bien).

No se si interpreto bien la pregunta. Las señales que usa el core para
comunicarse con el exterior son más o menos las mismas que usa cualquier
otro core, hay algunos detalles de las señales que tienen que ver con
como funcionan el AVR y sus periféricos. En cuanto a la implementación
interna del core: fue hecha desde 0, fijate que hay otra diferente en el
repo, pero estaba más pensada para otros usos.

> Y hablando del tema... ¿Me permites una sugerencia? Los que no
> conocemos mucho los lenguajes HDL nos es difícil pensar en él (tenemos
> tendencia a ver el código como secuencial) y como imagino que harás
> pruebas de simulación con los bloques... ¿No sería una buena idea
> subir unas imágenes de capturas con la secuencia de las señales en
> simulación?

Usualmente soy muy meticuloso con el tema de verificación, hago bancos
de prueba para todo. Sin embargo en el caso del Lattuino tomé un camino
más pragmático, la CPU tiene unos cuantos bancos de prueba, los
periféricos no. El punto es que son pequeños y bien modulares. La
mayoría funcionaron a la primera, y cuando algo falló bastó con ver un
poco el código para encontrar que era.
Por otro lado:
1) Mis bancos de pruebas no están pensados para que un humano vea
señales, es el banco de pruebas el que dice si el core anda o no.
2) Es posible levantar las formas de onda de alguno de los bancos de
pruebas, pero usualmente no son muy fáciles de entender. El punto es que
al ser simulaciones funcionales (sin timing) los tiempos entre un flanco
y sus consecuencias son nulos, y eso confunde a cualquiera que no esté
acostumbrado.

Es mucho más claro ver como son las formas de onda del SPI en una datasheet.
El adjunto es READ ID de la datasheet de la S25FL128P.
Ahí podés ver como CS# (SS) se mantiene en 0 solo durante esta
transacción, por otro lado muestra que SI (MOSI) vale 9F (MSB primero)
en el primer byte, pero luego no importa lo que valga (dibuja 0 y 1 a la
vez)

>
> A mi personalmente me aclararía mucho (soy eminentemente visual, lo
> tengo que dibujar todo) e imagino que siempre viene bien tener todas
> las señales de los procesos básicos en una imagen, no tienes que leer
> código y la mente no se te dispersa en la secuencia el mismo. Por
> supuesto es una sugerencia... creo que didácticamente sería una
> herramienta útil para comprobar el funcionamiento de un bloque. :)))

Al menos en Linux basta con instalar make, gtkwave y ghdl y correr:

$ make test_m
$ gtkwave Work/spi_controller_tb.ghw

Adjunté las formas de onda de el test de spi_controller (el otro core)
pidiendo el ID a una S25FLxxx (simulada)

[Jesús Arroyo]

Asegúrate de que todos los paquetes de node están instalados con el comando:

npm install

Y luego ejecuta:

npm start


Un saludo.

[Juanma Rico]

¡Buenas Salvador!

El miércoles, 31 de mayo de 2017, 14:14:34 (UTC+2), Salvador Eduardo Tropea escribió:

Hola Juanma:

El 30/05/17 a las 14:12, Juanma Rico escribió:
>
> Buenas Salvador,
>
> Sí, no entra casi nada en la iCE40HX-1k...¡Que malo eres! nos pones
> delante la zanahoria del /Lattuino/ y vemos como con desesperación no
> llegamos a ella....¿Seguro que no se puede usar una DRAM externa o
> algo similar con la suficiente velocidad como para que sirva de
> memoria principal al AVR y meterle un "chute" de memoria a la iceZUM
> Alhambra? :)))


Eso resolvería el problema de la memoria de programa/RAM, pero no el de
los periféricos.

¡¡Cachiiiissss!! ¡Todos son problemas! ¡¡Tú lo que quieres es que me construya una Kéfir...¡¡ :))))
 

>
> ¡al final vas a hacer que me tenga que construir la Kéfir-8k!
> jajajajajaja :))

:-)))

No, hablando en serio... :))
¿Es muy complicada la Kéfir? ¿Podría construírmela yo en casa?
Mira que mis conocimientos de electrónica son muy básicos... nivel Ingeniero Industrial, osea que si no tiene un regulador de Watt dando vueltas... ya me pierdo... :))))

>
> Por otra parte...
> Sí, estuve echando un vistazo a la secuencia y encontré varios fallos
> en mi forma de pensar el protocolo (seguramente por mi falta de
> práctica en el SPI... creo que mi mente está más hecha al I2C).

Lo más recomendable es que mires la hoja de datos de alguna de las
memorias. Suelen tener dibujada la secuencia en que se mueven las señales.

¡A sus órdenes! Eso haré... Me da un poco de pereza, la verdad... pero lo haré. jajajajajajaja  :)))

> Así que con esto y lo que me has comentado en el mensaje anterior de
> las señales del "/Interface/" del bloque *SPI_master.v* espero poder
> ya centrar el problema.... Por cierto... ¿Este /interface/ del módulo
> SPI es un /interface/ propio? He estado buscando por el proyecto de
> github y no he encontrado ninguna referencia al mismo (igual no he
> buscado bien).

No se si interpreto bien la pregunta. Las señales que usa el core para
comunicarse con el exterior son más o menos las mismas que usa cualquier
otro core, hay algunos detalles de las señales que tienen que ver con
como funcionan el AVR y sus periféricos. En cuanto a la implementación
interna del core: fue hecha desde 0, fijate que hay otra diferente en el
repo, pero estaba más pensada para otros usos.

Sí, bueno... me refiero a las señales que etiquetas en el fichero SPI_master.v como //Interface
que son las que te dan los bytes de salida y entrada (tx_o y rx_o) ya preparados (que yo directamente conecto con la UART) y el resto de señales start_i, busy_o, ack_i y irq_o.
No es un Wishbone ni nada parecido... ¿no? (perdona mi completa ignorancia)

Perfecto, entendido, lo miraré... :))))
 

>
> A mi personalmente me aclararía mucho (soy eminentemente visual, lo
> tengo que dibujar todo) e imagino que siempre viene bien tener todas
> las señales de los procesos básicos en una imagen, no tienes que leer
> código y la mente no se te dispersa en la secuencia el mismo. Por
> supuesto es una sugerencia... creo que didácticamente sería una
> herramienta útil para comprobar el funcionamiento de un bloque. :)))

Al menos en Linux basta con instalar make, gtkwave y ghdl y correr:

$ make test_m
$ gtkwave Work/spi_controller_tb.ghw

Adjunté las formas de onda de el test de spi_controller (el otro core)
pidiendo el ID a una S25FLxxx (simulada)

¡Es verdad! ¡GHDL para tus ficheros en vhdl del testbench! No podemos sintetizar... pero simular sí... ¡Genial! :)))

 

Saludos, Salvador

Saludos agradecidos para ti también. :)))
 

[Salvador Eduardo Tropea]

Hola Juanma!

El 31/05/17 a las 09:36, Juanma Rico escribió:

Hmmm ... es necesario poder soldar componentes pequeños, la FPGA es de
lo más difícil que tiene el PCB. El paso es 0,5 mm. Por lo que se
necesita un soldador con punta fina, una lupa, fundente (flux) y mucha
paciencia.
No es imposible, pero lleva tiempo.
Yo para soldar el prototipo usé una estación de soldadura PACE con una
punta bien finita y un videoscopio, que es más cómodo que una lupa.
Estoy viendo si le puedo hacer llegar a Obijuan los PCBs de Milk y
Kéfir, junto con los componentes, para que pueda armarla.
El diseño fue pensado para que sea lo más simple posible, no es
indispensable usar un horno de refusión y pasta de estaño, el PCB es de
sólo 2 caras, etc. Pero los componentes como la FPGA tienen un paso
fino, aún cuando es el encapsulado más fácil de soldar de la iCE40,
pensá que hay de 16 bolitas en 1,4x1,5 mm ;-)

>
>
> >
> > Por otra parte...
> > Sí, estuve echando un vistazo a la secuencia y encontré varios
> fallos
> > en mi forma de pensar el protocolo (seguramente por mi falta de
> > práctica en el SPI... creo que mi mente está más hecha al I2C).
>
> Lo más recomendable es que mires la hoja de datos de alguna de las
> memorias. Suelen tener dibujada la secuencia en que se mueven las
> señales.
>
>
> ¡A sus órdenes! Eso haré... Me da un poco de pereza, la verdad... pero
> lo haré. jajajajajajaja :)))

Te lo ahorré con la captura ;-)

>
>
> > Así que con esto y lo que me has comentado en el mensaje
> anterior de
> > las señales del "/Interface/" del bloque *SPI_master.v* espero
> poder
> > ya centrar el problema.... Por cierto... ¿Este /interface/ del
> módulo
> > SPI es un /interface/ propio? He estado buscando por el proyecto de
> > github y no he encontrado ninguna referencia al mismo (igual no he
> > buscado bien).
>
> No se si interpreto bien la pregunta. Las señales que usa el core
> para
> comunicarse con el exterior son más o menos las mismas que usa
> cualquier
> otro core, hay algunos detalles de las señales que tienen que ver con
> como funcionan el AVR y sus periféricos. En cuanto a la
> implementación
> interna del core: fue hecha desde 0, fijate que hay otra diferente
> en el
> repo, pero estaba más pensada para otros usos.
>
>
> Sí, bueno... me refiero a las señales que etiquetas en el fichero

> *SPI_master.v* como *//Interface*
> que son las que te dan los bytes de salida y entrada (*tx_o* y *rx_o*)

> ya preparados (que yo directamente conecto con la UART) y el resto de

> señales *start_i, busy_o, ack_i* y *irq_o*.

> No es un Wishbone ni nada parecido... ¿no? (perdona mi completa
> ignorancia)

Ah! ok. Si son "adhoc", pero como te comentaba, son un handshake muy común.

Saludos, Salvador

[Juanma Rico]

¡¡Hola de nuevo!!

Hoy estoy en el laboratorio y tengo tiempo hasta la hora de comer... Creo que se nota... :))

Creo que paciencia es lo más difícil de encontrar en mi ferretería del barrio... de todas formas preguntaré por si acaso...  :))))

No es imposible, pero lleva tiempo.
Yo para soldar el prototipo usé una estación de soldadura PACE con una
punta bien finita y un videoscopio, que es más cómodo que una lupa.

 :-O
Creo que no me llega el presupuesto...

Estación de Soldadura PACE MBT350

Fabricante: PACE

Estación de soldadura/desoldadora digital totalmente programable, de tres canales para usar simultáneamente y potencia de 240W

$7.783.300+IVA.

Voy a tener que esperar... hace poco mandé fabricar las PCB's de otra placa... una ecow-Logic, francesa... y ahí la tengo, que no consigo soldarla... creo que me tiene que subir el SAV un poco más... jejejejejeje :)))

 

Estoy viendo si le puedo hacer llegar a Obijuan los PCBs de Milk y
Kéfir, junto con los componentes, para que pueda armarla.

¡Míralo él! ¡Qué suerte tiene!
No hay nada como que te den un premio Internacional de software libre... ¿eh? jajajajajajajaj (envidia sana) :))))

El diseño fue pensado para que sea lo más simple posible, no es
indispensable usar un horno de refusión y pasta de estaño, el PCB es de
sólo 2 caras, etc. Pero los componentes como la FPGA tienen un paso
fino, aún cuando es el encapsulado más fácil de soldar de la iCE40,
pensá que hay de 16 bolitas en 1,4x1,5 mm ;-)

Con lo de las bolitas me quieres animar,...  ¿verdad? jajajajaj :))))
 

>
>
>     >
>     > Por otra parte...
>     > Sí, estuve echando un vistazo a la secuencia y encontré varios
>     fallos
>     > en mi forma de pensar el protocolo (seguramente por mi falta de
>     > práctica en el SPI... creo que mi mente está más hecha al I2C).
>
>     Lo más recomendable es que mires la hoja de datos de alguna de las
>     memorias. Suelen tener dibujada la secuencia en que se mueven las
>     señales.
>
>
> ¡A sus órdenes! Eso haré... Me da un poco de pereza, la verdad... pero
> lo haré. jajajajajajaja  :)))


Te lo ahorré con la captura ;-)

Ya están guardadas... después de comer lo intento... :)

Por cierto... por aquello de hacer pruebas, separé algunas acciones asociadas a caracteres ASCII recibidos por la UART (a modo de "microinstrucciones") para simular el protocolo y las secuencias SPI, es decir, recibo un "1" pues pongo el SS en HIGH, un "2" pongo el valor de tx_o en la UART... así.
La cuestión es que aún no lo he probado en profundidad... ¿tiene posibilidades de funcionar o los tiempos entre pulsaciones de teclas bajo la UART es muy lento para el SPI que necesita unos tiempos mínimos?

Perfecto, curiosidad resuelta, gracias.

Saludos, Salvador

Saludos

[Salvador Eduardo Tropea]

Hola Juanma:

El 31/05/17 a las 10:24, Juanma Rico escribió:

Otro difícil de conseguir: buen pulso ;-)

>
> No es imposible, pero lleva tiempo.
> Yo para soldar el prototipo usé una estación de soldadura PACE con
> una
> punta bien finita y un videoscopio, que es más cómodo que una lupa.
>
>
> :-O
> Creo que no me llega el presupuesto...
>
>
>
> Estación de Soldadura PACE MBT350
>
> Fabricante: PACE

> <http://suconel.com.co/home2/suconelc/public_html/index.php?option=com_virtuemart&view=manufacturer&virtuemart_manufacturer_id=22>

>
> Estación de soldadura/desoldadora digital totalmente programable, de
> tres canales para usar simultáneamente y potencia de 240W

> *$7.783.300+IVA.
> *


Pero noooo ... con un buen soldador de punta fina alcanza, el problema
es que hay que adquirir un poco de práctica.

> *
> *Voy a tener que esperar... hace poco mandé fabricar las PCB's de otra

> placa... una ecow-Logic, francesa... y ahí la tengo, que no consigo
> soldarla... creo que me tiene que subir el SAV un poco más...
> jejejejejeje :)))
>
> Estoy viendo si le puedo hacer llegar a Obijuan los PCBs de Milk y
> Kéfir, junto con los componentes, para que pueda armarla.
>
>
> ¡Míralo él! ¡Qué suerte tiene!
> No hay nada como que te den un premio Internacional de software
> libre... ¿eh? jajajajajajajaj (envidia sana) :))))

En realidad con Juan nos venimos "cruzando" desde hace unos 12 años ;-)

>
> El diseño fue pensado para que sea lo más simple posible, no es
> indispensable usar un horno de refusión y pasta de estaño, el PCB
> es de
> sólo 2 caras, etc. Pero los componentes como la FPGA tienen un paso
> fino, aún cuando es el encapsulado más fácil de soldar de la iCE40,
> pensá que hay de 16 bolitas en 1,4x1,5 mm ;-)
>
>
> Con lo de las bolitas me quieres animar,... ¿verdad? jajajajaj :))))

Imaginate si hubiera usado un encapsulado como ese ;-)

Saludos, Salvador

[Jose Pico]

Hola:

Donde está la versión de develop para poder probarla ?  ( perdona mi ignorancia pero la última que yo he visto es la 0.3.0-rc  y esta no me soporta los errores en windows )

Saludos

El miércoles, 31 de mayo de 2017, 11:21:29 (UTC+2), Jesús Arroyo escribió:

[Jesús Arroyo]

Hola Jose:

Por probar la rama develop me refiero a ejecutar Icestudio desde las fuentes. En el Readme hay un enlace con las instrucciones: https://github.com/FPGAwars/icestudio#development.

El primer paso es instalar Node.js 6: https://nodejs.org/en/.

Luego se clona el repositorio:

git clone https://github.com/FPGAwars/icestudio.git
cd icestudio

Se actualizan los paquetes:

npm install

Y se ejecuta:

npm start

De esta forma se pueden probar los últimos cambios en la aplicación sin esperar a la release.

Me comentas si tienes algún problema.

Un saludo.

[Juanma Rico]

Buenas... noticias del SPI de nuestra flash... ¡Me he comunicado ya por fin con ella desde la propia FPGA y he obtenido el ID! :))))

Los avances de Obijuan con el I2C me han animado a "hacer hueco de domingo" y ponerme con el módulo SPI que lo tenía a medio probar (las consecuencias del "hueco" en un día de playa como este que hace hoy en Málaga son aún imprevistas... :P), la prueba era leer el ID de la flash, (los valores que te entrega con el comando 0x9F) y que se puede obtener mediante iceprog con el comando -t, en mi caso el ID lanzado desde iceprog es este (imagino que cada flash tendrá un ID distinto):

Y los valores obtenidos por consola meidante UART son estos:

Como véis a partir de la pareja FF son los mismos... :))

Queda por documentar un poco y ordenarlo, pero el SAV no me ha dejado mucho tiempo, así que prefiero antes compartirlo con vosotros por si lo queréis reproducir con la ID de vuestra propia flash.
Si habéis seguido este hilo, yo he usado el módulo SPI de Salvador E. Tropea para el Lattuino y para mostrar datos por pantalla y enviar órdenes a la FPGA, he usado una UART del proyecto de Aarzho (github). Pues bien, ambos módulos funcionan perfectamente, está claro que me atascaba en el modo de usarlos (la famosa interfase)... al final era cuestión de como mostrar los valores y controlar el módulo UART, el SPI funcionaba perfectamente y a la primera con la ayuda de Salvador (muchas gracias, Salvador :D ).

Por si lo queréis reproducir, os dejo los ficheros adjuntos necesarios, el binario (hardware.bin) para la iceZum Alhambra también, por si no podéis esperar a sintetizar y queréis probarlo sin más... ;)
En los ficheros podéis encontrar todos los comentarios de las señales y de qué hace cada pulsación (hay mucho escrito porque yo no me aclaraba, espero que os sirva).

Para sintetizar las pruebas he usado apio desde consola (simplemente copiar y descomprimir los ficheros a un subdirectorio y ejecutar "apio upload").
Una vez descargada la imagen en la FPGA el funcionamiento es el siguiente:

1. Se abre el puerto desde GTKTerm (cualquier otro es válido), se pone a 115200 baudios, se muestra en hexadecinal, se le quita el eco local y se deja a la espera.
   Si pulsáis ahora cualquier tecla desde la consola la cosa no funciona (no hay eco).
   
   
2. Para que funcione se resetean los módulos (SPI y UART) pulsando el botón 1 de la iceZum Alhambra.
   
   
3. Si ahora pulsais cualquier letra (no números) os devuelve el eco... vemos que la UART está funcionando.
   
   
4. Para ver que el módulo SPI funciona y lee la flash, hacer lo siguiente:
   
   
1. Pulsamos la tecla 1 y se activará internamente el protocolo SPI con la flash como esclavo (el led0 se enciende).
   
2. Pulsamos la tecla 2, enviamos por SPI el comando 0xAB para despertar a la flash (el led1 se enciende y aparece FF en consola).
   
3. Pulsamos la tecla 3, desactivamos el esclavo (el led2 se enciende).
4. Pulsamos la tecla 4, activamos de nuevo el esclavo, que es la flash ya despierta (el led3 se enciende).
5. Pulsamos la tecla 5, solo se enciende el led4, internamente no se hace nada.
6. Pulsamos la tecla 6, se enciende el led5 y aparece un FF en consola, internamente se escribe el comando 0x9F en SPI para que nos entregue el ID.
7. Hacemos sucesivas pulsaciones de la tecla 6, se leerá un nuevo byte del ID y aparecerá "mágicamente" en consola, cuando todos se terminen aparecerán ceros.
8. Comprobamos que los valores son los correctos... :)))
   

Y eso es todo... ya en teoría podemos escribir/leer directamente en la flash desde nuestra propia FPGA instanciando un módulo SPI... queda establecer toda esta secuencia en una máquina de estados y hacer pruebas de escritura por subsectores... y sobre todo aplicar esto a modificar directamente la cabecera de la flash para poder cambiar los vectores del Cold/Warm boot y así poder elegir entre 127 imágenes sintetizadas desde la propia FPGA..... ¡Sin ningún PC conectado, sin usar iceprog! :)))

Un pasito más...

Saludos.

Pdta: Calmado mi SAV, os recuerdo que el módulo SPI no solo es útil para grabar nuestra flash interna (esa era mi "batalla" particular para usarla con el Cold/Warm boot)... con los pines redirigidos adecuadamente desde la FPGA podemos ya comunicarnos con cualquier dispositivo externo que necesite SPI, al igual que Obijuan ha usado el módulo I2C para comunicarse con el chip ADC interno de la placa, pueden usarse estos mismos módulos para comunicarnos con cualquier otro dispositivo externo... unos cablecillos y listo... a ver quién es el primero... ¡¡lanzado está el reto!! :)))

Pdta2: Si alguien reproduce el experimento (con el binario no llega ni a 10 segundos) me gustaría quedara constancia de la ID de la flash... a modo de trofeo. Escribid un mensaje con las capturas de los ID's en este mismo hilo si lo conseguís.  :)))

[Jose Pico]

Fantástico! Hay que ver q interesante se pone últimamente el grupo! Un UART,
Un i2c , ahora un spi
Muchas gracias a todos!

En poder me pongo a probar todo ( en icestudio ya q yo de momento solo se funcionar con icestudio y es la tool q me ha lanzado hacia las FPGAs )

Saludos y Gracias por tener tanto SAV

[Juan Gonzalez Gomez]

Genial!!!!  Comprobado en mi flash!!! Funciona!  😀

Adjunto pruebas.  Este es el id de la flash:

Y esto es lo leido por gtkterm:

:-D

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/0d5d208e-2168-4ae4-92f3-9dc15e7284ff%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[Juanma Rico]

¡¡Bieeeeeennn!! ¡¡Perfecto!! ¡¡Gracias Juan!! :))))

[Juanma Rico]

Buenas José,


Lo he intentado...Dios sabe que lo he intentado, pero no he podido terminarlo, mira qué hora es y no he podido... :(((

He hecho por trasladar el código completo a "bloques de código" en el icestudio (lo que creo que es más sencillo), pero cuando he ido a conectarlo todo... entre las líneas que hacen lo que quieren al mover el bloque (o yo que soy muy torpe) y que me parece que me he equivocado en una salida de la UART que he puesto como entrada... (con lo que hay que rehacer todo lo que tenga que ver con el bloque)... ya me he rendido, me estaba empezando a desesperar y antes de enfadarme he decidido dejarlo...  :(((

De todas formas te adjunto lo que he hecho en icestudio, por si tú tienes más maña, ánimos y paciencia que yo para reconectar los bloques. Ya me avisas si lo logras. :))))

Saludos

Pdta: Como los buses de entrada y salida no se pueden parametrizar en icestudio, he fijado a 8 el ancho del bus, además de poner el DATA_W=8 como constante para las definiciones internas del bloque.

[Jose Pico]

Muchas gracias por el esfuerzo!
Lo intentaré en tener un rato, seguro q alguien al final lo deja bonito!
Mil gracias y a de recuperar ese SAV

[Juanma Rico]

Buenas al grupo,

Hoy he tenido un ratito para seguir jugueteando con la comunicación con la flash por SPI...
He modificado el programa principal (top.v) para incluir una máquina de estados como me sugirió Salvador (en realidad no sé si llega a tener esa entidad de máquina de estados ya que yo de Verilog ando escaso...), lo que me ha permitido simplificar la secuencia que hay que enviar por el puerto serie. Además ahora... ¡ya podemos leer directamente la memoria de la flash! :)

Os adjunto el fichero con los cambios (cuando tenga tiempo crearé un proyecto nuevo en github por si queréis aportar o hacer algún seguimiento). Respecto al esquema anterior las pulsaciones de teclas quedan:

•  Letras... como siempre, eco para saber que está funcionando la UART. (no olvidar resetear los módulos con el botón 1).
  
  
• Tecla 1, despierta el chip de la flash. (es necesario la primera vez que se resetea la iceZum pues la FPGA duerme el chip una vez leida la configuración de él).
  
  
• Tecla 2, desactiva el esclavo. (es necesario para establecer un comando nuevo).
  
  
• Tecla 3, pide entregue TODOS los bytes del ID de la flash por la UART. (si repetimos la pulsación obtendremos ceros, para obtener de nuevo el ID hay que desactivar la actual transferencia pulsando la tecla 2).
  
  
• Tecla 4, pide entregue los primeros 1024 bytes (1KB) leidos de la flash empezando por la dirección cero. (si no se pulsa la tecla 2 la transferencia queda abierta y cada vez que pulsemos la tecla 4 obtendremos los siguientes 1024 bytes de la memoria).
  
  
• Tecla 5, pide al bloque que envíe el siguiente byte de memoria.

Con esto podemos leer la memoria completa pulsando las teclas 4 y 5  repetidamente (os sorprendería ver lo que guarda la memoria de vuestra flash después de unas cuantas programaciones de prueba... ;P).

En cuanto tenga otro hueco (no sé cuando) intentaré establecer la dirección de lectura mediante otro comando y así poder leer los vectores de la applet, con los vectores obtenidos podemos acceder a los nombres de las imágenes que contiene la flash (si se ha usado el icemulti modificado para ello) y así poder extraer el listado (opción iceprog -l del iceprog modificado) con la idea de poder decidir qué imagen intercambiar con los vectores seleccionables por Warm boot y así cambiar el bitstream "ejecutable" por la FPGA.

Tened en cuenta que por ahora uso la UART por comodidad para las pruebas (enviar comandos y recibir información por el puerto serie), pero la idea final es que los comandos se puedan enviar por simples botones (o un pequeño teclado) y la información pueda ser reflejada en un LCD o similar, de tal forma que hagamos innecesaria la conexión con el PC (o MAC) para cambiar el bitstream interno de la FPGA. De esta manera damos mayor independencia a la placa para cambiar su comportamiento.

Ahora elijo el bitstream 3 y es un robot de sumo... ahora elijo otro bitstream y es un sigue líneas... ahora elijo el circuito que sinteticé para salir de un laberinto... en fin, lo que se os ocurra... la versatilidad de la FPGA ya la conocéis.  :))))

Ya me diréis si os funciona... :)
Saludos

[Jose Pico]

Hola Juanma!

Adjunto el  SPI en icestudio (corregido sobre el tuyo) he tenido que:

reg  irq_o;   //***** Añadir esta línea para definir la salida   irq_o   del tipo registro ya que si no es así hay una incompatibilidad con el tipo de dato al  hacer una asignación noBlocking del  tipo   irq_o<= xx dentro de un procedimiento always ( que algún experto en verilog me lo corriga,confirme...)

y luego tenias un simple error léxico al escribir la entrada cpol_i  pusiste cpo_i  por lo que no  existia dentro del código verilog.

tenemos el bloque pero ahora abría que probarlo.

Si Salvador es tan amable de explicar un poco las señales de entrada - salida sería de gran ayuda.

no soy experto en SPI pero los SPI que yo he visto no tenian tantas señales de control jejjejejej

[Jose Pico]

Juanma!

en poder miro top y uart

Saludos y buenas noches

[Juanma Rico]

Buenas José,

Gracias por las correcciones. Estaba ya desesperado... :)))

Le echaré un vistazo a tu módulo creo que gracias a Salvador me voy a poder reconciliar con icestudio e igual empiezo a crear módulos y bloques para él. :)

Las señales del módulo SPI están ya explicadas por Salvador en este mismo hilo.

Aún así están reexplicadas por mi en el propio código. (No en el de icestudio, en icestudio se pierde el codigo que instancia los módulos, sino en el original de Verilog, mira la parte del fichero top.v donde se instancian ambos módulos).

En el módulo SPI de Salvador hay tantas señales porque la comunicación SPI serie la "trocea" y agrupa en un par de registros donde sitúa los datos para posteriormente poder acceder a ellos... es como el módulo UART, los bits transmitidos en serie los agrupa en bytes para poder trabajar internamente con ellos.

Además Salvador ha hecho el módulo tan general que hay señales simplemente de "configuración" del modo de trasmisión que luego se fijan a un valor y no cambian.

Échale un vistazo al código, ahí lo explico, si tienes dudas pregúntame... a Salvador déjamelo que nos está intentando hacer las modificaciones más fáciles en icestudio...jajajajaja ;)))

Esto módulo del SPI ya lo tengo bastante trillado y seguro que puedo contestarte a cualquier pregunta en el modo de funcionamiento. ;)))

Míralo y me cuentas.
Un saludo.

[Jose Pico]

Lo miraré con cariño en poder!
Mil gracias, seguro q te pregunto.
Saludos

[Juanma Rico]

Buenas a todos,

Aunque ya se controla lo suficiente el módulo SPI para comunicarnos con nuestra flash y la conexión con el módulo UART ya permite mandar órdenes de lectura y recibir los datos a una consola del PC, surge un "pequeño" problema al escribir en la flash... el granulado de escritura de nuestra flash. No se puede escribir un único byte de una dirección de memoria en concreto.

Para escribir en la flash un único byte de un sector, antes hay que leer el sector, borrar el sector completo, para luego escribir "del tirón" dicho sector con el byte cambiado. Nuestra flash permite granulados de borrado de 4kB de sector, 64kB (el que usa iceprog) de sector y un borrado completo.

Para modificar el primer sector (con la idea de cambiar los vectores del sistema "cold/warm boot") lo que se hace en el iceprog "modificado" es leer el sector de 4kB y guardarlo en memoria del PC, borrar el granulado de 4kB y volver a grabar el sector leido anteriormente con los cambios que hagamos en él (el intercambio de vectores de la cabecera).

Esto desde el PC es fácil de hacer, pero en la FPGA que tiene la iceZum Alhambra (iCE40HX1K) la cosa se complica. El integrado únicamente tiene 64kb (kbits) de RAM con lo que no dispone de los 4kB (kbytes) que se necesita para guardar el sector a modificar y luego grabar.

La cuestión es que solo se me ocurre disponer de una memoria RAM estática externa a la placa que nos permita utilizarla en forma de buffer temporal para estas grabaciones en la flash... pero claro, ya la cosa se complica y si se quiere usar el sistema "cold/warm boot" en una futura versión de la iceZum Alhambra habría que incluir una memoria RAM estática en la placa...

¿A alguien se le ocurre una forma de solventar este problema con lo el hardware del que disponemos?
Si ya no hay más remedio y hay que incluir una memoria RAM estática... ¿Alguien conoce alguna memoria RAM que utilice un mínimo de pines y que disponga de al menos de 4kB para estas transacciones?

En espera de alguna pista... ;)
Un saludo.

[Juanma Rico]

Me auto-respondo...

hoy ando despistadillo con las tareas diarias, así que me he puesto a buscar y he encontrado que Microchip tiene una pequeña gama de lo que él llama "Serial RAM" algunas de ellas (sino todas) admiten el protocolo SPI, por tanto no tendríamos que añadir ningún IP Core a la FPGA para usarla (con el mismo de la flash y unas modificaciones para seleccionar el esclavo podría valer).

La gama completa la podéis encontrar aquí.

El SAV ha podido conmigo y he pedido dos tipos (de 64kb y 1kB) en formato PDIP para que sea fácil hacer pruebas en la placa entrenadora.
De momento es lo que se me ocurre para conseguir los 4kB que se necesitan: un integrado externo. Ya os sigo contando cuando lleguen y pueda hacer alguna prueba.

Saludos.

[Manuel Luis Alcázar Laynez]

Hola a todos! Sé que el hilo tiene más de 3 años, pero por si a alguien le pudiera servir lo dejo por aquí.

He probado las "Serial RAM" que comenta Juanma. En concreto, el chip 23LCV1024, de 1Mbit. Va como un tiro :) Tengo unos 5, y los pillé para poder hacer un poco más de "retro-computing" en la Alhambra II. Viendo que están disponibles el Z80 entre otros, y que tenemos VGA y PS/2 funcionales en los bloques de la colección, no me he podido resistir a "bichear" por esa línea.

Por otra parte, hay que comentar que como máximo soportan 20MHz, pero la gama LCV permite conectar una pequeña batería de backup por si fallara la alimentación. Quizá ésta pequeña ventaja sea algo a favor con el warmboot que Juanma se está currando (por ejemplo, poniendo un condensador para asegurar la alimentación durante el re-flasheado... ¡ni idea! lo dejo a vuestra imaginación)

Para probarlos he utilizado el ejemplo 06-serial-spi-cmd de la Coleción Jedi 1.11.0. Dejo algunas fotillos:

Espero que pueda ser de ayuda. Un saludo!

Manuel

[charli va]

Muy interesante no conocía esta gama.

Yo estoy trabajando con esta:

https://lcsc.com/product-detail/RAM_Lyontek-Inc-LY68L6400SLIT_C261881.html

La voy a integrar en el hat de prototipado en el que estoy trabajando.

--


Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.


Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/8332bde9-3425-4828-8c96-fc9217970d6cn%40googlegroups.com.