Alhambra: compartir bus SPI con perféricos

[una...@gmail.com]

Estoy revisando el esquema de la versión 1.1 de la Alhambra para ver cómo podría pinchar un Arduino al SPI y programar la flash, como experimento para sustituir el FTDI. Creo que ahora mismo:

- Cuando se programa la memoria Flash, la FPGA se mantiene en reset, por lo que sus puertos SCK, SDO, SDI y SS_B se encuentran en alta impedancia o como entradas.
- Cuando se programa la FPGA, tanto esta como la memoria son esclavos. Como la memoria no está selecionada, su SDO está en alta impedancia.
- Cuando no se usa el FTDI, sus puertos SCK, MOSI y SS_B deben estar en alta impedancia, ya que de otra forma harían corto con las salidas de la FPGA cuando esta está en modo master.

Por lo tanto, con el hardware actual, debo asegurar que el Arduino tiene las salidas 10,11,12 y 13 en alta impedancia, salvo cuando esté el RESET de la FPGA activo.

Para poder realizar transferencias desde Arduino con la FPGA encendida y funcionando, debo asegurarme de que en el bitstream los pines 68, 68, 70 y 71 están configurados como entradas. Además, para que la FPGA se configure desde la flash nada más arrancar, Arduino deberá empezar en modo alta impedancia y esperar a que la FPGA termine para que sea seguro pasar a modo maestro.

Por último, como la iCE40 tiene un par de módulos SPI configurables como maestro/esclavo de forma dinámica (con buffered IO), se puede escribir en la flash indistintamente desde Arduino y la FPGA, estando ambos en funcionamiento. Para ello, hay que ser cuidadoso e implementar alguna sincronización con un pin adicional (o varios) para evitar que dos estén como maestros al mismo tiempo. En otras palabras, meter un arbitrador en la lógica.

Opcionalmente, incluir un multiplexor 8-4 (2:1 de 4 bits) externo como protección. Pero esto requeriría modificar la placa demasiado: ocho cortes y soldaduras.

La duda que me surge es si se puede añadir una resistencia entre cada maestro y el bus para que se reduzca la corriente en caso de que más de uno tenga las salidas activas (pero con diferentes valor lógico). Siendo una plataforma de desarrollo, es de esperar querer añadir más dispositivos al bus, por lo que algo así sería más seguro que cuidar la programación, y menos complicado que añadir multiplexores.

He buscado un poco al respecto y casi me explota la cabeza:

Por un lado hay referencias en las que se incluyen resistencias entre los pines SPI de la FPGA y el bus, y en caso de usar un programador externo (ICSP), se conecta en el lado de la FPGA. Cualquier periférico adicional va al otro lado. Esto se hace para que el ICSP tenga prioridad. Pero creo que no es de aplicación en este caso, ya que tanto el Arduino como el FTDI hacen las veces de ICSP.

http://electronics.stackexchange.com/questions/76415/spi-device-prevents-isp-programming

En otros casos se añaden resistencias pull-up o pull-down a los CS de los esclavos, para que no participen aún cuando la línea este en alta impedancia. A veces se hace esto además de lo anterior.

https://www.dorkbotpdx.org/blog/paul/better_spi_bus_design_in_3_steps

En ningúno de ellos se centran en posibles cortos, sino en tener prioridad en el bus. A mí no me preocupa eso, ya que prefiero que no funcione ninguno a que lo haga el principal, pero  puedan estar quemándose otros.

¿Alguien puede arrojar algo de luz sobre cuál sería la medida de protección hardware más simple?

[Eladio Delgado]

Hola de nuevo,

Como comentaba en el hilo sobre el desarrollo de la Alhambra II, me perdí este post pero recupero el tema porque es una de las mejoras que hemos hecho en la Alhambra II.

Efectivamente hay colisión en el SPI entre la FPGA y el FTDI. En la IceZUM no hay resistencias entre ambos dispositivos porque lo hicimos como estaba en la Icestick (en ésta hay resistencias pero son de 0R) ya que apenas había espacio para añadir resistencias. Ahora hemos incluido unas de 470R entre ambos integrados para que funcionen dentro del rango de corriente recomendado.

A continuación hago copy&paste de las notas que tomé durante las pruebas de la IceZUM, espero que se entienda:

Captura 11-003b: Startup config - USB_5V, iCE_SS, I_SUB:

·     El FTDI arranca con las líneas de los puertos A y B en Hi-Z

·     2 ms después, la FPGA (que ha muestreado nivel alto en iCE_SS_B) la pone a nivel bajo y comienza a leer la memoria externa.

·     unos 4 ms más tarde comienza la configuración interna del FTDI. Durante esa configuración hay un aumento del consumo debido a la colisión y al consumo interno del FTDI.

·     Durante la configuración, se puede ver que la línea iCE_SS_B pasa de 0 a 0.45V. Esto se debe a que en ese momento el FTDI configura el puerto A por defecto como UART, hasta que lea el contenido de su memoria de config. Se puede ver que domina el nivel 0 que pone la FPGA frente al uno que pone el FTDI. El valor máximo es 0.8V (p. 3-6 del DS).

·     Al configurar este puerto como UART, pasan a ser salidas los pines 16 (TXD, SCK), 18 (RTS#, MISO) y 21 (DTR#, SS). Las otras dos que son salidas en la FPGA y que podrían tener colisión son la 17 (RX, MOSI) y la 23 (DCD#, CDONE), que son entradas y no hay colisión.

·     La configuración dura unos 6 ms y todas las líneas se ponen como entradas. En la captura se puede ver que la señal iCE_SS_B vuelve a cero.

El problema de la colisión sólo ocurre una vez tras el encendido, lo que significa que cada vez que se enciende la placa y se carga bitstream, debe funcionar con colisión. En los resets posteriores el FTDI ya está configurado y no hay colisión.

Viendo que durante la colisión los niveles bajos se mantienen por debajo de 0.5V (el máximo es 0.8) parece un margen seguro.

Captura 11-011: Startup config - SYS_RESET, iCE_SS_B, I_USB - 470R vs 0R.

En cuanto a la corriente máxima en los pines, la captura 11-011 muestra un incremento de 12.5 mA. La traza M1 muestra la corriente con una resistencia de 470R en serie con el pin iCE_SS_B (traza oscura) frente a 0R. Como lo único que varía es ese pin, el incremento total de corriente se debe a ese pin. Con la resistencia de 470R ya están pasando por ese pin unos 6.5mA (3V/470R). Si añadimos los 12.5 son 20 mA, que supera los AMR del FTDI: 16 mA, p47 del DS.

Habría que añadir 470R a las líneas SCK, MISO y SS.

Un saludo,

Eladio

[1138-4EB]

Muchas, gracias por las notas, Eladio. Sólo me queda la duda de dónde está conectada la flash. Indicas que habéis incluido resistencias entre los integrados (entre el MISO del FTDI y el MISO de la FPGA). ¿El MISO de la flash está conectado en el lado del FTDI o el de la FPGA? ¿Tiene alguna importancia?

[Eladio Delgado]

Hola Unai,

Hemos puesto las resistencias de forma que la FPGA domine sobre el FTDI, ya que el FTDI no sabe que hay otro maestro en el bus y nunca se inhibe. La FPGA sí lo hace según el estado de Slave Select (SS) durante los primeros milisegundos tras el reset.

Lo del MISO / MOSI en este caso es un lío, habiendo dos maestros y uno de ellos cambiando de rol. Si intentas dilucidar lo que pasa en voz alta acaba viniendo el gato :-))

Para verlo más claro: hay sólo dos escenarios de comunicación con la flash:

1. Cuando se programa la flash desde el FTDI. En este caso, si ve lo que ocurre en el bus, la FPGA se configuraría como escavo al activarse el SS por el FTDI, pero realmente se inhibe porque el FTDI está manteniendo activa la señal de reset de la FPGA hasta que termina de programar la memoria.
2. Cuando la FPGA carga el bitstream de la flash. En este caso el FTDI (que siempre está como maestro) no sabe que esa comunicación está teniendo lugar, por lo que la FPGA debe dominar el bus.

Te pongo esa parte del esquemático para que veas cómo van las resistencias. Eléctricamente la señal que más necesita la resistencia es SS y la línea iCE_MOSI no la necesita, pero las hemos puesto en las cuatro señales porque el componente es una red de 4 resistencias:

Un saludo,
Eladio

[Juanma Rico]

¿Qué el FTDI nunca se inhibe como maestro?¿Qué pasa?¿Se cree más importante que la FPGA en el bus, o qué? ¡Cachis!
¡Un motivo más para acabar con el FTDI!... ¡Qué tío! ¡Acabemos con él! ¡Si da más problemas que otra cosa! ¡Además es caro! ¿De verdad que lo quieres mantener? jajajajajajajaja :))

Por cierto, Eladio... por curiosidad, cuando estaba investigando el FTDI (por encima,... solo lo trasteé un poco), vi que había que programarlo para que funcionara como lo hace en la placa... yo usé un único cable USB y me pareció "tedioso"...
¿Cómo hiciste esto tú con la icezum Alhambra?¿Los programaste uno a uno?¿Las casi 400 placas que hay ya?¿Antes?¿Después de soldarlos?  :(((

Un saludo
Juan Manuel Rico

[Eladio Delgado]

Hola de nuevo,

Lo que comentaba en el hilo de desarrollo de la Alhambra II, el FTDI lo seguiremos usando por ahora pero seguro que lo acabaremos quitando. No hay problemas de arbitraje de bus y es cuestión de que esté algo más maduro el tema del bootloader en la FPGA.

El FTDI se configura con la utilidad FTProg de FTDI. Se puede hacer una utilidad a medida que lo configure (con número de serie incluido) usando la librería de FTDI y configure la FPGA con el bitstream de test con un solo clic. Es una buena solución para producción porque pruebas todos los componentes implicados en la comunicación y la alimentación desde USB.

En lo que es el tiempo de producción de una placa (desde que recibes el PCB hasta que la placa está empaquetada), incluso estando el proceso bastante automatizado como lo tenemos ya, el tiempo de programación de la memoria del FTDI no es nada! :-) Y sí, lo hacemos uno a uno... para más de 800 placas que ya hemos enviado a 18 paises!! :-)) Para una producción de HW no es un número muy grande pero nosotros estamos muy contentos tanto por estar aportando nuestro grano de arena a FPGAwars como por la forma en que se ha hecho con la comunidad, y ver cómo está creciendo el interés por las FPGAs libres.

Un saludo,

Eladio

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

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

[Juanma Rico]

Buenas Eladio,

¿Más de 800 placas van ya? ¡Guau! No me imaginé que fueran tantas... le perdí la pista cuando dejásteis de "automatizar" las peticiones con la hoja excel... :)))
Me alegra ver que va tan bien la cosa... Esperaremos con paciencia a que el FTDI desaparezca... no te doy más la "turra" con él. ;))
Gracias por las respuestas a mis curiosidades... :))