Presentación y ayuda sobre como iniciar
250 views
Skip to first unread message
Gerardo Tenreiro Vazquez
May 2, 2025, 6:16:51 AMMay 2
to FPGAwars: explorando el lado libre
Hola,
primero enhorabuena por el gran trabajo que estáis realizando y el tiempo que invertís en ayudar de forma desinteresada a un gran grupo de personas.
Tengo la intención de crear un equipo en el cual interviene una FPGA ICE40HX4K (utilizo esta por ser la mas grande que puedo soldar) y un ESP32 WROOM 32 o similar.
Revisando los esquemas de la ALHAMBRA veo que utiliza un FTDI FT2232H para la carga del código por el puerto USB, en mi caso el puerto USB ira conectado al ESP32 ya que necesito este puerto para cargar también el programa al ESP32 y para la comunicación exterior.
Necesitaría algún ejemplo de como conectar la memoria SPI, la FPGA y el ESP32 así como conseguir que el ICESTUDIO lo reconozca y funcione.
Alguna Idea?
Alguna ayuda?
Muchas gracias
charli va
May 2, 2025, 6:27:59 AMMay 2
to fpga-wars-explora...@googlegroups.com
Hola Gerardo, si tu idea es utilizar el ESP32 como interfaz al mundo exterior delante de la FPGA , tendrás que preparar el firmware del esp32 para grabar los bitstreams en la FPGA.
Jesús tiene un proyecto de una placa que te puede inspirar, el utiliza otro micro pero tiene publicado el firmware y te puede valer tanto para ver el formato para grabar el bitstream como ideas muy chulas, por ejemplo Jesús genera el reloj de la FPGA desde el pll del micro por lo que puede cambiar el reloj principal de la FPGA desde el propio micro.
Los esquemáticos y el firmware lo puedes encontrar aquí https://www.ele.uva.es/~jesus/ICECREAM/index.html
Para integrarlo en icestudio, al ser algo no estándar, tendrás que primero tener el software o un api web (no sé si tu idea es hacer un programa para lanzar los bitstreams contra el esp32 por línea de comandos o si vas a montar un servidor web en el esp32 con un api para aceptar comandos via web), en cualquier caso lo primero que teines que tener es tu firmware bien cerrado y con la interfaz pública bien definida. Luego tendrás que integrarlo en Apio y después en Icestudio.
PAra el último punto es mejor que cuando tengas bien solucionada la primera parte retomes el tema de la integración de forma concreta.
Saludos!
--
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 este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/b09a187f-18e0-4945-bd0a-c1e56032b4c0n%40googlegroups.com.
Jesus Arias
May 2, 2025, 5:03:44 PMMay 2
to FPGAwars: explorando el lado libre
Hola,
En primer lugar adjunto el documento que me ha servido de referencia en mis diseños.
Las ICE40 se pueden configurar de dos modos diferentes:
- Modo SPI Master: Se necesita una memoria Flash SPI para almacenar el bitstream de configuración. Si al salir de RESET la FPGA tiene SPI_SS_B en alto se entra en este modo en el que la FPGA genera el reloj del bus SPI, manda comandos a la Flash, y lee el contenido del bitstream de configuración.
- Modo SPI Slave: Si SPI_SS_B está en bajo cuando la FPGA sale de RESET se entra en este modo y la FPGA queda a la espera de recibir el bitstream de configuración desde un dispositivo SPI maestro que suele ser un microcontrolador (en tu caso sería un ESP32)
Es interesante poder configurar la FPGA de los dos modos: el modo Slave para las pruebas durante el desarrollo de los diseños, y el modo Master para que la FPGA pueda arrancar por si misma, aunque creo que Icestudio siempre usa el modo SPI maestro (el bitstream se programa en una flash externa a la FPGA y luego se deja que la FPGA se configure sola)
En cuanto a mis diseños, además de la placa ICECREAM también tengo esta otra en la que uso una placa de programación separada (PRGICE):
Lo malo de estas placas es que NXP ya no vende el micro que tienen (el LPC1112), con lo que se impone un rediseño. El código fuente es bastante dependiente de este micro ya que el bus SPI lo he implementado por bitbanging. Eso se debió a que dependiendo del modo de configuración hay que intercambiar las funciones de los pines MISO y MOSI, y los controladores SPI hardware no permiten hacer esto, con lo que al final opté por el bitbanging (en lenguaje ensamblador ARM-thumb), que a pesar de todo me permite generar un reloj SPI de unos 6MHz
Saludos
Gerardo Tenreiro Vazquez
May 3, 2025, 12:23:01 PMMay 3
to FPGAwars: explorando el lado libre
Muchas Gracias por la información y la colaboración.
Estoy empezando a digerir información HARDWARE del proyecto de Jesús y lo primero que me encuentro es que algunos PINES de la FPGA que consideraba no conectados internamente en la FPGA Jesús los utiliza en su diseño, por ejemplo:
PIN 131(NC_19) -> Conectado a 3V3.
PIN 77(TRST_B) -> Una resistencia de 10K a GND.
PIN 40(NC_18) -> Conectado a 1V2
PIN 54(NC_17) -> Resistencia 100 a 1V2
PIN 126(NC_16) -> Resistencia 100 a 1V2
PIN 53(NC_15) -> Conectado a GND
PIN 127(NC_14) -> Conectado a GND
Sobre el USB observo que las conexiones van directamente a la FPGA, no localizo el micro en el esquema.
USBDM -> P1 al pin 1 (
PIO3_02/DP00A)
USBDP -> P2 al PIN 2 (
PIO3_03/DP00B)
En mi caso la carga a la FPGA la necesito realizar desde el ESP32 por SPI de forma que el ESP32 sea el maestro del bus. Este BUS SPI del ESP32, de la FPGA y de la memoria FLASH permitirá el micro leer y escribir no solo el bitstream sino que también tendrá que permitir la lectura de valores y ajustes.
Sobre el ESP32 entiendo que ICESTUDIO envía el bitstream de una forma determinada para poder tomarlo y remitirlo por SPI a la memoria de la FPGA.
Sobre esto hay alguna información?
Genera un fichero que se puede leer y procesar?
Observo que la memoria NOR FLASH U5 IS25LP032D-JNLE en las líneas SPI no dispone de ninguna resistencia PULL-UP ¿No seria conveniente disponer unas resistencias de 10K?
Por el momento no tengo totalmente definida la capacidad de registros de 32 bits que necesito para almacenar valores y consignas pero seguro que fácilmente alcanzo los 500 registros de 32 bits. En la documentación de la FPGA ICE40HX4K lei que dispone de varios banco de memoria que entiendo son accesible o seria conveniente disponer de una memoria SRAM para guardar las variables de proceso?
El equipo atiende a 10 canales y cada canal tendrá unas 12 variables de 32 bit, además de todos los registros que utilice en las comunicaciones.
También sobre la capacidad de 4K de instrucciones de la FPGA es algo que no tengo considerado, no tengo idea del consumo de capacidad según las parametrización.
ICESTUDIO entiendo que da una valor de la capacidad que estamos utilizando, es correcto?
Sobre el oscilador observo que la frecuencia es de 16Mhz y esta sobre el PIN21, tengo que utilizar este pin o puedo utilizar cualquier otro, es el pin que ICESTUDIO considera?
Por que 16Mhz y no 20Mhz para tener números redondos en los cálculos de frecuencia y tiempo?
Os adjunto esquema de la parte de la FPGA para que podáis comentar todo lo que veis o mejorar, este es mi primer diseño con una FPGA así que estoy realmente muy verde.
El proyecto se trata de un equipo multifunción que permite leer 20 canales analógicos de dos en dos de forma simultanea, cuenta con dos ADC de 32 bit ADS1262 , la curiosidad de este dispositivo es que los módulos de medida son enchufables y permite al operador seleccionar el modulo mas adecuado para su función, por ejemplo que estamos procesando potencia o energía lo ideal es que cada modulo mida tensión e intensidad de la misma fase para poder efectuar cálculos o registro lo mas fiel posible, si estamos sincronizando dos tensiones lo ideal es medir en el mismo modulo dos tensión de forma que la lectura se realiza sobre dos ADC de forma simultanea. también permite crear LOG de parámetros, simular señales, realizar cálculos de energía, verifica contadores y algunas funciones mas relacionadas con la generación de energía.
Espero vuestros comentarios y de nuevo muchas gracias por la ayuda y colaboración
Chao
charli va
May 3, 2025, 12:44:36 PMMay 3
to fpga-wars-explora...@googlegroups.com
Hola Gerardo, cada tarjeta tiene sus propios programadores, Jesús por ejemplo tiene uno desarrollado por él (que habla con elmicro de la icecream para mandarle el bitstream).
Tu tendrías que hacer esa aplicación que mande aal esp32 el bitstream para que el esp32 lo mande a la FPGA.
Una vez tengas esa aplicación, tendrías que integrar el programador en apio (que es lo que actualimente usa icestudio por debajo) y luego darías de alta la tarjeta en icestudio.
Es decir en todo el recorrido primero debes tener el programador de tu consola a tu micro una vez tengas eso ya andaremos las partes de la integración con apio y icestudio, es un largo recorrido y deberías plantearte esta primera etapa primero.
Icestudio es una mera capa visual no hace nada ni con el bitstream de la FPGA (esto lo hace yosys manejado a su vez por apio), toda la información de uso, consumo de recursos, etc son los generados por las herramientas de síntesis de yosys.
Sobre la memoria, depende de tus necesidas, la familia ice40 tiene unos bloques internos de memoria llamadas BRAMS, son muy rápidas, te permitirán lecturas y escrituras internas en un ciclo y son memorias de doble puerto lo uqe en muchos casos tiene un gran utilidad y potencia.
Lo único los recursos son excasos, en una ice40hx4K, tendrás las siguientes posibles combinaciones y tamaños:
4096 x 1: 4096 posiciones de 1 bit.
2048 x 2: 2048 posiciones de 2 bits.
1024 x 4: 1024 posiciones de 4 bits.
512 x 8: 512 posiciones de 8 bits. (esto sería 1BRAM del contador que aparece en icestudio)
256 x 16: 256 posiciones de 16 bits.
El tema de las brams es que tienes que calcular si con eso es suficiente para lo que quieres hacer contando que depende de tu código verilog yosys puede inferir más brams de las que tu puedes creer de inicio (para el son recursos para la síntesis y puede utilizarlas para crear diferentes estrategias).
Si vas muymuy justo o no te cabe ya directamente plantéate añadir una memoria externa, la placa de Jesús la tiene y es algo muy interesante.
Sobre los MHz del reloj, no me lo sé de memoria pero la especificación de la ice40 le permite relojes juraría que lo máximo recomandable son 133Mhz pero no me hagas caso y eso consúltalo en la documentación. Valores típicos de reloj externo son 12Mhz, 16Mhz, 25Mhz... Eso Jesús te podrá responder mejor en ala elección para su tarjeta pero entiendo que es por conformidad con el resto de chips.
Luego esta FPGA internamente tiene un par de PLLs que te permitirá tener relojes internos a mayor velocidad, eso sí tu diseño tiene que ser capaz de soportarlo.
No entiendo muy bien a lo que te refieres con los de 4k de instrucciones, creo que ahí tienes algún concepto erróneo. Los 4k se refiere a las unidades lógicas que dispone la FPGA que es con lo qeu se reconfigura para sintetizar tu circuito, no tiene nada que ver con instrucciones, no es un procesador, no sé si esto te aclara algo, solo intento darte una pista para que busques información por ahí hacia lo que necesites.
El proyecto suena interesante, vete contándonos los progresos!
Jesus Arias
May 3, 2025, 5:55:33 PMMay 3
to FPGAwars: explorando el lado libre
Hola de nuevo,
En primer lugar pido disculpas por la poca claridad de mis esquemáticos. Los pines que mencionas son para un modelo de FPGA distinto, la ICE40HX1K, que era el chip para el que había diseñado inicialmente la placa ICECREAM. Pero entonces Obijuan me sugirió usar una ICE40HX4K, que tiene un pinout un poco diferente. Así que conecté los pines que faltaban en el esquemático (que sigue siendo para una HX1K) y por ello quedó un tanto lioso. Luego importé el esquemático a la placa SIMRETRO y las dos quedaron igual de embrolladas. (aunque el cambio a la HX4k fue una excelente idea, porque la HX1k se queda pequeña enseguida)
En la placa SIMRETRO, el USB lo estoy usando sólo como entrada de alimentación. Aunque también conecté los cables de datos del USB a pines de la FPGA casi nunca han tenido uso, y desde luego nunca se usan para configurar la FPGA. La configuración se hace a través del conector J2 que contiene las señales del bus SPI de la FPGA / Flash, además de las señales de RESET y DONE.
El archivo bistream lo generan las aplicaciones "yosys" y "nextpnr", que son parte de la toolchain que instala Icestudio. Es un archivo binario, de unos 130Kbytes que hay que grabar al comienzo de la memoria flash (si la FPGA se configura en modo SPI-master). En placas como ICESTICK o Alhambra el chip FT2232 proporciona una interfaz PC - bus SPI que permite a Icestudio grabar la memoria Flash de manera que luego simplemente se libera el RESET de la FPGA y ella sola lee la flash y se configura.
Para cargar el bitstream en la Flash (o directamente en la FPGA en modo SPI-slave) se necesita una aplicación en el PC. Las placas con el chip FT2232 utilizan "iceprog" (está en la toolchain) y tienen un soporte directo en Icestudio. En mis diseños no utilizo el FT2232 y por ello he tenido que desarrollar mi propia aplicación para la programación. En tu caso la aplicación equivalente deberá correr en el ESP32.
Observa que si la FPGA la vas a configurar siempre desde el ESP32 no necesitas para nada la memoria flash ya que puedes recurrir al modo SPI-slave. Y el código es bastante simple: Se ponen SS y RESET en bajo y luego Reset en alto. Con esto la FPGA arranca como SPI-slave después de un retardo tras el que SS se puede poner en alto. Luego desde tu micro transmites un byte dummy, todos los bytes del archivo bitstream, y continúas dando pulsos de reloj hasta que DONE se ponga en alto. Para terminar se mandan 49 pulsos de reloj adicionales, y la FPGA ya ha arrancado.
Los pull-ups en el BUS SPI no son indispensables, aunque tampoco pasa nada por ponerlos, cosa que puede ser recomendable si se quieren tener estados de muy bajo consumo. (las entradas flotantes pueden ocasionar consumos de corriente apreciables)
En la ICE40HX4K dispones de un total de 16KBytes de memoria repartidos en 32 BRAMs.
Además el total de celdas lógicas es de 7680, no las ~3500 que dice Lattice en sus datasheets. (en realidad la ICE40HX4K es una HX8K en un encapsulado de 144 pines en lugar de BGA aunque desde Lattice nos la quieran vender como un modelo con menos capacidad de la que realmente tiene)
El reloj no es imprescindible que esté en el pin 21 (la Alhambra lo tiene en el pin 49), aunque es recomendable que esté en alguno de los 8 pines GBIN (buses globales que dentro de la FPGA van a todas partes) La frecuencia del reloj se puede elegir, 12MHz es bastante habitual, aunque yo elegí 16MHz precisamente porque cuando se conecta un PLL se pueden generar frecuencias "redondas" ;).
Saludos y suerte con el proyecto
charli va
May 4, 2025, 2:34:07 AMMay 4
to fpga-wars-explora...@googlegroups.com
Gracias Jesús por la explicación tan detallada!
Gerardo Tenreiro Vazquez
May 4, 2025, 7:03:59 AMMay 4
to FPGAwars: explorando el lado libre
Muchísimas gracias por la explicación
Referente al archivo bistream entiendo que lo recuperas de algún directorio después de sintetizar con ICESTUDIO, me puede decir donde localizar el fichero y como se llama?
Referente a los esquemas no te preocupes nos pasa a todos muchas veces.
Referente al archivo bistream entiendo que lo recuperas de algún directorio después de sintetizar con ICESTUDIO, me puede decir donde localizar el fichero y como se llama?
Así puedo empezar crear la aplicación que lo envié al ESP32 o lo suba al servidor. La idea es disponer de la actualización de software y hardware en el servidor y que el ESP32 pueda descargar los ficheros y el bistream lo envié a la FPGA siguiendo tu detallada explicación.
Me voy a decantar por dejar una memoria FLASH en el BUS SPI que una al ESP32 como maestro y a la FPGA como esclava, esta memoria FLASH almacenara el bistream al inicio por si en el futuro opto por otro tipo de configuración y la FPGA puede arrancar directamente desde le memoria FLASH, además el ESP32 puede almacenar en esta memoria algunos valores de configuración o futuros ajustes.
El ESP32 dispone de las siguientes líneas a la FPGA y memoria FLASH. son las mismas que están el conector J2 del esquema. Según tu descripción son las necesarias para grabar el el FPGA el bistream y al mismo tiempo puedo grabar el la memoria FLASH.
FPGA -> 66 -> CRESET_B
FPGA -> 65 -> CDONE
FPGA -> 67 -> IOT_44_SDO
FPGA -> 68 -> IOT_45_SDI
FPGA -> 70 -> IOT_46_CLK
FPGA -> 71 -> IOT_47_SS
Referente al USB aun tengo muchas dudas, la idea es que lo procese directamente el ESP32 pero dado que no tengo experiencia con la FPGA estoy valorando dejar el FTDI en la placa de la FPGA, esto me permitirá directamente desde ICESTUDIO grabar la memoria y poder iniciar las pruebas y mi aprendizaje de la misma.
He enviado el correo de solicitud de una ALHAMBRA II a la pagina "https://alhambrabits.com/buy/" pero nunca me han contestado.
Referente al FTDI hay una memoria EEPROM, en concreto la U4, que entiendo que necesita un firmware que no se de donde descargar. Esto y que el FTDI ocupa bastante y es caro fue lo que me decanto a intentar que el ESP32 sea el encargado de grabar el bistream
Este punto del USB como podéis ver los tengo muy verde y aun estoy indeciso de por donde ir, no me agrada la idea de utilizar el FTDI pero para iniciar tampoco tengo la confianza de no usarlo. Que me aconsejáis?
La decisión de utilizar la ICEHX4K fue por el formato TQ144, Yo con el formato BGA tengo problemas de utilización, me cuesta mucho trabajar con el formato, Ya es de una época mucho mas moderna que Yo, así que el TQ144 me pareció correcto, ahora que me indicas que la capacidad es la misma que las 8K ya no me queda ninguna duda.
Referente a la capacidad tengo varias dudas al respecto. como comente en mi proyecto tengo 20 canales de medida que se leen por medio de dos ADC, la idea es que la FPGA lea los dos ADC de forma simultanea a una frecuencia de 10Khz aproximadamente, Tiene que leer de cada canal la tabla de calibración de una memoria FLASH y realizar los cálculos según la lectura, la tabla de calibración y la temperatura que lee de cada modulo por I2C, esta claro que la temperatura la leerá cada 5 segundos aproximadamente, Como puede ver la FPGA tiene un BUS SPI para los dos ADC, otro Bus SPI para las memoria de calibración y 10 Buses I2C para cada uno de los módulos de medida. Realmente cada modulo de medida dispone de 5 GPIO de la FPGA que según el modelo de modulo de medida se utilizaran de una u otra forma.
Los bloques son repetitivos, todos los módulos se procesan igual con la diferencia de la tabla de calibración y el resultado del conversor ADC.
Las operaciones de calculo son con numero enteros, trabajo con los valores X10000 para disponer de 5 decimales en vez de operar en coma flotante que entiendo le costara mucho mas a la FPGA, sobre esto también tengo que realizar pruebas y ver cual es la forma correcta y optimizada de operar.
De cada uno de los canales (20) se dispone una señal digital que indica cuando la medida es mayor que cero de forma que tengo que contar impulsos y determinar la frecuencia, el ancho de pulso para determinar el % de onda y la diferencia de tiempo con la señal del mismo canal para determinar el factor de potencia o el coseno, desfase ...
¿Alguien tiene una idea de lo que puede ocupar esto en celdas lógicas?
¿Me llegaran los 4K/8K?
Referente al Reloj en el PIN 21 entiendo que cada uno lo pone donde le interesa dentro de los pines GBIN, tendré alguna ventaja utilizando el PIN 49 con ICESTUDIO o ¿es configurable para ICESTUDIO?
Mi intención es utilizar ICESTUDIO para generar toda la parametrización de la FPGA, trastee un poco con el programa y le veo muchas posibilidades, además es cómodo, practico y libre. Que mas le podemos pedir. Tendré que adaptarme en lo posible por eso os realizo la consulta, estoy en fase de diseño así que por ahora podemos cambiar todo y adecuarlo.
Referente al SPI que leerá las memorias de calibración entiendo que no hay pines preferentes a esta función o si?
actualmente este bus esta definido según esta lista:
FPGA. -> 144 -> IOT96 -> MOSI
FPGA. -> 143 -> IOT95 -> MISO
FPGA. -> 142 -> IOT94 -> CLK
FPGA. -> 141 -> IOT93 -> CS Modulo 0
FPGA. -> 139 -> IOT92 -> CS Modulo 1
FPGA. -> 138 -> IOT91 -> CS Modulo 2
FPGA. -> 137 -> IOT90 -> CS Modulo 3
FPGA. -> 136 -> IOT89 -> CS Modulo 4
FPGA. -> 135 -> IOT88 -> CS Modulo 5
FPGA. -> 134 -> IOT87 -> CS Modulo 6
FPGA. -> 128 -> IOT84 GBIN0 -> CS Modulo 7
FPGA. -> 129 -> IOT85 GBIN1-> CS Modulo 8
FPGA. -> 122 -> IOT83 -> CS Modulo 9
¿Seria mejor tener el SPI(MOSI,MISO,CLK) en PINES GBIN?
Os adjunto algunas imágenes de equipo con los módulos de medida, sin el display, sin batería, tapa inferior ni la placa del ESP32, la PCB de la FPGA es la que va en el interior en vertical.
La PCB de la FPGA esta muy justa de espacio por lo que intentare disponer el menor numero de dispositivos.
Muchas gracias y mas que suerte mucha colaboración de este gran grupo.
charli va
May 4, 2025, 10:58:37 AMMay 4
to fpga-wars-explora...@googlegroups.com
Hoa Gerardo! proyecto interesante! y gracias por compartir tu documentación, siempre se agradece y aprendemos unos de otros.
Sobre el bitstream, en icestudio cuando sintetizas o haces el "build" verás que en el mismo directorio donde tienes el .ice se crea un directorio ice-build, dentro de este directorio encontrarás todos los ficheros generados incluido el bitstream.
Sobre el pin del reloj, cuando integres la tarjeta en apio y en icestudio, generarás un fichero .pcf en el que se define la configuración de los pines de tu tarjeta en cuanto a la FPGA, ahí indicarás, pues uso el pin XX para el CLK, etc.
Para la lectura de tu memoria flash externa con los datos de calibración, puedes utilizar cualquiera de lo spines de entrada salida generales, no hay pines específicos para spi genéricos. En los micros que tienen pines específicos SPI es porque hay una parte del micro encargada de realizar esta función, en la FPGA como quien dice está todo "por reconfigurar" con las funciones que tu quieras.
En cuanto a las LCs estimadas es muy difícil de decir ya que en verilog dependiendo tu habilidad y conocimientos cambiando un if puede hacer que el diseño se desboque en consumo de puertas lógicas o al revés sea ultra óptimo. Por lo que cuentas tendrás que intentar hilar muy fino porque estas FPGAs no tienen dsps así que todas las operaciones de multiplicación , división etc, son muy costosas en cuanto a recursos.
A parte de los LCs, tienes que tener en cuenta que si quieres operar con senos y cosenos tendrás que contar con las brams que necesites para tener tablas precalculadas que en función de la resolución que quieras te ocuparán más o menos espacio de brams, pero a bote pronto yo calcularía que algo más de la mitad de las BRAMs se te van a ir en las tablas de senos y cosenos, bufffers para el ADC y alguna cosa más así que se vea claro. Sobre la implementación al ser 20 canales vas a tener que ser muy cuidadoso porque como te digo al no tener DSPs, en cuanto empieces a meter operaciones para el análisis de pulsos (contador de frecuencias , medir ancho de pulso y desfase) ahí se te van a ir muchos recursos, igual se te va media FPGA, puede que me esté equivocando, como te digo esto es difícil de estimar a ojo pero me suena que esa parte va a ser costosa.
Es probable que vayas muy al límite (hablando siempre de los 8k, en la de 4k creo que sería inviable) , como te digo tendrás que ser muy fino.
Buena tarde de Domingo!
Eladio Delgado
May 4, 2025, 12:02:04 PMMay 4
to fpga-wars-explora...@googlegroups.com
Hola Gerardo,
Comentas en tu último post que has pedido la Alhambra II pero no has recibido respuesta. No sé si ha podido haber algún fallo puntual pero no nos ha llegado, disculpa las molestias. Si sigues interesado puedes probar de nuevo o contactarnos directamente en ad...@alhambrabits.com
Muchas gracias por compartir este proyecto!!
Un saludo,
Eladio
Gerardo Tenreiro Vazquez
May 4, 2025, 12:08:43 PMMay 4
to fpga-wars-explora...@googlegroups.com
Hola Eladio,
Si envie mas de veces la solicitud desde la pagina y no he tenido respuesta, si puedes revisar el correo que utrilice es este mismo gtv...@gmail.com
Voy a intentarlo ahora mismo a ver si hay respuesta.
Muchas Gracias
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/vDLFxwM9YDM/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAJXdXgRD-O9QPGPYfgsrWYWd93i4vV_eLNRBL%2BuH14ezXPavbA%40mail.gmail.com.
email...@gmail.com
May 4, 2025, 5:29:22 PMMay 4
to FPGAwars: explorando el lado libre
Hola Gerardo,
Sigue sin llegarnos, no sé qué puede ser y puede que le esté pasando a más personas. Lo vamos a mirar. Hablamos por privado y lo solucionamos.
Gracias a ti y un saludo,
Eladio
Jesus Arias
May 5, 2025, 6:35:52 AMMay 5
to FPGAwars: explorando el lado libre
Hola, Gerardo
Respecto del FT2232 realmente es un incordio, pero puede venir muy bien para poder programar tu placa con el software "standard" (iceprog / Icestudio). Una solución de compromiso podría ser poner un conector de programación en la placa con la FPGA y conectar en él otra placa con el FT2232 , más o menos como hice con las placas SIMRETRO / PRGICE pero usando una placa de programación con FT2232, por ejemplo:
En cuanto a la cantidad de recursos (celdas lógicas + BRAMs) que vas a necesitar es algo que resulta muy complicado de estimar. En buena medida depende de si el procesamiento de los datos va a necesitar multiplicaciones. Quiero resaltar que la FPGA no es como un micro en el que se corre un programa (para eso el ESP32 le da mil vueltas) sino más bien como una tabla de prototipos en la que enchufamos circuitos digitales simples. Por supuesto que alguno de esos bloques podría ser un microprocesador. Por tener una estimación de los recursos te digo lo que ocupan aproximadamente algunos de estos "cores":
6502: 760 celdas lógicas ("Arlet Ottens core")
Z80: 2200 celdas lógicas ("tv80")
68000: 4800 celdas lógicas ("fx68k")
RiscV: 2700 celdas lógicas ("Larva", RV32E, sin multiplicación)
Otros cores que he diseñado (GUS16, BAC): http://www.ele.uva.es/~jesus/
Respecto de la asignación de pines a priori puede ser casi cualquiera, ya se encargará "nextpnr" del routing interno. Y el bus SPI de configuración, (pines 67 a 71) también se puede reusar una vez configurada la FPGA, con lo que la misma flash que contiene el bitstream puede almacenar otros datos útiles en direcciones más altas, por ejemplo los datos de calibración que mencionabas.
Saludos
Jesus Arias
May 5, 2025, 9:47:03 AMMay 5
to FPGAwars: explorando el lado libre
Perdón por la referencia a la placa "Deosdum". No tiene el chip adecuado, debería tener un FT2232
Esta otra parece que sí lo tiene (claro que es bastante más cara):
charli va
May 5, 2025, 10:02:38 AMMay 5
to fpga-wars-explora...@googlegroups.com
Yo tengo esta que la suelo usar para programar algunas colorlight https://es.aliexpress.com/item/1005002448969402.html?spm=a2g0o.order_list.order_list_main.120.5f90194dR7rTc2&gatewayAdapt=glo2esp
Va muy bien.
Gerardo Tenreiro Vazquez
May 5, 2025, 10:55:40 AMMay 5
to FPGAwars: explorando el lado libre
Hola, en encanto de la participación, cuantos mas opinen mejor.
Os respondo por puntos.
Primero: Conseguí pedir una ALHAMBRA II gracias a Eladio, así podre realizar las primeras pruebas, hacer estimaciones y empezar a aprender el funcionamiento y uso de la FPGA.
Segundo: El numero de pines que utilizo de la FPGA es la totalidad, así que no tengo capacidad de ampliar, de echo modifique el esquema con un DECODER 4:16 para el CS de las memorias de calibración del Bus SPI.
Necesito dos bus SPI, uno el de arranque que lee la memoria FLASH y comunica con el ESP32, este bus es el que esta en los pines 67,68 y 70 y otro que es el que lee las memorias de calibración, los ADC y algunos dispositivos internos del equipo para la gestión de consumos, batería, pulsador de arranque, etc. esta en los pines 142,143 y 144.
Ambos buses funcionan de forma independiente y cada uno tiene su propia gestión, el BUS. el ESP32 puede estar leyendo información de la FPGA y la FPGA puede estar leyendo un ADC por ejemplo.
Por el momento mantengo el esquema con el ESP32 según lo tenia y veré la posibilidad de que el fichero generado por ICESTUDIO se pueda enviar por algún sistema al ESP32. Los ESP32 disponen de una gran memoria FLASH interna (en mi caso 16MB) y un gestión de archivos, así que el ESP32 puede guardar temporalmente el fichero de la FPGA y después realizar el volcado.
Tercero: Si necesito hacer operaciones matemáticas en 32 bit con enteros, suma, resta, multiplicación y división .Entiendo que será posible pero en cuanto tenga la ALHAMBRA II empezare a realizar este tipo de pruebas y ver lo que ocupan las operaciones y empezar a realizar pruebas. Sobre operaciones matemáticas en 32 bit hay alguna librería o información?
Cuarto: Referente a la capacidad de celdas veo que es difícil de calcular, así que será a base de ir incrementando bloques e ir viendo a donde llego.
Os iré informando y dejando el código para ver si podemos conseguir que entre todo en la FPGA.
Creo que seria bueno conseguir que ICESTUDIO pudiera enviar por puerto serie el fichero, no solo para esta proyecto sino para el futuro avance del desarrollo con FPGA.
Esta claro que antes de correr hay que andar y el gran paso de ICESTUDIO que nos permite pensar en crear proyectos con FPGA es increíble, pero como todo hay que seguir avanzando y popularizando lo mas posible. ¿Qué opináis?
Se que estoy empezando y que mi proyecto no es pequeño, lo se por que a creado otro equipo similar realizado con tres micros(dos DSPIC y un PIC32) y se lo que le cuesta a los procesadores llevar a cabo su trabajo. sobre todo la gestión de tiempos e interrupciones. En este caso con la FPGA la gestión de las interrupciones me lo evitare y seguro que me será mas fácil conseguir sincronismos de señales y tiempos.
Muchísimas gracias y como siempre estoy esperando vuestro comentarios.
Democrito
May 5, 2025, 1:40:04 PMMay 5
to FPGAwars: explorando el lado libre
Hola Gerardo:
Sobre la parte matemática te dejaré enlaces de trabajos que hice en su momento. No tengo multiplicadores, pero sí otros módulos matemáticos. Quizás alguno pueda ser de tu interés.
Te recomiendo que si tu FPGA contiene un micro como el ESP32 lo uses como, si de un chip matemático se tratase, de esta forma te librarás de mucho espacio en la FPGA, especialmente para los conversores de formato que es lo más pesado.
Todos vienen con ejemplos donde la entrada y la salida se hace a través del terminal serie. Los conversores de formato (de humano a binario y de binario a humano) es la parte más pesada del circuito, en este sentido el módulo que realiza el cálculo es una fracción pequeña del total.
Por lo general, si vas a probar los ejemplos, en el terminal serie has de meter un valor y pulsar enter, y luego otro y le das al enter, y obtendrás el resultado.
Esto es un ejemplo para introducir datos desde el terminal serie de Icestudio utilizando el ejemplo de división en punto fijo.
Para terminar decir que le des directamente a subir, si verificas te dará errores, por el tema de que a partir de cierta versión estamos obligados a usar asignaciones de registros a las salidas físicas, pero Yosys lo sintetiza sin problemas.
Saludos.
División entera: https://github.com/Democrito/repositorios/tree/master/Maths/div_uint
División en punto fijo: https://github.com/Democrito/repositorios/tree/master/Maths/div_fix_point
El algoritmo que usé contiene un "bug" y ocurre cuando el divisor es "0.algo", por ejemplo: "1 / 0.001". Trata de aproximar el resultado, pero en según que casos no es satisfactorio. Si sabes que nunca vas a usar 1 partido por algo (excepto 1), puedes usarlo con tranquilidad. Y para esos casos puedes usar el siguiente que pongo.Inverso de un número entero: https://github.com/Democrito/repositorios/tree/master/Maths/inverse
Logaritmos (log2, ln y log10) en punto fijo: https://github.com/Democrito/repositorios/tree/master/Maths/logarithms
Raíces cuadradas en punto fijo: https://github.com/Democrito/repositorios/tree/master/Maths/sqrt/Fix_Point
Atan2 en punto fijo: https://github.com/Democrito/repositorios/tree/master/Maths/trigonometric/atan2
Inverso de seno y coseno en punto fijo: https://github.com/Democrito/repositorios/tree/master/Maths/trigonometric/inverse_sin_cos
Seno y coseno en punto fijo: https://github.com/Democrito/repositorios/tree/master/Maths/trigonometric/sin_cos
Por otra te dejo con un conversor binario a BCD (16 y 32 bits): https://github.com/Democrito/repositorios/tree/master/Maths/Bin_to_BCD
Y aquí te dejo con conversores de puerto serie a binario y de binario a serie y también para punto fijo:
Binarios int32 y Uint32 a serial: https://github.com/Democrito/repositorios/tree/master/Binary_to_Serial
Serial a binario con y sin signo: https://github.com/Democrito/repositorios/tree/master/Serial2Binary
Otros conversores: https://github.com/Democrito/repositorios/tree/master/Serial_Maths
charli va
May 5, 2025, 1:44:45 PMMay 5
to fpga-wars-explora...@googlegroups.com
Que gran aportación Demócrito! y la idea de usar el micro como coprocesador matemático es muy buena.
--
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.
Gerardo Tenreiro Vazquez
May 5, 2025, 4:43:34 PMMay 5
to FPGAwars: explorando el lado libre
Muchas Gracias por las aportaciones las probare e intentare reutilizar todo lo que pueda para el proyecto.
La idea de utilizar el ESP32 como procesador matemático es buena pero no es viable en este caso, la lectura de los canales de medida (20) se efectúa de forma asíncrona entre ellos y de forma síncrona entre la pareja de canales (Tensión e Intensidad), por eso dispongo dos conversores ADC .
La idea es leer 1000 veces por segundo cada ADC y el ESP32 no tiene capacidad de operar a esa velocidad.
La FPGA lee el resultado de la conversión en formato de 32 Bit con signo directamente del ADC1262, lee el valor de multiplicación del canal según la temperatura leída de la memoria de calibración del modulo, todos los números están en formato entero de 32 bit. El resultado lo deposita directamente en el memoria SRAM.
El ESP32 cada 250ms realiza la media de las lectura(las que se depositaron en la SRAM) y toma el valor como valido y realiza los cálculos matemáticos de verdad, potencia, energía, factor de potencia y demás.
Se que es fácil escribirlo pero dará mucho trabajo llegar al final,
Pero cuento con vuestra colaboración.
Muchas Gracias
Democrito
May 5, 2025, 7:56:52 PMMay 5
to FPGAwars: explorando el lado libre
Te paso un truco que se aplica para medir frecuencia a partir de un pulso, quizás sea aplicable dentro de tus matemáticas, que no lo sé porque no estoy metido en tu proyecto, pero por si encuentras alguna "inspiración". Seguramente este tipo de trucos ya lo conoces. Se trata de solucionar un problema concreto con números enteros, que son los más fáciles de trabajar.
Jesus Arias
May 6, 2025, 6:41:04 AMMay 6
to FPGAwars: explorando el lado libre
Hola de nuevo
He mirado un poco el datasheet del ADC porque 32 bits me parecían una exageración, y realmente si nos fijamos en la tabla 8.2 vemos que el número efectivo de bits es de unos 22. Esto significa que los 10 bits LSB de los datos van a ser puro ruido y se podrían ignorar, lo que nos deja unas variables de 22 bits en lugar de 32.
Y luego el procesamiento supone según nos dices una multiplicación por cada uno de los 20 datos, lo que serían 20000 multiplicaciones por segundo. Esto parece asumible, ya que incluso con un multiplicador secuencial que emplee 32 sumas por cada multiplicación el reloj se queda en 640kHz, mientras que fácilmente se podrían conseguir relojes de unos 20MHz.
Y si reducimos el ancho de las variables a 24 bits incluso se podría usar un multiplicador combinacional similar al que tenía en mi máquina de Mandelbrot:(https://www.ele.uva.es/~jesus/SIMRETRO/mandelmachine.pdf), que podría hacer 20 millones de multiplicaciones de 24 bits por segundo a cambio de unas 1500 celdas lógicas.
Saludos
El lunes, 5 de mayo de 2025 a las 22:43:34 UTC+2, gtv...@gmail.com escribió:
Democrito
May 6, 2025, 7:10:03 AMMay 6
to FPGAwars: explorando el lado libre
Me hizo gracia la línea final del PDF.
<<
Year 2 AC (After COVID)
>>
Lo cierto es que fue un antes y un después.
Gerardo Tenreiro Vazquez
May 6, 2025, 8:19:34 AMMay 6
to FPGAwars: explorando el lado libre
Hola grupo,
Mirare lo del multiplicador combinacional en cuanto tenga una ALHAMBRA II disponible, pero por el momento vamos a comentar la resolución del ADS1262 y el numero de bit para las operaciones matemáticas.
Jesús referente al numero efectivo de bits de la tabla 8.2 comentar que la tabla indica el numero de bit libres de ruido, eso lo cumple como mínimo el ADS1262 y como bien sabes los fabricantes(sobre todo los Americanos y Europeos) siempre ponen en la documentación los mínimos que aseguran cumplir, no significa que el resto de bits los podamos descartar, son lecturas con ruido y valores correctos por eso realizo la media cada 250ms y el valor resultante como dije es la media de los 250ms del valor + el ruido.
Si descarto a 22 bit no puedo alcanzar las resolución necesaria en el equipo, con los valores hay que hacer mucha matemática en el ESP32 para que lo entregado por la FPGA sea lo real.
Este integrado ya lo tengo usado en otro equipo y con 1000 muestras por segundo la resolución se acerca los 25 bit, tener en cuenta que el equipo no dispone de unas gamas de medida externas como un multímetro que le permita seleccionar un rango de medida, es un equipo de gama automática completa pero que siempre lee toda la gama, bueno menos para pequeñas medidas que utiliza la FPGA del ADS1262, que sinceramente siempre me funciono perfectamente.
Ya comente que cada 250ms es la toma real del dato, los otros valores se promedian.
El ruido, las temperaturas y las alimentaciones son claves en el equipo. Para ciertas medidas el equipo se desconecta de la alimentación y solo opera con su batería interna para eliminar el rizado de la red eléctrica y del cargador de batería. Fijaros en el esquema la cantidad de condensadores de filtrado que hay.
Mi intención es entregar valores con 4 decimales reales, esta claro que con 32 bit del ADC podría intentar ir a 6 o 7 dígitos decimales en algunas medidas, pero mi experiencia me demostró que llegar a 0,00001 V ya es muy difícil. Claro si tenemos en cuenta que después calculamos por ejemplo potencia o integramos energía nos damos cuenta que la perdida de decimales genera error de calculo importantes.
Como os comente cada modulo de medida dispone de dos sensores de temperatura, uno en el divisor resistivo de tensión y otro en el shunt de intensidad. También cada modulo dispone de una memoria EEPROM con los datos de calibración de cada modulo a diferentes temperaturas. Este valor es el que utilizara la FPGA para multiplicar por la lectura del ADC y conseguir el valor de la medida que aun así se integra para conseguir una media.
La calibración de los módulos la realizo en una cámara climática de -10 a +60ºC, los módulos de medida están dentro de la cámara durante una semana aproximadamente realizando medidas de tensiones e intensidades contrastadas a las diferentes temperatura y valores de todo su rango, los valores de cada modulo se guardan en sus memorias de calibración. este proceso es una de las partes mas importantes del proceso. Esto se realiza de forma automática con un PC, un equipo de calibración y una estación climática controlada por el mismo PC. Obviamente todo dentro de una jaula de Faraday.
Una vez terminado el proceso los módulos se sellan en resina de ciertas cualidades dieléctricas y térmicas, esta resina es otra de las partes importantes de proceso, esto me genero muchas pruebas y errores por humedad, condensaciones y calentamientos.
La versión anterior del equipo cumple con la clase 0,02 , esto se integra dentro de los equipos de laboratorio. La intención es que este nuevo diseño este en la clase 0.001, es lo máximo que puedo intentar alcanzar con mis medios y mi conocimientos actuales.
Se que el proyecto suena difícil y complicado pero realmente es mas difícil y complicado de lo que parece. Si alguien necesita mas información referente no dudéis en comentarlo y os la facilitare
Muchísimas gracias por el interés que estay demostrando y el gran grupo de ayuda.
No os preocupéis por que termine rápido el proyecto, estoy seguro que en el 2026 aun no estará termina y seguiré dándole muchas vueltas a todo y comentándolo con vosotros.
Gracias
charli va
May 6, 2025, 9:03:43 AMMay 6
to fpga-wars-explora...@googlegroups.com
Una joya Jesús, tu Mandelbrot machine, un artefacto que siempre me ha cautivado. Lo veré con calma, suena prometedor.
Sobre tu proyecto Gerardo ya nos contarás, suena interesante, creo que Jesús no se refería a que tomaras 22 bits en lugar de los 32 sino que al no tener precisión para garantizar los datos en los 10 LSBs te puedes ahorrar esos bits para los cálculos. , en la FPGA cada bit cuenta! En el documento que ha aportado Jesús de su Mandelbrot machine se explica muy bien el concepto de la resolución y el número de bits (aplicado en el zoom en el caso del fractal) , esto es un cambio de mentalidad importante, en el software todo tiende a ser "infinito" y más en los tiempos abstractos de hoy en día pero en la FPGA te encuentras de bruces con los límites físicos y aprovechar cada bit es fundamental.
Saludos!
Jesus Arias
May 6, 2025, 9:26:19 AMMay 6
to FPGAwars: explorando el lado libre
Hola Gerardo,
Realmente me había llamado la atención la enorme resolución de este ADC. 22 bits efectivos a grandes rasgos significan que el error del ADC es 4 millones de veces menor que una señal que llene el fondo de escala. Lógicamente cualquier imperfección analógica va a tener en comparación un peso importante y hay que minimizarla.
En cuanto al multiplicador del ejemplo del Mandelbrot es de sólo 24 bits (en formato fraccionario 5.19), y lo malo es que en este bloque el número de celdas lógicas crece con el cuadrado del número de bits, con lo que una versión de 32 bits va a ocupar no poca FPGA. Pero no se necesita mucha velocidad, de modo que creo que sería mejor hacer una versión secuencial, con sumas y desplazamientos, que va a necesitar muchísimas menos celdas lógicas aunque tarde 32 ciclos en multiplicar.
De todos modos te adjunto el código un posible multiplicador combinacional de anchura de palabra configurable (formato: 1.DW-1). Para variables de 27 bits ocupa 1666 celdas lógicas (no he podido probar con más bits porque me he quedado corto de pines en la FPGA para rutar todas las entradas y salidas ;) Escalando por (32/27)^2 con 32 bits serían unas 2400 LCs, y el retardo máximo unos 40ns... Mi idea era usar este multiplicador con los datos de un ADC de 10 bits y 65 MS/s, pensando en aplicaciones de software-radio.
Saludos y espero que tengas pronto tu Alhambra para empezar a probar las ideas
charli va
May 6, 2025, 12:31:02 PMMay 6
to fpga-wars-explora...@googlegroups.com
Hola Jesús, super interesante el tema de SDR que planeas, ya nos contarás, yo ando pendiente de que me llegue algo de material para probar tu experimento de AM y aprovechar a poner en marcha algunas ideas en este marco, ya nos contarás!
Por otro lado me asusto a veces de como confluyen las ideas por aquí XD, ando justo haciendo unos temas con la OLED con Demócrito y estaba preparando también un tema de punto fijo así que tu algoritmo me va a venir de perlas.
Tenía preparado un testbench para probar lo que estaba haciendo así que lo acabo de ajustar para meter tus dos multiplicadores (el de mandelbrot y el que acabas de pasar), de forma que se puedan comparar entre ellos y con el valor teórico real y a no ser que haya entendido algo mal de la propuesta creo que hay un error en el código en los desplazamientos de los productos parciales, o a lo mejor como te digo, no lo he entenido bien (lo he tomado y he querido intuir que planteabas por ejemplo en 16 bits lo mismo que en fmut 4 para la parte entera 1 signo y 11 fraccionaria).
Esta es la salida original de la comparativa, como veis hay una desviación de los bits en fmul (desplazados a la derecha), suponiendo la organización 1+4+11, para las pruebas he llamado fmut al multiplicador de Mandelbrot y fmul al último qu eha lanzado Jesús:
Y esta es con la propuesta de corrección que se me ha ocurrido, posiblemente sea mejorable, pero ahora en principio ya cuadra la salida de los dos multiplicadores, al ser la función genérica he añadido un parámetro adicional para poder seleccionar cuantos bits serán para la parte fraccionaria. y los resultados ahora salen tal cual:
Os paso por si os viene bien el código original, el código adaptado/corregido, el de mandelbrot, el testbench y el makefile. El testbench lo que hace es multiplicar varios casos límite para ver si funciona en casos típicos del rango.
Los meteremos pronto en bloques para Icestudio ;)
¡Buena tarde!
Jesus Arias
May 6, 2025, 4:44:14 PMMay 6
to FPGAwars: explorando el lado libre
Hola Carlos,
El multiplicador era distinto por el formato de los datos, con sólo un bit en la parte entera (el del signo) en lugar de 5.
Pero si ahora el número de bits de la parte fraccional es un parámetero pues mucho mejor!
Saludos
charli va
May 6, 2025, 5:11:55 PMMay 6
to fpga-wars-explora...@googlegroups.com
XD me imaginé que algo no estaba entendiendo bien, pero no conseguí entender así así a bote pronto como habías repartido los bits, en cualquier caso me ha parecido un código interesante y solo he tenido que hacer un leve cambio para parametrizarlo. Me he obsesionado con Mandelbrot y pensé que era el equivalente y me obcequé XD
Bueno al menos espero que sea útil
charli va
May 6, 2025, 7:46:57 PMMay 6
to fpga-wars-explora...@googlegroups.com
Os adjunto un nuevo multiplicador, en este caso un multiplicador de Booth radix-4 . Es en el que estaba trabajando cuando Jesús envío lo de Manderlbrot y me ha complicado la vida XD (gracias Jesús) por intentar generalizarlo para tener así los tres ejemplos (mañana generalizaré el de Manderlbrot por tenerlos los tres parametrizados ) y así poder hacer algunas pruebas comparativas que siempre son super interesantes.
Además es divertido porque con estos tres multiplicadores tenemos casi "una escala evolutiva".
Para el que no lo conozca Booth en los años 50 se dio cuenta que para multiplicar números en binario con signo te podías ahorrar un montón de sumas y restas si te fijabas en patrones de 1's consecutivos (en modo simplista), la cosa es que el truquillo es la bomba y por ejemplo los primeros pentium utilizaron una variante de booth en modo radix-8 para sus multiplicaciones. , vamos que es un truco que sigue siendo vigente.
Por si alguno le gusta guardar documentos originales en el archivre.org está el paper original https://web.archive.org/web/20180716222422/http://bwrcs.eecs.berkeley.edu/Classes/icdesign/ee241_s00/PAPERS/archive/booth51.pdf
y aquí un simulador de como va el algoritmo http://www.ecs.umass.edu/ece/koren/arith/simulator/Booth/
Yo os lo he añadido al testbench de forma que ahora se comparan los tres, solo pruebo 10 casos límite, lo ideal sería ampliar el etstbench para probar muchos más porque la codificación del multiplicador podría contener algún bug. Es probable que lo mejore en las próximas semanas según avance en donde lo voy a usar, pero os aviso por si acaso, está recién salido del horno. Os dejo aquí la tabla del testbench:
En la síntesis salen estos resultados, las LCS es del multiplicador combinacional, sólo, sin reloj ni nada, luego para sacar las frecuencias máximas añadí un registro y un reloj, en el paquete teneis una carpeta que contiene los top para sacar las LCs solas, los top del directorio principal incluyen reloj y unos registros para poder sacar la frecuencia máxima:
Por ocupación:
Fmut 591 LCs
Booth 675LCs
Fmul 714 LCs
Por frecuencia máxima:
FMUL:
Info: Max frequency for clock 'clk$SB_IO_IN_$glb_clk': 50.94 MHz (FAIL at 100.00 MHz)
FMUT:
Info: Max frequency for clock 'clk$SB_IO_IN_$glb_clk': 55.14 MHz (FAIL at 100.00 MHz)
BOOTH:
Info: Max frequency for clock 'clk$SB_IO_IN_$glb_clk': 62.02 MHz (FAIL at 100.00 MHz)
Posiblemente se podría optimizar aún más Booth y Fmul, de hecho pensaba que Fmul ocuparía algo menos y booth igual, posiblemente al generalizar no he sido fino, en cualquier caso creo que es un buen punto de partida para el que le interese.
El paquete contiene un script para compilar con yosys y rutar pero no funciona bien el parseo de los datos, ya os pasaré la versión mejorada que a estas horas estoy que no doy pie con bola.
Espero que os guste, el que está aquí se va a dormir XD
Jesus Arias
May 7, 2025, 2:03:48 PMMay 7
to FPGAwars: explorando el lado libre
Hola, Carlos
mira lo que hacen tus multiplicadores :)
Aunque me parece que el algoritmo no está del todo fino. Este es el resultado con variables de 12 bits y 7 bits fraccionarios:
Booth:
Multiplicación simple:
Parece que tienes algo más de error.
Por lo demás el multiplicador es un poco más rápido aunque también ocupa más celdas
Resultados para 16 bits y 11 bits fraccionales:
Simple: 35.63 MHz , 2286 LCs
Booth: 38.37 MHz, 2389 LCs
Resultados para 29 bits y 24 bits fraccionales:
Simple: 27.42 MHz , 5969 LCs
Booth: 29.13 MHz, 7171 LCs
Son resultados interesantes, aunque me parece que nos estamos saliendo del tema de este hilo...
Buenas tardes a todos
charli va
May 7, 2025, 2:15:20 PMMay 7
to fpga-wars-explora...@googlegroups.com
¡Que bueno! una comparativa super interesante! le daré un repaso sin falta probando varias configuraciones de punto fijo.
Nos hemos ido por los cerros de Úbeda! da para otro hilo solo de multiplicadores XD
Muy buenas tardes!
--
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.
Gerardo Tenreiro Vazquez
May 8, 2025, 7:09:32 AMMay 8
to FPGAwars: explorando el lado libre
Hola,
Muy interesante esto de las multiplicaciones en la FPGA, a mi lo que me esta dejando asombrado es que solo la parte de multiplicación ocupe mas del 50% de la capacidad de la FPGA en celdas.
Nunca me podría imaginar esto.
Con esto datos aportados :
Resultados para 16 bits y 11 bits fraccionales:
Simple: 35.63 MHz , 2286 LCs
Booth: 38.37 MHz, 2389 LCs
Resultados para 29 bits y 24 bits fraccionales:
Simple: 27.42 MHz , 5969 LCs
Booth: 29.13 MHz, 7171 LCs
todas mis ideas se complican, mi desconocimiento del tema esa mucho mas grande de los que creía.
Creo que tendré que pensar en algo externo a la FPGA para realizar los cálculo.
muy interesante y muy buen aporte de conocimiento sobre todo de un tema que no lo encontré tratado en ningún otro lugar.
Entiendo que lo pasareis a librería del ICESTUDIO verdad?
Muchas gracias
Jesus Arias
May 8, 2025, 11:23:07 AMMay 8
to FPGAwars: explorando el lado libre
Hola Gerardo
Estos multiplicadores ocupan mucho porque tienen un diseño de "Fuerza bruta" y son completamente combinacionales. El lado bueno es que son muy rápidos.
Pero un diseño secuencial, con registros de desplazamiento, acumulador, y sumador, todos de 32 bits, no creo que pase de las 100 celdas lógicas. En cambio tardará 32 ciclos en hacer una multiplicación (o puede que sólo 16 ciclos con el algoritmo de Booth, eso lo sabrá mejor Carlos)
Yo no suelo usar habitualmente Icestudio, pero no me parece que sea muy complicado meter un módulo Verilog en un bloque de Icestudio, basta con definir las entradas y salidas y el resto del código Verilog va dentro del bloque sin más.
Saludos
Jesus Arias
May 8, 2025, 11:44:14 AMMay 8
to FPGAwars: explorando el lado libre
Hola otra vez,
Respecto de los datos de ocupación de mi "máquina de Maldelbrot" olvidé comentarte que internamente tengo:
- 3 multiplicadores fraccionales
- 4 sumadores
- Un controlador de vídeo VGA
- Un poco de lógica adicional para pegar todos los bloques.
Así que no todas las celdas se emplean en un único multiplicador, aunque en comparación el resto de los bloques son enanos.
Saludos
charli va
May 8, 2025, 11:48:37 AMMay 8
to fpga-wars-explora...@googlegroups.com
Muy buenas! como dice Jesús, estos multiplicadores sacrifican espacio por velocidad.
El multiplicador de booth que os he pasado es totalmente combinacional, también genera el resultado en 1 sólo ciclo.
Quiero afinarlo más porque me había hecho los cálculos de la cuenta la vieja para que me ocuparan algo menos LCs de los que ha ocupado y pudiera alcanzar más velocidad.
Eso sí, por los truncamientos que hace , añadí un desplazamiento de 0.75LSB para compensar el error acumulado. Como los casos límite de prueba que me puse , cuadraron os lo lancé sin probar mucho más pero con Mandelbrot se ve que algo falla, Me liquidé una suma parcial porque la di por despreciable y me da que por ahí va el error.
Le daré una vuelta estos días, además ha coincidido que ando haciendo una historia en la que quiero meter muchos multiplicadores y ando planteando ver otras opciones (como indica JEsús en su documento Wallace y Dada u otras que he estoy viendo en diferentes artículos que parecen prometedoras).
Meterlo en icestudio es muy fácil, aun así los prepararemos para el que no se defienda mucho con verilog.
Aún se me caen las lágrimillas de ver la Mandelbrot machine con este multiplicador :)
Buena tarde!
Gerardo Tenreiro Vazquez
May 8, 2025, 1:20:19 PMMay 8
to fpga-wars-explora...@googlegroups.com
Muchas Gracias Jesus
Ya me quite el miedo del cuerpo, ya empezaba a pensar que la FPGA era una mala elección por la ocupación de memoria.
Como ya os comente nunca hice nada con una FPGA, si lei mucho pero nunca toque una en realidad.
Estoy esperando que me llegue una ALHAMBRA II para empezar a descubrir las maravillas y los problemas.
100 celdas es poco para una capacidad de 7000, 32 ciclos de reloj de la FPGA también son asumibles para una frecuencia de 160Mhz¡, asi que dejare de pensar en cosas raras que estaba pensando y seguiré adelante con la FPGA
Referente a ICESTUDIO es con lo que empezare, al parecer está a punto liberarse una nueva versión que cuenta con muchas mejoras, espero que esto de las operaciones matemáticas y las librerías estén también disponibles.
Muchas gracias y un gran saludo al grupo.
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/vDLFxwM9YDM/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/0c5db8ad-f9f0-44f0-b081-dbf01f18fed7n%40googlegroups.com.
Jesus Arias
May 9, 2025, 4:50:31 AMMay 9
to FPGAwars: explorando el lado libre
Hola otra vez
Me temo que mi estimación de 100 celdas era demasiado optimista. Al final he diseñado el módulo del multiplicador secuencial de 32 bits (de momento sólo para datos con 31 bits fraccionales, va adjuntado) y me salen:
236 celdas lógicas
119 MHz de reloj máximos
Al final esto son 7 LCs por cada bit del multiplicador (después de restar las 11 LCs de la señal busy), de las cuales 4 LCs se van en la lógica del ajuste de los signos antes de la multiplicación propiamente dicha (si el multiplicador fuese siempre positivo ocuparía menos de la mitad) y las otras 3 en los registros. Me ha costado lo mío entender porqué el cambio de signo ocupa 2 LCs por bit en lugar de una, y al final la explicación está en el acarreo de las LCs (no se puede calcular el acarreo con el inverso de la entrada, por eso se necesita otra LC)
Por otra parte, quería destacar que la frecuencia máxima de una FPGA no está especificada en ninguna parte porque va a depender mucho del circuito que se sintetice dentro y de cómo la herramienta de place & route haga sus conexiones internas. Por ello no es algo que podamos saber a priori hasta que hayamos sintetizado nuestro diseño. Entonces es cuando "nextpnr" nos va a dar una estimación para la frecuencia máxima.
Como ejemplos en las ICE40HX:
- Microcontrolador con CPU RiscV LarVa: f_max = 28 MHz
- Codificador de video DVI: f_max = 274 MHz
- Frecuencímetro con contadores de rizado: f_max = 683 MHz
En la práctica estas frecuencias se pueden exceder algo pero no mucho. Los PLLs de las ICE40HX no pueden generar frecuencias por encima de los 275 MHz
Buenos días
charli va
May 9, 2025, 5:08:26 AMMay 9
to fpga-wars-explora...@googlegroups.com
Me parto,,,,, nos dan cuerda y no sé a donde llegamos XD
Yo ando implementando también otro multiplicador serie, de bit en bit con la idea de que ocupe poco y vaya muy rápido muy alineado con esto que acabas de pasar , ando con una idea mezclando algún concepto de lo aprendido con booth, a ver si consigo que tire , que ahora mismo se me desbarra totalmente y os lo paso, pero me da que se me va a ir de LCs.
Quizá deberíamos abrir un hilo solo de multiplicadores porque esto está dando para una buena comparativa, meteré este nuevo multiplicador en el testbench que os pasé que saca la tabla con los datos comparativos y meteré más cuentas aleatorias a parte de los casos límite .
Quizá estaría bien comparar los errores de precisión entre los diferentes multiplicadores como tiene Jesús en el documento de Mandelbrot, por ver cuales son más precisos y así a futuro según necesidades tener una tabla de referencia para elegir "a la carta" ;)
Que tengáis buen día!
Gerardo Tenreiro Vazquez
May 9, 2025, 5:29:36 AMMay 9
to fpga-wars-explora...@googlegroups.com
Hola Jesús
236 celdas de 7500 es asumible, por lo menos si entiendo que creó una multiplicación y la puedo utilizar en todos los módulos, que creo que será así verdad?
Como comente el equipo dispone de dos ADC de 32 bit que leen las magnitudes en el mismo momento, así la FPGA tiene que al recibir final de conversión del primer conversor realizar la siguiente secuencia:
1.- Leer el ADC de tensiones -> Valor de 32 bits
2.- Leer el ADC de Intensidades -> Valor de 32 bits
3.- Parametrizar el ADC de Tensiones -> Envía unos 48 bits
4.- Parametrizar el ADC de Intensidades -> Envía unos 48 bits
5.- Leer de la Memoria de calibración de tensiones el Valor de conversión según la temperatura. La temperatura la obtiene leyendo secuencialmente por I2C
6.- Leer de la memoria de calibración de intensidades el valor de conversión
7.- Multiplicar la medida del ADC de tensiones por el valor de conversión y depositar en registro
8.- Multiplicar la medida del ADC de intensidades por el valor de conversión y depositar en registro
(Esta secuencia es en la conversión de valores, la FPGA también tiene que medir tiempos entre pasos por cero, leer temperatura, gestiones tensiones de medidas, etc)
Como puedes ver el bus SPI de los conversores es unico, aqui me gustaria disponer de dos buses SPI para efectuar la lectura y parametrización de los dos ADC de forma simultánea, pero el número de pines no me lo permite
Ademas si operó de forma simultánea necesitare dos multiplicadores lógicos verdad?
Con las FPGA el pensamiento cambia y las operaciones se realizan en paralelo así que esta parte también la tengo que asumir y ver cómo afrontar, Yo esto en un procesador lo tengo claro y aplico lo de divide y vencerás, pero en la FPGA el planteamiento creo que no es así.
Me gustaría conocer vuestra opinión referente a cómo plantear el hardware para que la FPGA esté trabajando dentro de lo más óptimo posible.
Como sabéis la FPGA cada x tiempo tiene que efectuar la media de las medidas y asumir este valor como el dato valido, asi que sumar y dividir en 32 bit también puede ser una odisea verdad?
Creo que las 4 operaciones matemáticas simples, suma, resta, multiplicación y división en 32 bits me son imprescindibles, así que será lo primero que tengo que asumir y preparar lo más optimizado posible.
Una librería matemática en 32 bits sería lo ideal. ¿Quien se anima?
Con Vuestros ejemplos y ayuda seguro que lo conseguiremos
Muchas gracias
Democrito
May 9, 2025, 10:52:03 AMMay 9
to FPGAwars: explorando el lado libre
Hola:
He tomado el circuito de Jesús y he hecho un montaje con unos conversores que tengo para que se pueda ver desde el terminal serie.
Debido a que mis conversores (tanto de RX como de TX) son como máximo SQ16.16 (16 bits enteros + 16 bits fraccionarios, con signo) le he hecho una adaptación de buses para convertirlo a SQ1.16. Es decir, que como máximo sólo puede representar 4 dígitos fraccionarios en vez de 8.
Aparcando esta limitación por la adaptación de los conversores, siempre me sale como respuesta números negativos. En el ICE que adjunto he puesto el signo siempre a 0 y aún así me sigue respondiendo a la multiplicación con negativo.
Por otra parte cuando hacemos que una multiplicación se desborde (que sea mayor de 1.9999), en las siguientes multiplicaciones la parte entera acumula algún error, dándome resultados no deseados, sin embargo la parte fraccionaria es correcta.
Para finalizar comentar que para evitar que, por ejemplo al multiplicar 0.5*0.5 y nos responda con 0.24999, lo que hago es sumarle una pequeña cantidad, en este caso se puede sumar 2 ó 3, y conseguimos que redondee a las cifras esperadas. La constante "adjust" se encarga de ello.
Quizás algunos problemas que he comentado sean debido a las adaptación de buses, o que exista algún concepto que me esté saltando o que no me doy cuenta.
Adjunto ICE de prueba.
Saludos.
charli va
May 9, 2025, 11:29:07 AMMay 9
to fpga-wars-explora...@googlegroups.com
Buenas Demócrito, no he podido ver aún tu circuito pero por el pantallazo una cosa importante, multiplicador de jesús es para el rango -0.999.... al 0.999 se usan todos los bits para la parte fraccionaria menos 1 que es para decir si es positivo o negativo.
Te lo digo porque en el pantallazo he visto un 1.5555 y no sé si es un despiste o que tienes un error de concepto en el formato utilizado por el multiplicador. Si quieres probar puedes utilizar el de booth que adjunté más arriba que puedes configurar el número de bits de la parte fraccionaria de forma que podrías configurar un Q16.16 (no lo he probado nunca y a lo mejor explota) por si lo quieres testar.
charli va
May 9, 2025, 11:31:57 AMMay 9
to fpga-wars-explora...@googlegroups.com
Perdón , me he equivocado, según le he dado a enviar he caído, el rango en los multiplicadores que está usando Jesús para Mandelbrot es de -1.0 a 0.999 (esto ya no lo se de memoria).
Democrito
May 9, 2025, 1:14:13 PMMay 9
to FPGAwars: explorando el lado libre
Carlos, he tenido que adivinar cuál de ellos era, pero creo que lo encontré.
Lo he configurado para SQ16.16, o dicho de otro modo, de 32 bits con signo con 16 bits fraccionarios.
Va relativamente bien. Funciona bien los signos y más o menos realiza bien los cálculos, pero muchas veces "patinan" los dos últimos dígitos fraccionarios.
El anterior adjunto que puse era el secuencia, este dato se me olvidó comentarlo. El que adjunto aquí es el puro puro combinacional, que por cierto, ocupa 4040 LCs, pero hay que restar unos 1357 de los conversores para el terminal serie.
Lo adjunto por si quieres probarlo.
Democrito
May 9, 2025, 1:17:43 PMMay 9
to FPGAwars: explorando el lado libre
Por cierto, como no tenía "done" o "busy", tuve que poner un temporizador de envío. Cada 5 segundos envía el resultado.
Democrito
May 9, 2025, 1:25:56 PMMay 9
to FPGAwars: explorando el lado libre
Vale, es combinacional... voy a modificar esa parte porque es un rollo estar con el temporizador.
charli va
May 9, 2025, 1:34:04 PMMay 9
to fpga-wars-explora...@googlegroups.com
Buenas!, si la idea de estos multiplicadores es que sean combinacionales (en un ciclo, respuesta) si lo necesitas sincronizar añade un registro con el load antes o después, a gusto del consumidor ;)
Lo del error es lo que pasaba en la imagen de Mandelbrot, realmente booth tiene un error posible de 1lsb (precisamente esos últimos decimales.) puede ser error mio como comenté arriba, tengo que depurarlo, estoy justamente ahora trabajando en ello junto con un multiplicador serie (multiplica bit a bit) como el de jesús pero en formato más típico de 1 bit signo, y luego el resto lo repartes como quieras.
Te adjunto otro multiplicador que es el de Jesús pero genérico con el formato 1bit signo + tu reparto, este debería ir más cuadrado, si lo pruebas nos cuentas y vale para ir validándolo porque el de Jesús está super optimizado y además usa el formato que sería algo así como 1bit signo+0 parte entera+ resto fraccionario y generalizar eso de forma óptimia es "jodido".
Estoy preparando un test para poder medir del tirón las áreas ocupadas por cada multiplicador, velocidad máxima y un set te pruebas para comprobar que funcionan (inicialmente solo probé casos límite y booth ahí iba bien pero en casos aleatorios estoy viendo las pérdidas deprecisión posiblemente por un truncamiento que me cargué).
Lo dicho si pruebas este otro nos cuentas, estaría genial ver si tiene menos error (también es combinacional)
Democrito
May 9, 2025, 1:39:06 PMMay 9
to FPGAwars: explorando el lado libre
Para no liarnos:
El último que he adjuntado sólo era corregir (eliminar) el temporizador.
Voy a mirar el otro que has enviado.
Democrito
May 9, 2025, 1:54:51 PMMay 9
to FPGAwars: explorando el lado libre
Te adjunto el que dices que has modificado y es combinacional. Sigue patinando las dos últimas cifras de la parte decimal.
Por ejemplo:
34.5677*23.9991 verás que los dos decimales finales no se corresponden con el valor real.
34.5677*23.9991 verás que los dos decimales finales no se corresponden con el valor real.
Mi opinión: Si mis conversores no fallan, como la multiplicación pertenece a cálculos lineales, sólo permitiría un error de más/menos 0.0002. En cálculos no lineales se puede tener mayor margen si conserva valores que se aproximan dentro de un margen coherente.
Adjunto ICE
charli va
May 9, 2025, 2:21:53 PMMay 9
to fpga-wars-explora...@googlegroups.com
Siempre va a haber error si comparamos muchos decimales generados por un ordenador :) La idea es medir ese error y clasificarlo para así poder hacer una tabla real.
Tus conversores los podemos testear también para quedarnos tranquilos de que funcionan como un reloj suizo ;)
Yo estoy preparando una simulación pero tu módulo me ha parecido genial para una vez en la simulación parece que esté la cosa sólida, usarlo para volcar un montón de resultados de multiplicaciones automatizadas dentro de la fpga , y guardar los datos reales recibidos por el terminal serie y con eso calcular el error. Aunque la simulación será bastante exacta o casi exacta, me parece curioso tomar los valores reales de la FPGA.
Tus conversores los podemos testear también para quedarnos tranquilos de que funcionan como un reloj suizo ;)
Muchas gracias por probarlo!
Jesus Arias
May 9, 2025, 5:31:51 PMMay 9
to FPGAwars: explorando el lado libre
Hola Gerardo
Por lo que creo entender de tu proyecto, lo que realmente importa es muestrear las señales de ambos ADCs simultáneamente. Luego los datos se pueden leer y procesar de forma secuencial, siempre que dispongamos de tiempo para todo. Para ello los dos ADCs deberían tener el mismo reloj y deberían recibir el comando START simultáneamente (activando los dos pines CS del bus SPI al enviar el comando)
Los datos de calibración basta con leerlos una vez dejando una copia en memoria interna, y la temperatura no necesita un muestreo rápido. Los bloques que leen estos datos operan por separado del de los ADCs y dejan sus datos compartidos en memoria interna. Y lo mismo podemos decir del bloque de medida de tiempos (paso por cero). Todos esos bloques operan en paralelo.
Una cosa que me preocupa un poco es la conmutación de los 10 canales analógicos. Al ser los ADCs del tipo sigma-delta cuando se cambia un canal de entrada se podría tener un transitorio que dura varias muestras ("conversion latency") Esto va a impedir entrelazar las medidas de los canales...
Respecto de la aritmética las sumas y restas son muy simples y suponen poca lógica. La división es algo que no me había planteado. En los algoritmos de procesamiento de señal es una operación que se suele evitar (el DSPIC que mencionabas no tiene divisiones en su motor DSP, y las divisiones enteras del micro tardan 18 ciclos frente a 1 ciclo en multiplicaciones). Supongo que la división también debería operar con datos de coma fija...
Buenas noches
El viernes, 9 de mayo de 2025 a las 11:29:36 UTC+2, gtv...@gmail.com escribió:
Jesus Arias
May 9, 2025, 5:58:54 PMMay 9
to FPGAwars: explorando el lado libre
Hola,
Una forma "correcta" de hacer las multiplicaciones sería usar un multiplicador entero que nos de un resultado de 64 bits del que luego nos quedamos con los 32 bits más significativos. Este último truncamiento genera un error de +- 0.5 LSB
Pero esos bits que quedan por debajo del 32 suponen un montón de sumadores para calcular unos bits que sólo tienen peso en el resultado final a través de los acarreos. Así que me había planteado truncar los bits LSB de las sumas intermedias para ahorra lógica. Claro, al hacer eso el error es bastante mayor.
Así que como solución de compromiso me había planteado añadir sólo un par de bits a las sumas intermedias (en lugar de los 32 bits que se necesitarían en un multiplicador entero), con lo que el error, aunque siga siendo mayor que +-0.5 LSBs, no es exageradamente mayor.
La figura estaba calculada para multiplicadores de 16 x 16 bits en los que los sumadores intermedios eran de 16, 18, o 32 bits:
charli va
May 9, 2025, 6:03:44 PMMay 9
to fpga-wars-explora...@googlegroups.com
Super buena explicación, me dejó impactado lo que pasaba en Mandelbrot y ando revisando el código de los multiplicadores que andamos moviendo por aquí en los que he hecho yo , tienen todos algunos errores que en valores extremos se desbordan o meten demasiado error , justamente 1 o 2 bits de ls sumas intermedias que en su momento por recortar en la línea que comentas me los había "zampado".
Quiero verificar que funcione todo bien antes de mandároslos, como ando parametrizando para que sea configurable el Qm.n me está costando ma´s de lo que pensaba.
PEro gracias por el código y la explicación que me ha dado luz.
Democrito
May 9, 2025, 7:00:55 PMMay 9
to FPGAwars: explorando el lado libre
Lo he probado y parece que seguimos en el mismo agujero negro de las multiplicaciones fraccionarias. Lo he probado en Q16.16 con signo porque es lo que soporta los conversores sin hacer artefactos de buses y equivalencias.
Adjunto ICE para probar. Con pequeñas multiplicaciones no hay mucho problema, pero cuando se elevan las cifras (número de dígitos) la realidad difiere.
Y ya pasamos aquí si queréis: https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/Ep7s8HmMC9M
charli va
May 9, 2025, 7:20:18 PMMay 9
to fpga-wars-explora...@googlegroups.com
Eso es normal Demócrito, es lo que he planteado en otro mail, con números grandes multiplicando 2 valores de 16bits hace overflow rápidamente. Estoy inentando preparar una versión con protección, pero la generalización me está matando. Por hoy creo que lo dejaré y mañana a ver si lo veo más claro.
charli va
May 10, 2025, 2:29:13 AMMay 10
to fpga-wars-explora...@googlegroups.com
¡Buenos días!, creo que ahora sí tengo la versión del multiplicador de la máquina de Mandelbrot funcionando a pleno rendimiento, tengo que probarlo más pero el testbench con más casos intermedios y casos límite que antes desbordaban ya salen correctamente (la única columna importante es la referida a fmul(real) que es el valor que devuelve el multiplicador y Theorical(real) es el valor teórico esperado, ahora mismo cuadra todo bastante bien, como podeis ver puede haber alguna pérdida de precisión en los dos últimos dígitos en algún caso extremo(los próximos a desbordar) , esto no sé si es mejorable tengo que darle una vuelta, pero creo que empieza a ser usable.
En principio soporta el caso Q0.M siendo M el número de bits -1 (todo fraccionario y 1 bit de signo).
Y he metido soporte para saturación (satura cuando desborda) como si fuera un DSP, no sé si es interesante, dejar esta parte configurable (es decir que elijas si si o si no quieres saturación) y/o además sacar una bit de desbordamiento. De momento lo he dejado de forma transparente, de forma que puedes estar tranquilo de que no se te de la vuelta la multiplicación.
Os adjunto la tabla (los otros multiplicadores aún me fallan) y os adjunto el código.
En principio soporta el caso Q0.M siendo M el número de bits -1 (todo fraccionario y 1 bit de signo).
Y he metido soporte para saturación (satura cuando desborda) como si fuera un DSP, no sé si es interesante, dejar esta parte configurable (es decir que elijas si si o si no quieres saturación) y/o además sacar una bit de desbordamiento. De momento lo he dejado de forma transparente, de forma que puedes estar tranquilo de que no se te de la vuelta la multiplicación.
Os adjunto la tabla (los otros multiplicadores aún me fallan) y os adjunto el código.
¡Buen sábado!
Gerardo Tenreiro Vazquez
May 10, 2025, 5:18:37 AMMay 10
to FPGAwars: explorando el lado libre
Buenas Grupo y enhorabuena por el apoyo prestado.
Esta serie de equipos están destinados al proceso de generación y distribución de energía, por ello es muy importante procesar la tensión y la intensidad en el mismo momento, nada es 100% simultaneo nunca, pero se trata de leer ambas ondas en el mismo momento. Este tipo de equipo se utiliza para verificar conversores o contadores de medida así que suelen estar en marcha durante horas verificando medidas, acumulando energía y el resultado es muy importante para el cliente, el usuario y la distribuidora.
La frecuencia de red en muchos lugares es de 50hZ o de 60hz pero este equipo también puede procesar redes de 400hz (Utilizadas en equipos especiales), no con la misma precisión ni resolución pero si se puede utilizar.
Con una frecuencia de 50hZ tenemos una onda completa en 20ms lo que significa que la tensión y la intensidad toman todos los valores posible de ese ciclo, no se trata de medir todos los valores pero si de medir los necesarios para tener una idea de su forma y su desfase.
El equipo cuenta con una señal digital de cada una de las medidas de forma que por esa señal podemos determinar el momento que cambia de valor, esto nos permite medir la frecuencia y el desfase entre una y otra señal. Con este desfase podemos determinar si la potencia es inductiva o capacitiva y este valor junto con la medida de los dos canales en el mismo momento nos define el calculo de la potencia en ambos canales. Dos canales son un modulo. El equipo dispone de 10 módulos.
Se que suena a chino pero hoy en día la red eléctrica de todo el mundo esta muy modificada por los equipos electrónicos que la trocean y desfasan generando armónicos que son muy perjudiciales para el usuario y la compañía eléctrica. Esta energía que utilizamos genera graves problemas en muchos equipo y al mismo tiempo es muy difícil de procesar o gestionar. por eso este equipo permite a los técnicos tomar medidas de la red eléctrica y conocer la naturaleza de la misma y a ser posible tomar medidas correctores.
Otra de las funciones es determinar si dos redes son iguales o si se pueden acoplar entre si, para ellos analiza las tensiones de las dos redes y verifica si están dentro de parámetros para poderse unir, esto en redes con muchos armónicos es realmente difícil de determinar sobre todo con armónicos bajos cono el quinto y séptimo.
Hoy en día hay analizadores de redes que permiten efectuar estas medidas o osciloscopios de 6 canales que permiten monitorear las tres fases de tensión y las tres fases de intensidad, en el caso de los osciloscopios el procesamiento de los datos lo tiene que hacer el operador de forma tradicional mientras que en los analizadores de redes algunos de estos procesos lo realiza el propio equipo, pero no todos ni nunca de forma conjunta, por ello y por la necesidad de uso en su momento cree el equipo anterior que realiza las mismas funciones que intentare realice este y supere al anterior.
Esta es la explicación corta de por que es necesario leer la tensión y la intensidad en casi el mismo momento. Digo casi por que siempre hay algún desfase de tiempos por pequeños que sean. La medida es digital así que entre cada una de las medidas hay un tiempo, mayor o menor pero un tiempo. Nada es en tiempo real, todo aun la visión tiene un desfase de tiempo desde la imagen al proceso y eso que va a la velocidad de la luz.
Efectivamente los dos ADC tienen el reloj unido y operan a la misma frecuencia. la señal de STAR se envía desde la FPGA al mismo momento a ambos ADC y el resultado se lee primero uno y después el otro. Tras la lectura de los dos ADC se parametrizan los dos nuevos canales en los ADC, el ADC ya esta procesando el canal anterior por ello la conversión se interrumpe al llegar los nuevos parámetros, se envía la señal de STAR y el ADC inicia de nuevo la conversión. desde este momento la FPGA tiene que hacer los calculo y dejar el dato en la SRAM. Cuando uno de los dos conversores termina activa la línea de aviso a la FPGA para que el proceso se vuelva a repetir. NO siempre se utilizan todos los canales ni siempre con los mismos parámetros, pero ese proceso lo gestiona el ESP32 según las opciones y los resultados.
Referente a la temperatura comentar que con leerla cada 5 ó 10 segundos es suficiente, son sensores de 0,25ºC de resolución que están dentro del modulo de medida, realmente están justo encima de la resistencia de medida.
La idea de leer toda la table de calibración no creo que sea muy viable, hay 10 módulos de medida, cada modulo de medida contiene valores de 32 bit de la conversión desde -10ºC a 60ºC cada grado, así que son 10 canales x 70 Grados x 1000 valores de conversión x 2 magnitudes (tensión e intensidad)x 32 bit = 44,800,000 bits.
Mientras que leer el valor de conversión es apuntar a la dirección según la temperatura y leer el valor de 32 bit de la memoria. creo que es un proceso mas lento pero mas liviano de ejecutar. además los módulos son enchufables en caliente lo que significa que el operadores lo puede extraer y cambiar en cualquier momento, claro esta dejan de medir y retoman la medida. Cada modulo dispone de una señal a la FPGA que le indica si el modulo esta insertado o no, Cuando se inserta un modulo se lee de la memoria del modulo que tipo es, su rango, sus características y sus parámetros, estos valores si se guardan en memoria de la FPGA y el ESP32 los procesa y adecua según condiciones.
El rango de los módulos en diferente así que en la memoria de calibración además de la calibración están estos datos así como los datos tipos de numero de serie, fecha de fabricación, fecha de calibración, estado de l modulo etc.
Todos los módulos disponen de dos salidas analógicas de +-2.5V que se conectan a los conversores ADC, En cada modulo hay 7 señales directas de la FPGA, dos de las señales de tensión y intensidad mayor que cero, dos del bus I2C, una de modulo insertado y dos de reserva en estos modulo de medida. (Podéis ver en el esquema enviado)
Este equipo no solo admite módulos de medida, también admite otros tipos de módulos que tienen otras funciones que os iré comentando, pero su principal función es la de medida y simulación. Esto de la simulación es tomas las medidas de la red actual con un modulo y después generar esa misma red en salidas analógicas. por eso también admite otro tipo de módulos que no son de medida sino de simulación.
Se que parece exagerado disponer de todos estos datos de calibración, pero la realidad me demostró que la electrónica dentro del modulo cambia sustancialmente los resultados de las medidas según la temperatura, incluso con pequeñas variaciones de 0,25ºC la misma medida se ve afectada en un 0,02% en los extremos del rango de medida. por eso la tabla de calibración no es lineal y los valores se determinan cuando se efectúa la calibración del modulo. dos módulos fabricados igual, en el mismo momento, con las mismas condiciones no responden igual en la calibración y mucho menos en la vida real.
El shunt de medida de intensidad varia su medida sustancialmente dependiendo de la temperatura y la fabricación de las resistencia. realice pruebas con shunt caros de buena marca y con resistencia occidentales de las mas baratas y ambos necesitan datos de calibración, los dos con buena calibración otorgan resultados similares y de duración en el tiempo muy similar.
Lo ideal es que lo módulos se vuelvan a calibra una vez al año si pretendemos tener resultados dentro de la precisión del equipo. normalmente no hay grandes diferencia pero si las hay.
El procesamiento de los tiempo se efectúa en 10 módulos diferentes, cada modulo se ejecuta al cambio de valor de su señal, tenemos 10 canales que miden tensión e intensidad de forma simultanea en los dos ADC. La tensión dispone de una señal digital y la intensidad dispone de otra señal digital, si la potencia esta en fase y con un factor de potencia de 1 la tensión y la intensidad cambia en el mismo momento, según el factor de potencia y si es inductiva o capacitiva el momento de cambio varia en el tiempo de forma que conociendo la frecuencia y la diferencia de tiempo entre la tensión y la intensidad conocemos el factor de potencia.
Referente a este cambio de positivo a negativo hay momentos de incertidumbre donde el operacional que mide si la magnitud es mayor que cero comete errores. en redes donde las ondas están bastante limpias de armónicos se puede recalcular con los valores de la medida de los ADC, pero en redes donde la onda es muy mala el ESP32 realiza un calculo del coseno entre la tensión e intensidad para mejorar el resultado.
Esta mala detección del cambio de polaridad en las magnitudes afecta a la medida de frecuencia y en este punto estoy trabajando para mejorar la detección e intentar minimizar los errores, pero no tengo mucha esperanza que el hardware solvente al 100% este error que ya tiene el equipo anterior y este pueda que también, así que el software de la FPGA tendrá que realizar algún tipo de magia para solventarlo, pero paso a paso, primero medir.
Efectivamente los DSPIC no disponen de ALU de calculo a 32 bit de coma flotante, pero si tengo una librería bastante optimizada que me permiten las funciones matemáticas básica, la secuencia de los dos DSPIC es diferente a la de la FPGA, los DSPIC funcionan de forma asíncrona, disponen también de dos ADC1262 pero disponen de dos memoria DUAL PORT RAM de forma que un PIC32 se encarga de leer las memoria y alimentar de datos al ESP32. esto me genero muchos problemas de sincronismo y de coordinación entre lecturas y datos, no fue buena idea disponer un intermediario, además todos los datos se procesan varias veces y aumenta mucho en consumo de energía para la misma operación dando como resultado menor eficiencia en el equipo sin conseguir nada. otro de los problemas graves es la actualización del software que es de forma independiente a cada uno de los micros de la placa. Es un diseño de hace años así que no le puedo pedir mucho mas.
No me parece mala idea operar las matemáticas a 64 bit en el resultado, esto genera un tiempo mas de conversión de nuevo a 32 bit pero creo que mejora la precisión del calculo. Todos los lenguajes de programación dispone de simple o doble precisión de calculo según el tiempo que quieras invertir en la operación, incluso podemos plantearnos operar con enteros. Mi primera idea era utilizar 32 bit con valores enteros desplazados 5 lugares de forma que simplifique los cálculos de la coma flotante.
El numero de ciclos de cada operación esta determinado por el tiempo de conversión del ADC1262, que estada configurado a 1200SPS ò 2400SPS según proceda.
Tendría que tener una idea de la ocupación de celdas y del tiempo de cada operación.
Aun no me llego la ALHAMBRA II, ya me esta tardando mucho, para realizar las pruebas, pero me parece muy interesante todo lo que estoy aprendiendo de multiplicaciones, parece un tema que dará para largo y mucho.
Esto es lo que me encanta del grupo, una idea y muchas grandes personas que aportan lo mejor.
Muchas gracias
Democrito
May 10, 2025, 10:47:40 AMMay 10
to FPGAwars: explorando el lado libre
No sabía que multiplicar con decimales (parte fraccionaria) pudiera dar tantos problemas para luego al final sólo dar dos decimales exactos.
He estado haciendo múltiples pruebas y he llegado a la conclusión que con los métodos que hemos usado no se puede, incluso escalando a 64 bits.
Este camino es demasiado ineficiente.
charli va
May 10, 2025, 11:03:58 AMMay 10
to fpga-wars-explora...@googlegroups.com
A qué te refieres a lo de dar dos decimales exactos?
A qué te refieres con lo de dar dos d
charli va
May 10, 2025, 1:02:37 PMMay 10
to fpga-wars-explora...@googlegroups.com
Creo que ya te entiendo Demócrito! y voy a intentar explicarme porque doy por hecho cosas que no he explicado, disculpadme.
final_sum[30:15] + final_sum[14].
A ver os cuento la idea de como estoy testeando esto. Lo primero es entender que no es lo mismo en computación un número en punto flotante que un número en punto fijo, las formas de aproximar y representar el valor es distinto. De echo implementamos punto fijo precisamente porque no tenemos unidades especializadas en punto flotante y su implementación en la fpga sería muy costosa.
Entonces por eso en las dos primeras columnas pongo los números a multiplicar en hexadecimal , porque multiplicamos ese valor numérico en bits y no su representación numérica que podría llevar a discrepancias de interpretación o aproximación, eso son los bits que entran a los multiplicadores por decirlo de alguna forma.
Los multiplicadores que estamos haciendo , realizan una multiplicación en punto fijo que es la aproximación menos costosa posible al punto flotante (es una aproximación), ¿esto que quiere decir? pues que no tenemos infinitos números reales, sino solo una fracción de ellos múltiplos de la resolución dada por el punto fijo.
La resolución la podemos calcular así:
La resolución la podemos calcular así:
Por ejemplo para Q8.15, el paso mínimo representable es 2^{-15} ≈ 0.000030517578125. Cualquier valor que no sea múltiplo exacto de este paso se aproxima al valor más cercano por redondeo, introduciendo un error de hasta ±2^{-16} (~0.0000152587890625).
El redondeo, si veis en el código fuente del multiplicador, lo veréis por ejemplo en una línea final que hace esto por ejemplo para Q8.15:
final_sum[30:15] + final_sum[14].
el final_sum[14] es el redondeo del truncamiento, es decir al hacer las sumas parciales, al acabar hay que cortar y luego redondear para aproximar al valor más cercano al múltiplo de la resolución dada por el formato del punto fijo.
Por eso en la tabla veréis números cuadrados y otros aproximados, los que sean múltiplos de la resolución coincidirán todos los valores y los que no son redondeados al múltiplo más cercano.
Y por último tenemos otro handicap que es que para automatizar o tener una referencia a la hora del desarrollo o comparar precisiones, en el testbench el multiplicador es el generador del punto fijo por lo que sólo podemos compararlo con el valor en formato coma flotante (theorical) como el valor theorical se calcula en coma flotante por el simulador, es mucho más preciso y por eso en muchos casos tendrá una ligera diferencia con el punto fijo, además para que me cupiera en la pantalla había reducido el número de digitos a 6 porque el mayor de los problemas al parametrizar el módulo, ha sido lidiar con el signo y el desbordamiento y para eso con 6 dígitos me valía (os adjunto aquí la tabla con unamejora en el testbench que acabo de hacer para que muestre el máximo número de digitos decimales que de la resolución elegida).
Esto no quiere decir que el punto fijo no valga o no tenga precisión, tiene la precisión máxima que nos permite el artefacto del punto fijo :) pero es una forma muy sencilla de comprobar si el multiplicador multiplica bien y si la precisión se ajusta.
La columna Product es el producto tal cual en coma flotante sin saturación (es decir se da la vuelta si desborda), aunque esto en la captura ahora mismo no está funcionando porque lo estoy tocando pero bueno la idea es que sea eso.
Me ha motivado preparar estos multiplicadores porque estaba precisamente haciendo una cosa en la que tengo que usar punto fijo con multiplicadores y ha coincidido con ello. En general siempre había usado dsps para estas cosas y no me había pegado con implementar un multiplicador (y los algoritmos los había visto en teoría pero no me había pegado con implementarlos).
Hay implementaciones en github. pero en general están ajustadas a resoluciones concretas (8,16 bits...) o formatos fijos y basados en general en FSMs (básicamente muchos de los que he visto han aplicado algoritmos secuenciales sin aprovechar realmente la potencia de la FPGA).
Estaba implementando booth y el multiplicador de mandelbrot de JEsús me ha inspirado mucho. En este tipo de cosas me suele gustar testar en lo posible algoritmos diferentes y hacer comparativas para poder elegir la mejor opción para cada caso (nunca hay una opción mejor para todo) y veo muy potente para muchas aplicaciones futuras el tener una buena batería de multiplicadores genéricos parametrizables.
De hecho me ha costado más de lo que pensaba parametrizarlo por las limitaciones y lo farragoso del propio legunaje de verilog 2005 que manejamos con yosys pero he quedado contento con el resultado.
Además cubrimos el formato Q0.M!!!! ;)
Espero haberme explicado y si no decídmelo! es un poco lio todo y en el formato de la lista de correo es difícil de hilar las cosas muchas veces.
Que tengáis buena tarde!
Que tengáis buena tarde!
charli va
May 11, 2025, 10:45:45 AMMay 11
to fpga-wars-explora...@googlegroups.com
Gerardo, por cierto que no te comenté nada, muchísimas gracias por tan detallada explicación.
Ya nos irás contando los avances, un mundo interesante el de los altos voltajes ;) y más en los tiempos de hoy en día.
Buen Domingo!
Gerardo Tenreiro Vazquez
May 12, 2025, 4:39:09 AMMay 12
to FPGAwars: explorando el lado libre
Gracias Carlos y grupo.
Cada día que pasa y cuanto mas lee sobre las FPGA mas perdido estoy.
Leí en un correo tuyo Carlos la posibilidad de poder grabar la SRAM de la FPGA o la FLASH esto me parece muy adecuado sobre todo en la fase de pruebas iniciales, esto redefine el conexionado del BUS SPI de la FPGA.
También leí sobre las FPGA TANG y me parecieron muy interesantes, entiendo que también será compatible ICESTUDIO así que le tengo que dar una vuelta al proyecto y replantear el tipo de FPGA y como parametrizarla.
Además de todo esto parece que ICESTUDIO también sufrirá grandes cambios en un futuro no muy lejano. Sobre esto no se cuanto cambiara ni hacia donde pero leí en varias publicaciones que hay varias modificaciones de varios indoles.
Tenemos el tema de las operaciones matemáticas que no esta nada claro ni tengo definido.
Aun no se si la capacidad de la FPGA será suficiente para el proyecto.
Es mi primer diseño con una FPGA y ni el hardware esta definido, ni las herramientas están definidas, ni la capacidad, ni.....
Si sumamos todos los puntos y añadimos que mi diseño esta solo en fase inicial el resultado es un mar de dudas y posibilidades que por el momento solo es una idea de migrar un equipo de una tecnología que funciona a algo que esta totalmente en el aire.
No soy pesimista ni quiero ponerme del lado malo, un proyecto de esta índole cuesta mucho dinero afrontarlo, sobre todo cuando el 100% de capital sale de los bolsillos de un jubilado y no hay una gran empresa detrás. Puedo perder mi tiempo pero no mi dinero realizando caros prototipos.
La realidad es simple, fijaros por ejemplo ARDUINO es una plataforma que la placas son enchufar y funcionar, la comunicación esta definida, las librerías están creadas, mejor o peor, hay un camino definido, en definitiva es algo que se puede pensar en utilizar mas o menos según las habilidades del usuario. En cambio el camino de las FPGA, según mi visión, esta por definir, en mi opinión, no tenemos o por lo menos Yo un estándar de como integrar el HARDWARE con el SOFTWARE, con esto me refiero a como definir el bus SPI de la FPGA con el USB o la plataforma de parametrización, no hay ejemplos similares del hardware de la FPGA, si buscas ves mil variantes, FTDI, JTAG, Micros.... En todas ellas hay comentarios de compatibilidades, de cambios, de si pudiera, si hubiera.... En definitiva, a lo mejor es mi percepción, el sistema aun no esta maduro. Esta claro que es un sistema totalmente abierto y que cada uno es muy libre de elegir el camino a seguir, que hay millones de posibilidades y que cada día esta creciendo y avanzando, pero estas mismas razones son las que me hacen dudar, cual es el camino correcto a seguir?
Las FPGA llevan muchos años en el mercado y tienen algunas aplicaciones pero no son muchas. ¿Tendremos que pensar porque?
Los mismos fabricantes de las FPGA nunca quisieron abrir la mano demasiado, es como si fuese un producto que lo tienen cerrado y no es interesante dar a conocer, divulgar, promocionar o generar salida al mismo.
En mis 45 años de trabajo como técnico en muy pocas ocasiones me encontré con FPGA implementadas en proyectos ni grandes ni pequeños, las encontré en algún control numérico, en algunos procesadores de video, en alguna analizador lógico y poco mas. ¿No nos tendremos que preguntarnos porque? ¿Qué le pasa a esta tecnología?
Estos son mis pensamientos actualmente, no os preocupéis que el proyecto seguirá adelante con una FPGA, no se el modelo, no se la capacidad, no se si con procesador integrado, no se como la parametrizare, no se que software utilizar, no hay nada definido a no ser que seguiré adelante y que este gran grupo seguirá ayudando y colaborando como siempre lo hace.
Muchas gracias y comentar por donde esta el camino a seguir
charli va
May 12, 2025, 11:52:02 AMMay 12
to fpga-wars-explora...@googlegroups.com
Hola Gerardo! leo tu mail con mucho respeto , creo que lo que haces tiene una complejidad importante y no estás planteando hacer "un juguete" sino algo muy serio, Desde esta visión de respeto a toda una vida profesional te doy mi punto de vista y análisis de la situación actual del as FPGAs y como digo es sólo mi opinión, puedo estar equivocado o cualquier otro puede pensar en otra dirección, yo sólo te doy mi modesta forma de ver las cosas por las experiencias que he vivido. Espero que no me quede muy largo , porque esto es una discusión que daría para horas entre amigos con unas buenas bravas y unas cañas XD, pero has entrado como elefante en una cacharrería y estás haciendo preguntas de base que son difíciles de responder "rápido".
Sobre la madurez de la tecnología de las FPGAs, ahí discrepo bastante en lo que has comentado, posiblemente creo que simplemente no has tocado las áreas en las que sí que se usan las FPGAS no es ni bueno ni malo, solo que posiblemente te has movido en entornos en los que simplemente no hacía falta usar una FPGA.
Y además se te junta otro problema que hace que te hayas abrumado y es que las FPGAs aunque utilicemos lenguajes como verilog o incluso python para "programarlas", no tiene nada que ver con la programación. Verilog no es un lenguaje de programación, es un lenguaje de descripción de hardware y esta sutil diferencia es un abismo, hay que cambiar el "chip mental". No puedes abordar un desarrollo en FPGA sin antes haber explorado el artefacto y tomar al menos, nociones de arquitectura hardware (que todo esto se aprende andando como se dice). Esto es muy importante Gerardo, tienes que meter las manos en la harina y tomarle el punto a la masa ;)
En la FPGA estás tocando los. bits por lo que requiere para cosas avanzadas tener conocimientos sobre lo que estás haciendo. No quiero desprestigiar ni decir que el programar un micro sea más fácil ni mucho menos, es algo con lo que trabajo y sé calibrar perfectamente el nivel de dificultad y complejidad de todo esto, simplemente me refiero a que es un nivel más de abstracción (dices este número es de tipo float de 64 bits o 32 y los multiplico y te olvidas), en un arduino u otro micro puedes hacer cosas que en una fpga serían complicadísimas o directamente no tendría sentido abordar y al revés, cada mundo tiene sus dificultads,sus luces y sus sombras. Una persona con conocimientos de programación, ponerse a programar micros de forma seria, le requiere un pequeño paso pero pasar a una fpga es un cambio de mentalidad y posiblemente de ampliar conocimientos.
Un tema es que a nivel educativo las usemos para todo tipo de cosas, unas veces porque sin ellas no se podría hacer , otras por puro placer de aprender las tripas de lo que hay debajo... pero otra cosa son decisiones de producto profesional.
A nivel profesional cuando a veces me preguntan, ¿oye para esto uso un microcontrolador o una FPGA? siempre digo lo mismo, si con el microcontrolador puedes resolver el problema, no uses una FPGA ya que no tiene sentido.Yo para eso soy muy pragmático, si tienes que hacer un producto tienes que poner en valor las características de lo que quieres hacer y tus necesidades y aspiraciones futuras. ¿tiene que ser lo más barato posible?¿tiene que durar el mayor tiempo posible? ¿qué condiciones físicas y de ruido electromagnético tiene que soportar? ¿velocidad, entradas y salidas, necesidad de reconfiguración....?
Y con todo eso cada arquitecto/ingeniero o como nos queramos llamar tendrá que tomar sus decisiones, acertadas o no, es parte de este "juego". Las FPGAs son una tecnología muy concreta que permite hacer una serie de cosas y tiene una serie de capacidades, lo importante es usarlas si tiene sentido hacerlo y si no, claramente no.
Las FPGAs se utilizan desde hace muchos años, yo no soy tan mayor pero si que llevo muchos años ya trabajando y las he tenido presentes en todo lo que me he dedicado desde los 2000 y en los proyectos en los que comencé trabajando, utilicé placas y diseños de tarjetas con fpgas de los años 80 y que seguían funcionando como el primer día.
Para entender por qué las FPGAs aparentemente no están más presentes hay que entender con qué estamos trabajando y esto es un tema crucial. Las FPGAs que manejamos y que llamamos FPGAs "libres" realmente no lo son, es algo que está muy mal dicho aunque lo hablemos así para entendernos. Las FPGAs son casi todas propietarias, hace no mucho se lanzó la primera FPGA open source en un crowdfunding, llamada Clear, usuarios de esta lista la tienen aunque tiene recursos muy limitados y su futuro no sé como es de prometedor ya que la empresa que las fabricaba ha cerrado recientemente dejando a bastantes proyectos importantes del mundo asic open source tirados en la estacada (estoy seguro que saldrán adelante, ¡ánimo que sois unos grandes!, que hay alguno por aquí ;) )
Y esta es la clave Gerardo, el tema de que son propietarias. Esto quiere decir que cada fabricante guarda a buen precinto su arquitectura interna y viven no sólo de vender los chips físicos, sino de vender sus entornos de desarrollo, las librerías de módulos asociadas (lo que se conoce como ips) y los cursos de formación. Esto es totalmente prohibitivo para un usuario de a pie.
Para que te hagas una idea, para un proyecto de hace bastantes años, la licencia del software de desarrollo para mi equipo de trabajo fue de entorno a 15000 euros anuales. Esto hace que trabajar con ellas sea inviable para cualquier persona normal e incluso inasumible para empresas, incluso grandes, en las que la FPGAs no forme parte de su core.
Esto solo tiene sentido en proyectos donde la FPGA es una pieza clave por sus características y que la hacen imprescindible , no podrías hacer su trabajo con ninguna otra cosa (sector aeronáutico, robótica, análisis de imagen a gran escala o super resolución, centros de datos, laboratorios, genética, análisis de red, equipos de medición de altas frecuencias, prácticametne todos los equipos médicos de los hospitales tienen fpgas dentro.....) o en negocios de gran volumen que necesitan mucha precisión, por ejemplo las impresoras plotter de HP casi todas ellas llevan entre otras cosas ,FPGAs desde hace muchos años y casi cualquier estudio de arquitectura tiene uno al menos (plotters de más de 4000 euros pero que son comunes en esa profesión). Hay miles de productos en la calle que usamos cotidianamente que llevan FPGAs.
En general todo donde hay cosas que necesitan gestionar tiemporizaciones "críticas", tratamiento de datos a altas frecuencias o gestión de muchísima precisión, llevan una FPGA.
No hay que confundir que sea una tecnología poco accesible al público general , incluso al profesional general a que no esté difundido o no sea una tecnología madura.
Todo este panorama, cambia cuando hace unos años Claire Wolf desarrolla Yosys, creo que para su tesis aunque esto no estoy muy seguro, el tema es que básicamente lo que se plantea es hacer ingeniería inversa del formato de las fpga ice40 y crear una herramienta "libre" para poder reconfigurarlas.
Y esto es donde estamos hoy, gracias a Claire , a la que le debemos todo esto que hacemos podemos utilizar FPGAs propietarias, sin pagar licencias, lo que ha generado una revolución.
El problema es que como toda revolución, al principio es un caos, y ahora aunque llevemos años, son pocos realmente y con el handicap de que cuando por ejemplo apareció Arduino, no había nada, ahora la FPGA es accesible pero está Arduino y muchos otros microcontroladores muy potentes y amigables por lo que el que entra en la FPGA libre, suele entrar proque le interesan temas concretos o tiene intereses particulares. Además no hay ninguna empresa como en el caso de Arduino , en el que su objetivo haya sido democratizar las FPGAs, no hay que olvidar que Arduino es una empresa que factura no poco dinero precisamente. Icestudio es la única herramienta que intenta acercarse al que arranca en esta tecnología de las FPGAs que como estás viendo de primeras puede ser muy arisca. No sé si lo conseguiremos pero estamos en el camino.
Ahora mismo no es que esté todo verde, hay muchas cosas hechas , cientos y miles de proyectos super interesantes, pero todo desorganizado, disperso o que requieren de un nivel de conocimientos alto para ponerlos en marcha.
En esta propia lista las cosas se diluyen en el tiempo y la información se pierde, es algo que entre todas las comunidades y herramientas se irá casi seguro de forma natural mejorando.
Con esto espero haberte dado un "marco" de situación, aquí no te vamos a obligar a usar las FPGAs para tu proyecto , ni siquiera te animaría a ello. Tienes que tenerlo claro y para eso lo que te recomendaría ya que no has trabajado nunca con esta tecnología es empezar de cero, con cosas muy básicas, si intentas abordar tu proyecto de inicio sin un entrenamiento previo que te permita tomar buenas decisiones casi seguro que fallarás.
Como has planteado que no tienes realmente prisa y las prisas nunca son buenas compañeras, te diría que en cuanto te llegue la alhambra te echaras un vistazo por los tutoriales de Obijuan.
Obijuan ha elaborado durante años una documentación excepcional, desde lo más básico hasta cosas complejas, sigue sus tutoriales, si hay cosas que conoces sáltelas pero míralos aunque sea diagonalmente porque te ayudarán a entender como va todo esto.
Sobre las TANG, Yosys que comenzó solo con esta familia de las ice40, ahora cubre muchas más FPGAS , incluso de otras marcas como por ejemplo las famosas TANG, que realmente TANG es como decir Alhambrabits, la FPGA es del fabricante chino Gowin que sería el equivalente a Latice . Aquí pasa como con el resto de FPGAs, no hay colaboración por parte del fabricante porque realemnte no les interesa, ellos quieren seguir ganando dinero vendiendo licencias, formación, etc en el caso de las TANG ya las tenemos integradas en Apio y en breve estarán disponibles en icestudio, pero el soporte es aún muy limitado. Como también se está haciendo ingeniería inversa, hasta hace poco no se tenía ni acceso a las BRAMS para que te hagas una idea. Yo no te recomendaría usar las Gowin para tu proyecto, el mercado asiático es mucho más voluble que el europeo, por ejemplo un modelo de TANG de hace un año que compré para la integración con Icestudio, hoy ya no se vende(salió hace un año y literlalmente se lo han cargado), eso en Lattice no te va a pasar. Además el soporte aún es muy limitado.
Otra cosa es que quieras usar los entornos de desarrollo y las librerías de Gowin que son gratuitas (pero no libres) que ahí tienes un montón de módulos listos para usar, pero como te digo cuidado con esto si miras a largo plazo , más por los tiempos de vida y facilidad de distribuciónd e los chips.
Espero no haberte aburrido mucho y que esto te haya ayudado a entender mejor "donde te metes", en cualquier caso ya sabes que eres bienvenido y que siempre intentaremos ayudarte en lo posible.
Saludos!
beni...@gmail.com
May 12, 2025, 12:30:21 PMMay 12
to FPGAwars: explorando el lado libre
Hola Gerado,
En tu comentario hay varias cosas que me han sorprendido y creo que eso te esta llevando a una cierta incentidumbre con las FPGAs.
Estoy totalmente de acuerdo con lo que ha posteado Chaliva, las FPGAs no son nuevas ni mucho menos.
Lo que ocurre es que para los programadores informaticos tradicionales son un nuevo paradigma. Por que digo esto? Porque en realidad el uso de las FPGAs es mas cercano a los ingenieros electronicos que a los informaticos
Lo que ocurre es que para los programadores informaticos tradicionales son un nuevo paradigma. Por que digo esto? Porque en realidad el uso de las FPGAs es mas cercano a los ingenieros electronicos que a los informaticos
Con la FPGA estas implementando circuitos logicos, es decir estas muy cercano a la arquitectura de ordenadores, algo es muchisimo mas complejo que programar secuencialmente, y ojo que programar no es nada facil tampoco.
Por tanto lo primero que hay que plantearse antes de comenzar un nuevo proyecto que necesidades se tienen.
Siempre que se puede se hara de la manera mas sencilla y economica, y normalmente se utilizan microcontroladores para ello , tipo Arduino, STM32, ESP32 , etc
Solo en el caso de que se requiera especificaciones criticas no abarcables con estos microcontroladores es cuando uno puede plantarse el uso de una FPGA.
Siempre que se puede se hara de la manera mas sencilla y economica, y normalmente se utilizan microcontroladores para ello , tipo Arduino, STM32, ESP32 , etc
Solo en el caso de que se requiera especificaciones criticas no abarcables con estos microcontroladores es cuando uno puede plantarse el uso de una FPGA.
Pero claro, una FPGA no es nada sencilla de configurar. De hecho, IceStudio ha sido creado para facilitar muchisimo el modo de generar bitfiles para la FPGA. Es una programacion mas visual y mucho menos engorrosa que picar codigo Verilog o VHDL a mano.
El mercado actual de las FPGAs esta mas orientado al mundo profesional, en donde los ingenieros electronicos son los que mas las utilizan para sus proyectos.
Para ponerte un ejemplo, aqui en USA contrataron a un Master en ingenieria electronica para trabajar en una empresa que colaboraba con el departamento de defensa y para ese puesto se requeria el conocer bien las FPGAs Xilinx.
Las FPGAs Xilinx se usan muchisimo a nivel profesional en temas militares, de hecho el principal uso que se le da a las FPGAs de Xilinx es el uso militar. La razon es clara, es mucho mas facil controlar la fabricacion de nuevos desarrollos militares si no se tiene que fabricar los Chip ASIC externamente. Se usan FPGAS y se mantiene el secreto militar mucho mas facilmente sin necesidad de contratar empresas externas de fabricacion. TODA la parte critica de la implementacion se hace sobre FPGAs y ademas en el caso de Xilinx cada chip FPGA Artix 7 y superior tiene un numero de ID unico, y cuando se genera el bitfile se personaliza para ese numero de ID, ese bitfile solo funcionara sobre ese chip FPGA unico
Para ponerte un ejemplo, aqui en USA contrataron a un Master en ingenieria electronica para trabajar en una empresa que colaboraba con el departamento de defensa y para ese puesto se requeria el conocer bien las FPGAs Xilinx.
Las FPGAs Xilinx se usan muchisimo a nivel profesional en temas militares, de hecho el principal uso que se le da a las FPGAs de Xilinx es el uso militar. La razon es clara, es mucho mas facil controlar la fabricacion de nuevos desarrollos militares si no se tiene que fabricar los Chip ASIC externamente. Se usan FPGAS y se mantiene el secreto militar mucho mas facilmente sin necesidad de contratar empresas externas de fabricacion. TODA la parte critica de la implementacion se hace sobre FPGAs y ademas en el caso de Xilinx cada chip FPGA Artix 7 y superior tiene un numero de ID unico, y cuando se genera el bitfile se personaliza para ese numero de ID, ese bitfile solo funcionara sobre ese chip FPGA unico
Por tanto, no es nada baladi trabajar con FPGAS, ten en cuenta que estamos trabajando sobre una tecnologia muy avanzada en implementaciones con un alto nivel de abstraccion en un nuevo paradigma. Si a eso le sumas la dificultad que requiere el debugear sobre una FPGA, se complica muchismo el tema.
No te quiero desanimar, pero la curva de aprendizaje de las FPGAs es muy larga y practicamente horizontal, y eso lleva a la fustraccion muy facilmente. Es algo que se sabe y por algo es una tecnologia que cuesta mucho dominar. Pocas personas hay en este sector que dominen bien esta tecnologia, muy pocas. Preguntate el por que de ello.
Venga , te animo a que no tires la toalla, empieza con la Alhambra y siguiendo los excelentes tutoriales de Obijuan vayas avanzando en esa cuerva de aprendizaje poco a poco.
Aqui estamos todos para ayudarte en ese camino
Un Saludo
Fernando Mosquera
Gerardo Tenreiro Vazquez
May 12, 2025, 12:43:00 PMMay 12
to fpga-wars-explora...@googlegroups.com
Muchas gracias Carlos por la gran explicación. Todo lo que escribes estoy de acuerdo y me lo tomo como una gran lección.
Puede que de mi mensaje anterior entendáis que estoy decepcionado o reproche algo de las FPGA, pero no. Solo transmito mi punto de vista actual y os pido vuestro consejo de por dónde tirar o por donde buscar.
Yo empecé con puertas lógicas , los primeros dispositivos de automatización eran simples puertas AND, OR, XOR, NOT... conectadas con hilos retorcidos por la parte trasera del PCB y así se generaba la secuencia de funcionamiento de cualquier cosa. (Hablamos del 70)
De las puertas lógicas pase a los secuenciadores neumáticos de tarjeta perforada o banda en el mejor de los casos, si las puertas lógicas tenían mucha miga la neumática mucho más.(Sobre los 80)
Después el gran paso, micro de 8 bit y 1 o 2 Kb de memoria programados en ensamblador directamente, cada micro con su set de instrucciones, sus registros y acumuladores, nada era igual y todo cambiaba a mucha velocidad, pasar a 16 bit ya era imposible en ensamblador así que todo fue un cambio, pero llegamos a la era actual donde todo es más fácil aparentemente.
Llevo años viendo los tutoriales de Obijuan, el cual admiro y le estoy muy agradecido por ellos, lee todo lo que puedo de FPGA, me gusta avanzar e innovar. Siempre intento utilizar la tecnología que mejor se adapte al proyecto por eso en este caso que la medida de tiempos es muy importante, el procesamiento en paralelo de la lectura de dos canales también es muy importante, que poder actualizar el HARDWARE por software sería muy novedoso y valioso y por algunas razones menores fue por lo que decidí dar el paso e intentar utilizar una FPGA LIBRE.
En este punto estoy y únicamente os comento mi situación, estoy cada día más perdido, aún no he definido ni la FPGA ni la capacidad, ni la memoria ni dada.
No penseis que empecé hace un mes en esto, llevo desde principios de año dedicando tiempo y abusando de vuestra amabilidad os transmito mi situación.
Ya os comento que no me voy a dar por vencido fácilmente, que estoy convencido que una FPGA será la que realice el proceso necesario para que el equipo funcione lo mejor posible. También os comento esto no va a ser fácil ni rápido, pero va a ser. Se que el equipo no es fácil, el anterior tardó unos 4 años en tenerlo operativo, verificado y en predisposición a su distribución, este no creo que sea menos.
Estáis haciendo un gran trabajo para el futuro, entiendo que las FPGA LIBRES seguirán avanzando y coordinandose . Entiendo que cada día que pasa los temas se centran más y que en un futuro todo estará más centrado y maduro, pero mientras tanto hay que seguir adelante y Yo seguiré avanzando, no se si con paso firme o a bandazos pero seguiré.
Estoy ansioso de conocer el nuevo ICESTUDIO dentro de estos avance
Muchas gracias grupos y cualquier recomendación de por donde tirar será muy bien acogida.
Despues pasamos a los micros en lenguaje ensamblador, a mano y sin mas
Gerardo Tenreiro Vazquez
May 12, 2025, 12:54:46 PMMay 12
to fpga-wars-explora...@googlegroups.com
Muchas gracias Fernando por el apoyo
No estoy desanimado, solo os comento mi situación al respecto del proyecto.
Sé que la curva de aprendizaje es difícil pero también sé que las posibilidades son muchas. Una FPGA sería perfecta para el proyecto, de eso estoy seguro.
En el mensaje anterior ya os comente que empecé, hace muchos años, con puertas lógicas, antes que los micro estuvieran disponibles a un precio razonable, me arte de hacer armarios de alarmas de buques, controles de carga y de todo con simples puertas lógicas sin más.
Se que el inicio en todo es complicado y veo que con las FPGA es mas, o por lo menos es mi apreciación.
Esta es mi situación y así os la transmito.
Espero centrar algo el proyecto y mientras cuendo tenga la ALHAMBRA II trasteare e intentaré avanzar
Muchas Gracias grupo.
charli va
May 12, 2025, 12:58:57 PMMay 12
to fpga-wars-explora...@googlegroups.com
Ánimo Gerardo! para nada malinterpreté tu correo, aquí estamos para compartir conocimientos y ayudarnos, para esos somos comunidad ;)
Poco a poco, como te he dicho Fernando la curva de aprendizaje es alta, aunque parezca fácil inicialmente y sobre todo con los primeros ejemplos de Icestudio pero luego aunque se haga farrogoso y difícil, también empieza a verse la luz y al revés se convierte en algo muy satisfactorio.
Date tiempo y sobre todo experimenta ;)
beni...@gmail.com
May 12, 2025, 4:12:10 PMMay 12
to FPGAwars: explorando el lado libre
Por cierto Charliva, menos mensajes y a ver si nos sacas la nueva version del ICeStudio pronto 8-))))))))
Ja ja ja ja ja ja ja
Un Abrazo a todos
charli va
May 12, 2025, 5:02:57 PMMay 12
to fpga-wars-explora...@googlegroups.com
En ello estoy! pero me crecen los problemas como si fuera un vergel XD. He estado evitando años cambiar el motor gráfico y ha sido como la típica peli en la que va el coche con la rueda a punto de slirse sujeta por la última rosca de la tuerca, llevo viendo la tuerca a punto de salirse años y al final he tenido que parar para no descarrilar.
Ahora mismo es el tapón que me tiene mil cosas en cola bloqueadas, en cuanto libere esta parte os tendré fritos a cosas nuevas ;)
Reply all
Reply to author
Forward
0 new messages