Playing with Combinational Loops

[Jesus Arias]

Hola,

Adjunto el resultado de algunos experimentos recientes ;)

Hi,

I'm attaching some recent experiment results ;)

[charli va]

Hola Jesús! como siempre temas super interesantes. Estos días probaré lo que has propuesto en el documento , me ha parecido bastante sorprendente que puedas llegar a generar un reloj de vídeo lo suficientemente estable para generar las imágenes que has mandado.

Me ha recordado un artículo que leí hace tiempo, por si te es de interés y no lo conocías : https://hackaday.com/2015/09/27/mystery-fpga-circuit-feels-the-pressure/

*****

Hi Jesus! As always, super interesting topics. These days I will try what you have proposed in the document, I found it quite surprising that you can generate a video clock stable enough to generate the images you have sent.

It reminded me of an article I read a while ago, in case it's of interest to you and you didn't know about it: https://hackaday.com/2015/09/27/mystery-fpga-circuit-feels-the-pressure/

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/1abdb09b-8e6f-4dcb-96e5-7c81979df8d0n%40googlegroups.com.

[Jesus Arias]

Hola de nuevo,

Es muy curioso ese vídeo. Parece que la frecuencia del oscilador (de nada menos que 100 buffers en el anillo) varía con la deformación de la placa, o del propio chip. A cosas como esas me refería con "las fases de la Luna" ;)

De todos modos he seguido probando otros circuitos, en este caso latches. Parece que todos funcionan bien.

Saludos

[Democrito]

Yo también me quedé flipando. Cuando se enciende el led verde (que es central de la Icestick) es la pulsación sobre la placa, y con los led rojos hace el conteo circular, es decir y para los demás que no hayan visto el vídeo, cada vez que se presiona la placa el led se desplaza una posición dentro de los 4 led rojos que tiene. Una flipada total con pepinillos y en colores. Otra cosa que me llamó mucho la atención, mirando otros enlaces relacionados, es el de crear números aleatorios, aparentemente no-pseudoaleatorios (que una raíz, dentro de un algoritmo, "aparente" aleatoriedad real), según parece con este tipo "estructura" (esto no sé si lo he entendido bien), se puede hacer aleatoriedad real (como medir el ruido de un diodo en temas analógicos), no simulada.

1.) Vídeo donde se ve lo que he comentado al comienzo:

      https://www.youtube.com/watch?v=UFqWjZudOho

2.) Sobre la entropía y aletoriedad con una FPGA: (por cierto, muy gráfico y para gente como yo se agradece)

      https://www.iacr.org/workshops/ches/ches2011/presentations/Session%201/CHES2011_Session1_2.pdf

Todo lo que he comentado me supera 50 pueblos (derrapando esos 50 pueblos), pero entiendo que dentro de estos temas se esconden temas realmente interesantes.

[charli va]

ENGLISH BELOW

Hola a todos! he estado implementando el documento de Jesús, la verdad que los resultados me han sorprendido, el reloj es bastante "limpio" tengo que hacer más pruebas pero me ha parecido más preciso que el PLL de la FPGA (hay que medirlo bien pero visualmente lo parece).

También agradecer a Demócrito los enlaces,siempre tener referencias es super interesante así que millones de gracias por la info, tenemos que hacer un repo de enlaces para que no se desperdigue la información XD pero bueno eso es otra batalla.

Volviendo a nuestros anillos, he hecho las pruebas con la Alhambra II, para que más usuarios podáis probarlo si queréis, aunque mañana haré pruebas con la icecream y alguna otra placa que llevan la ice40 por ver como se comporta en cada una.

He implementado un ripple counter de 3 bits para dividir el reloj generado por 2,4 u 8, suficiente para cubrir aparentemente la máxima velocidad medida por Jesús (en el mejor de los casos en torno a 700Mhz que podríamos medir con el divisor de 8, entorno a 87Mhz, algo ya asumible por un osciloscopio de 100Mhz).

He hecho de momento solo dos tests uno con un ring oscilator con un buffer de 4 ff, en este caso la medida se aproxima mucho al documento de Jesús, os adjunto la captura (20Mhz detectados por el osciloscopio en continuo lo que quiere decir que dentro el oscilador en anillo va a 160Mhz aproximadamente, lo que cuadra bastante con la gráfica de Jesús):

La siguiente prueba he bajado el número de buffers a 1 (máxima frecuencia), aquí el osciloscopio muestra entorno a 58Mhz (oscila un poco 55-58-60) lo que vendría a significar una frecuencia del oscilador en el peor de los casos de 440Mhz, posiblemente no llego a la velocidad de Jesús porque en mi ejemplo no se pueda llegar a una frecuencia mayor, esto haré pruebas y quitaré el anillo para ver sin loops que análisis de tiempos da y ver si cuadra pero tiene buena pinta la verdad:

Para el que quiera apuntarse a este fiesta y no sepa por dónde empezar os paso estos tres ejemplos sencillos para Icestudio. Ahora mismo parte del proceso (generar el bitstream y flashearlo) hay que hacerlo desde línea de comandos, pero voy a cerrar unas mejoras que andaba preparando para poder pasar parámetros personalizados en icestudio, así que si os parece bien lo voy a preparar para que con este ejercicio de paso me valga para testear bien la funcionalidad (2x1! alguien da más? :) )

1) ring0.ice , este ejemplo sólo contiene el ripple counter (es un simple contador pero con la peculiaridad que los relojes de cada flip flop son la salida del anterior. En vez de implementarlo en verilog lo he hecho con bloques porque es algo muy sencillo y para educación queda muy visual. En este ejemplo símplemente con el pin SW2 hacéis de reloj y vais a ir viendo avanzar el contador en los leds. Este ejemplo funciona directamente desde Icestudio.

2) ring1.ice, este ejemplo libera el reloj ddel ripple counter del botón y utiliza directamente el de la alhambra II (12Mhz), tenéis que pulsar el sw2 para que funcione (reset) se encenderá el led6 y todo arrancará. Para visualizar este ejemplo debéis conectar el osciloscopio, podéis hacerlo al pin D1, al D2 o al D3 (o al D13 que contiene el reloj de 12Mhz por referencia). El D1 es el reloj del sistema dividido por 8 , el D2 por 4 y el D3 por 2, funciona perfecto. Esto es un ejemplo del ripple counter bajo un reloj real y que me valiera como prueba de que obtendrá algo con cierta exactitud (la verdad que a 12Mhz las medidas salen clavadas), este ejemplo funciona directamente desde Icestudio.

3) ring2.ice, aquí ya está el oscilador en anillo, el ejemplo funciona como el 2) (los pines para medir con el osciloscopio) y en el diseño podéis cambiar el número de buffers del anillopor si queréis probar. Este ejmplo requiere de momento de ejecución de comandos fuera de Icestudio, ahora os explico.

Para probar este último ejemplo, lo que tenéis que hacer es con icestudio darle a sintetizar, esto generará parte de los ficheros necesarios en la carpeta ice-build donde tengais el .ice.

Luego os vais y abrís un termina. os vais dentro de la carpeta ice-build correspondiente y tendréis que ejecutar a mano:

RUTA_OSS_CAD_TOOL/nextpnr-ice40 --hx8k --package tq144:4k --json hardware.json --asc hardware.asc --ignore-loops  --pcf main.pcf

RUTA_OSS_CAD_TOOL/icepack hardware.asc hardware.bin

RUTA_OSS_CAD_TOOL/iceprog hardware.bin

RUTA_OSS_CAD_TOOL es la ruta a la carpeta de usuario de icestudio y luego depende del sistema operativo una ruta similar a la que os pongo:

~/.icestudio/apio/packages/tools-oss-cad-suite/libexec

esa es mi ruta en mi linux, pero seguro que con esto podéis encontrarla sin problemas, y si no preguntad y os ayudamos.

Se me acumula el trabajo 😅 pero esto está siendo muy divertido, estos días intentaré mezclar unas cosas que ando trabajando del PAL y del PET con esto y así vamos avanzando todos los temas a la vez.

Un abrazo a todos!

ENGLISH::

Hello everyone!

I've been implementing Jesús's document and the results have really surprised me. The clock is quite "clean". I need to do more tests, but it seems more precise than the FPGA's PLL (this needs to be measured properly, but visually it seems so).

I also want to thank Demócrito for the links. Having references is always super interesting, so many thanks for the info. We need to create a repository of links to keep the information organized, but that's another battle.

Going back to our rings, I did the tests with the Alhambra II, so more users can try it if they want. Tomorrow, I'll test it with the Icecream and some other boards that use the ice40 to see how it behaves on each.

I implemented a 3-bit ripple counter to divide the generated clock by 2, 4, or 8, which is enough to apparently cover the maximum speed measured by Jesús (in the best case around 700 MHz, which we could measure with the 8-divider at around 87 MHz, something manageable by a 100 MHz oscilloscope).

So far, I've only done two tests. One with a ring oscillator with a buffer of 4 flip-flops. In this case, the measurement closely matches Jesús's document. I attach the capture (20 MHz detected continuously by the oscilloscope, which means the ring oscillator is running at about 160 MHz, which fits well with Jesús's graph):



In the next test, I reduced the number of buffers to 1 (maximum frequency). Here, the oscilloscope shows around 58 MHz (oscillates a bit between 55-58-60), which would mean the oscillator's frequency, in the worst case, is 440 MHz. I might not reach Jesús's speed because my example might not achieve a higher frequency. I will test and remove the ring to see the timing analysis without loops and see if it matches, but it looks promising:



For anyone wanting to join this adventure and doesn't know where to start, here are three simple examples for Icestudio. Right now, part of the process (generating the bitstream and flashing it) needs to be done from the command line, but I'll finish some improvements I was preparing to allow passing custom parameters in Icestudio. So if it’s okay with you, I'll prepare it so that this exercise can also be used to test the functionality well (2x1! Who offers more? :) )

1) ring0.ice: This example only contains the ripple counter (it's a simple counter, but with the peculiarity that each flip-flop’s clock is the output of the previous one). Instead of implementing it in Verilog, I did it with blocks because it's very simple and visually educational. In this example, you simply use the SW2 pin as the clock and see the counter advancing on the LEDs. This example works directly from Icestudio.

2) ring1.ice: This example frees the ripple counter clock from the button and directly uses the Alhambra II's clock (12 MHz). You need to press SW2 to start it (reset), LED6 will light up, and everything will start. To visualize this example, you need to connect the oscilloscope. You can do this to pin D1, D2, or D3 (or D13, which contains the 12 MHz reference clock). D1 is the system clock divided by 8, D2 by 4, and D3 by 2. It works perfectly. This is an example of the ripple counter under a real clock and served as a test to see if it gets something accurately (at 12 MHz, the measurements are precise). This example works directly from Icestudio.

3) ring2.ice: Here is the ring oscillator. The example works like ring1.ice (pins for measuring with the oscilloscope), and you can change the number of buffers in the ring if you want to test it. This example currently requires running commands outside of Icestudio. Here's how to do it:

To test this last example, you need to synthesize it with Icestudio, which will generate part of the necessary files in the ice-build folder where the .ice file is located.

Then, open a terminal, navigate to the corresponding ice-build folder, and execute manually:


PATH_TO_OSS_CAD_TOOL/nextpnr-ice40 --hx8k --package tq144 --json hardware.json --asc hardware.asc --ignore-loops --pcf main.pcf
PATH_TO_OSS_CAD_TOOL/icepack hardware.asc hardware.bin
PATH_TO_OSS_CAD_TOOL/iceprog hardware.bin


PATH_TO_OSS_CAD_TOOL is the path to the Icestudio user folder and then depends on the operating system, something similar to what I put here:


~/.icestudio/apio/packages/tools-oss-cad-suite/libexec


That's my path on Linux, but with this, you should find it without problems, and if not, ask and we'll help you.

Work is piling up 😅 but this is very fun. These days I'll try to mix some things I'm working on with the PAL and the PET with this, and we'll advance everything together.

Hugs to everyone!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a42a2810-c245-4624-b1df-493520ce079an%40googlegroups.com.

[Jesus Arias]

Hola Democrito, gracias por la información.

El enlace 2) (MIT) es muy interesante, aunque no veo cómo va a depender el retardo de una LUT   de sus bits MSB. Para mí todos los posibles caminos de la señal deberían tener unos retardos muy similares. Esto es algo que tengo que probar...

Saludos

[Jesus Arias]

Hola Carlos,

Me parece que las resistencias en serie de los pines están filtrando las frecuencias altas y lo que ves en el osciloscopio no se parece mucho a ondas cuadradas. Tienes que dividir la frecuencia bastante más (Yo usé un contador  de 10 flip-flops para dividir por 1024)

Saludos

[charli va]

Le ponemos un condensador y casi nos sale un seno XD, soy consciente de las resistencias que están muy bien para muchas cosas pero para estos temas siempre amortiguan" o se cargan la señal pero pensaba que aunque deforme la onda cuadrada, la frecuencia sería correcta (porque la de 12 que sabemos que es de 12 sale igual y detectada correcta, de todas formas mañana amplío el ripple para tener divisores mayores.

Mañana la probaré en la icecream ;) y en alguna otra placa que tengo con la misma fpga y que no tiene salidas con resistencias.

Esto me ha quitado el sueño XD lo primero que pensé cuando leí lo de "las fases de la luna" fue en números aleatorios, siempre tan necesarios y tan difíciles de generar y la verdad que con el documento que pasó Demócrito se me están ocurriendo algunas ideas que voy a intentar poner en marcha, si mañana sale algo ya os cuento.

Sobre el tema de retardos, leyendo sobre osciladores en anillo, estoy viendo que casi todo el mundo enlaza las puertas not en números impares, en vez de una not y buffers en nuestro caso. No sé si al implementar NOTs consecutivas ls retardos entre puertas se harán más aleatorios.

Posiblemente ya lo conozcas pero si ejecutas nextpnr-ice40 --gui  se abre una interfaz en la que puedes ver el despliegue de puertas ,luts y conexiones sintetizado y no sé si tiene alguna herramienta de medición de retardos, nunca he profundizado tanto en eso pero lo miraré.

Esta herramienta muchas veces no arranca por tema de librerías y suele ser un dolor si no te va a la primera o la segunda, si no te va igual lo conoces pero por si acaso dejo la referencia: https://knielsen.github.io/ice40_viewer/ice40_viewer.html   esto lo estoy integrando en icestudio y aunque es muy básico puedes subir el fichero asc y de una forma simplificada ver la síntesis, no puedes medir latencias pero si ver los trazados, muchas veces es curioso ver como en vez de agrupar los recursos los desperdiga trazando rutas enormes de punta a punta.

Buenas noches!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/9417a511-f087-497e-a164-07c6da09c6een%40googlegroups.com.

[charli va]

Buenas amigos! os paso una foto de la señal de 12Mhz saliendo por el pin de la alhambra II pasando luego por un filtro para intentar recuperar las frecuencias filtradas por la resistencia de serie de la placa (me apetecía hacer el ejercicio). Parece que ha tomado mejor pinta de señal cuadrada, habría que ajustar un poco más los cálculos pero creo que va por buen camino, la foto está en medida en contínuo no en captura single (a mi esto me suele dar pistas de si la señal se genera bien, de forma periódica,etc):

Me ha sorprendido que al aplicar el filtro y volverse más cuadrada, el osciloscopio detecta la frecuencia literalmente exacta, esto nunca me había pasado con la alhambra, ya estaba acostumbrado a los bailes y jugar siempre en modo difuso 😆

Era sólo un inciso entorno a los osciladores 😅 ando planificándome en papel pruebas que quiero hacer estos días a ver si cunde, si os parece bien y creéis que puede ser útil voy a mejorar la interfaz web del otro día , avanzando la parte del analizador lógico para poder pintar números aleatorios y también que nos valga como una forma sencilla de descargarnos datos a un fichero para poder pintarlos o trabajarlos con otras herramientas.

Buen comienzo de día!

[Jesus Arias]

Hola

He conseguido reproducir las dependencias de los retardos con factores como los que se tenían en los enlaces de Democrito.

Estas figuras las he obtenido con un anillo de 100 buffers sintetizado junto con un frecuencímetro. Las frecuencias medidas las he traducido a retardos por LUT.

En esta figura he presionado con un rotulador sobre el chip un par de veces. El rotulador era para no calentar el chip. Este efecto parece que se observa mejor con anillos de muchos buffers.

Si se calienta el chip con la mano, sin presionar mucho, y luego se deja enfriar tenemos esta gráfica:

Y también he usado los bits que sobran en las entradas de las LUT (3 bits) como señales de control de retardos, y desde luego se observa una dependencia de los retardos con los valores binarios de las entradas. Otra cuestión es interpretar estos resultados...

Las LUTs estaban configuradas así:

//inversor:

SB_LUT4 #(.LUT_INIT(16'h5555)) bufinv (.O(cktap[0]),.I0(cktap[NRING-1]), .I1(tun[0]), .I2(tun[1]), .I3(tun[2]));

//buffer:

SB_LUT4 #(.LUT_INIT(16'hAAAA)) bufbuf (.O(cktap[i]),.I0(cktap[i-1]), .I1(tun[0]), .I2(tun[1]), .I3(tun[2]));

anillo de 1 buffer:

anillo de 4 buffers:

anillo de 100 buffers:

[charli va]

Que interesante Jesús! ¿cómo has medido los retardos?me refiero a que el frecuencímetro entiendo que va sincronizado con el reloj de la placa para tener una referencia exacta de la que fiarte y ahí es donde no entiendo muy bien como mides algo que va mucho más rápido. Seguro que me estoy perdiendo algo por el camino,  si no te importa explicarlo,  es algo que me interesa mucho.

Veo en las gráficas que representas sólo los bits más significativos ¿esto es porque es donde más se nota el retardo? (igual no lo he entendido bien)

Muchísimas gracias por compartir tu trabajo, es un disfrute.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3f5114f8-12b1-47d7-8e99-752abbe31e43n%40googlegroups.com.

[Democrito]

Esto pinta muy muy bien, es como si nos estuviéramos acercando al extraño mundo cuántico!

Me hago preguntas parecidas a la que se hace Carlos.

Muchas gracias por tomarte las molestias de crear y compartir los gráficos, amén de crear el circuito, realizar pruebas, etc!

[Democrito]

Me ha venido a la cabeza qué sucedería si se pone un imán encima, o si ese imán se mueve (en plan ley de Faraday). Me pregunto si tendría algún efecto.

[Jesus Arias]

Hola a todos

El imán no parece tener un efecto apreciable en la frecuencia

Y la medida de la frecuencia me ha dado algún que otro quebradero de cabeza. Al final uso un contador de rizado con reset asíncrono. Incluyo los fuentes.

Saludos

[charli va]

Buenos días! mil gracias Jesús por el código!

Yo estoy jugando con la búsqueda de aleatoriedad basándome en los resultados de Jesús de los retardos, con la idea de que existe cierta aleatoriedad "física" en ellos.

Estoy con las primeras pruebas de concepto, pero son muy prometedoras:

De momento he probado un esquema muy básico de generador de entropía, símplemente utilizando 4 osciladores con la misma longitud (100 buffers) y tomar el bit msb como parte del cuarteto del número aleatorio (aunque teóricamente son iguales, cada uno variará ligeramente su oscilación por los retardos) las próximas pruebas jugaré a ir reduciendo el tamaño del buffer para ver si la aleatoriedad se mantiene o baja y  a distintos tamaños de buffer por oscilador para ver si se gana entropía.

Como estoy utilizando de momento sólo 4 bits, solo genero números aleatorios de 0 a 16, aunque el 0 nunca aparecerá (ahora lo estoy descartando porque más adelante voy a aplicar un extractor de aleatoriedad y los ceros se pierden y no quiero tenerlo en cuenta).

Sinceramente no me esperaba el resultado. aunque sean sólo números de 4bits, se rellena todo el espectro y eso no me lo esperaba sin más artificios adicionales. 

En las gráfica superior veis por un lado el histograma de aparición de números (es decir cuantas veces aparece cada número en las muestras tomadas).

En la otra cojo secuenciálmente los números generados como pares x,y para pintarlos en el espacio 2D, esto quería verlo porque en cuanto amplíe el número de bits utilizaremos el método de Montecarlo para ver lo bueno o malo que es el generador de números aleatorios, para el que no lo conozca luego lo explicaré cuando mande el resultado pero es un método en el que visualmente se ve si la distribución aleatoria es pseudoaleatorio o aleatoria real y en ambos casos como de buena es esa aleatoriedad. Hay otros métodos numéricos más potentes pero a mi Montecarlo me gusta mucho porque es muy visual y para lo que nos atañe inicialmente más que suficiente.

Ahora tengo que salir para ocuparme de taréas mundanas del mundo real XD pero a la vuelta sigo con ello y os mandaré el código. Estoy preparándolo para que sean verilogs que se puedan utilizar fuera de icestudio y luego un .ice para el que quiera probarlo desde icestudio o ver la arquitectura general de un plumazo. Aunque el código es super sencillo seguro que puede venir bien tenerlo fuera.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/0e2ef1af-aad7-465e-8a5e-2a06ae812155n%40googlegroups.com.

[Jesus Arias]

Hola,

Simplemente adjunto una foto de un equivalente al diseño del frecuencímetro:

¡¡¡Y parece que todavía funciona!!!

Desde luego los sistemas digitales en FPGA son mucho más descansados ;)

Abrazos

[Democrito]

Madre mía, qué viejos tiempos! Me ha parecido ver que todos los chips son CMOS.

La frase: "Desde luego los sistemas digitales en FPGA son mucho más descansados" me ha hecho mucha gracia porque además es verdad!

[charli va]

Una pasada y una maravilla que aún funcione, este tipo de prototipos son incombustibles XD

La verdad que aunque ahora con las FPGAs llevemos una vida más "descansada" 😆 para las personas que comienzan sus estudios o se inician en la electrónica me da pena que muchos no lleguen a tocar nada de este tipo de montajes.

Por cierto Tim Rudy (usuario de la lista y que suele colaborar en Icestudio) tiene en verilog implementada gran parte de la fmailia TTL 74 https://github.com/TimRudy/ice-chips-verilog por si os da curiosidad u os es útil.

Un abrazo y buena tarde!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a114e81f-7807-4744-9617-166766c8b4can%40googlegroups.com.

[charli va]

Buenas a todos! he seguido avanzando con unos pequeños tests:

1) He generado números de 16bits burdamente:

a) como en el ejemplo de esta mañana hay 4 anillos iguales y con el bit más significativo de cada uno se hace una tupla de 4 bits

b) la tupla se pasa por uno secuencia de 4 registros, de forma que tenemos en un momento dado 16bits entre todos los registros.

c) a una frecuencia baja de muestreo para evitar repeticiones se capturan los 16bits y se mandan por el puerto serie para su guardado.

2) Con este generador tan básico el resultado es bastante espectacular, he aplicado el método de Montecarlo para el cálculo dle número PI.

No me quiero extender mucho aquí, quiero preparar un documento bien detallado pero la idea es la siguiente:

a) Sabes que PI está relacionado con el área de un círculo. Si dibujas un cuadrado de lado 2 y un círculo de radio 1 dentro de ese cuadrado, el área del círculo será π y el área del cuadrado será 4.

b) Generas muchos pares de números aleatorios (x, y) dentro del cuadrado de lado 2 (normalizamos los valores generados porel oscilador entre -1 y 1.

c) Para cada par (x, y), determinas si cae dentro del círculo o no. La condición es x2+y2≤1

d) Cuentas cuántos puntos cayeron dentro del círculo.

e) El ratio de puntos dentro del círculo respecto al total de puntos generados te da una aproximación de π/4. Multiplicas este ratio por 4 para obtener una aproximación de π.

Bien, pues la aproximación de PI con esta generación tan burda es 3.281173 !!!!

Os paso el gráfico del test de montecarlo como veis, se aprecia cierto patrón en la muestra pero está muy bien distribuido:

En C en mi equipo, la aproximación es muy buena, estimación de Pi: 3.140794, como veis en el gráfico  sale casi completamente relleno. Esto se debe a que en el equipo que estoy probando esto (un mac m1), la cpu lleva un chip criptográfico apra encriptar y desencriptar el disco en tiempo real y la librería de c utiliza esto para generar números aleatorios , tomaremos esto como referencia a ver si conseguimos acercarnos en futuras pruebas.

He probado a modificar el número de elementos en el buffer y no varía demasiado el resultado.

Mañana mejoraré la generación del número aleatorio y a ver que va saliendo.

Un abrazo!

[Democrito]

Una pasada Carlos! Muchas gracias!

[charli va]

Gracias a vosotros por compartir estos momentos e inquietudes! mañana os paso el código que quiero organizarlo en verilog y al mismo tiempo instanciado en icestudio y para no andaros mareando. También os pasaré los generadores de las gráficas para gnuplot y los programitas en c para lo de montecarlo que es una tontería pero igual os apetece tenerlo

El sáb, 8 jun 2024 a las 20:47, Democrito (<spo...@gmail.com>) escribió:

Una pasada Carlos! Muchas gracias!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/7147b6cd-5f41-4d80-9c13-aca11c019cd3n%40googlegroups.com.

[charli va]

He estado haciendo unas pruebas utilizando el oscilador como reloj.

Aparentemente todo está llendo bastante bien, habrá que ver si hay alguna forma de luchar contra glitches y ver la estabilidad pero os paso la primera prueba "gorda"

La prueba que he hecho es literalmente cambiar el reloj por el oscilador pasando por el contador en rizo y trabajar a una frecuencia máxima entorno a 60Mhz (ya probaremos a más velocidadd que no quiero quemar la FPGA XD )

Aunque como veis en el vídeo se desincroniza un poco , el movimiento va muchísimo más fluido, si lo probais , cuando se desincroniza teneis que desplazar hacia abajo la terminal( debe fallar el envío o pisarse el borrado de página y vuelta al comienzo), esto no le deis importancia ahora mismo porque he utilizado este experimento que se hizo rápido y no tienen ningún tipo de control de flujo y en el original a veces también hay desincronizaciones.

Como primera prueba par ver si el oscilador puede ser un reloj válido para algo complejo me ha parecido más que buena, no sé que opináis. El test es un pequeño raytracer que renderiza un toro rotando (los colores se convierten en caracteres ascii que simulan la luminosidad), está todo lleno de cálculos, rotaciones de bits a lo bestia y hay comunicación con puerto serie (también con el oscilador). Os dejo aquí el vídeo a buena resolución:

https://youtu.be/TfGKByTtSxE

 Como veis la FPGA va "hasta arriba"

Os mando los bitstreams para la alhambra-ii he estado haciendo pruebas en la icecream y en la icebreaker pero os paso los de la alhambra porque habrá más gente que las tenga y quieran probarla. Lo mismo que lo anterior os pasaré el código mañana o pasado  porque es algo que hice rápido y no está muy ordenado que se diga.

Lo dicho os dejo el bitstream normal (el que se llama donut) este tenéis que configurar la uart a 921600 bps.

En el dopado con el anillo,  tenéis que poner la uart a 1Mbps, si usais la terminal de icestudio esta es la configuración, si usáis otro terminal serie tiene que soportar caracteres de escape:

Ya sabéis .... RUTA_APIO/iceprog bitstream

Un abrazo!

[charli va]

Y se me olvidaba!, una vez conecteis el terminal tenéis que pulsar el botón SW2,que si no no saldrá nada.😅

[Democrito]

Es una verdadera pasada Carlos,  a mí este tipo de ejercicio me flipa. Y es muy curioso que desde un terminal serie se pueda ver gráficos en movimiento.

Dejo enlace al vídeo que he grabado desde mi terminal serie (el de Icestudio). Mañana pruebo el otro bin. He subido el primero, el donut normal "donut-0_9mbps.bin".

https://drive.google.com/file/d/1yHqyzXg0tKRFcaTnODd6YclDHDwaIfBL/view?usp=drive_link

Y dejo un vídeo didáctico sobre el "Método MonteCharliva" :P

https://www.youtube.com/watch?v=m4X94Sq1Q4M&t=246s

[charli va]

Buenas Demócrito! me alegro mucho que lo hayas disfrutado, muchas gracias por probarlo, los saltos que te da si amplías la ventana del terminal te saldrá más continuo y desaparecerán . El terminal de texto no tiene una resolución natural de líneas y columnas respecto a una pantalla real y como tiene menos líneas, hace scroll para pintar las últimas y luego salta al principio, lo que te genera esa sensación de salto.

Como et digo si amplias un poco hacia derecha y abajo la ventana para que te quepan todas las líneas y columnas de golpe  lo verás fluido.

Respecto al vídeo la verdad que muy interesante hay datos históricos que no conocía y que la verdad me gusta mucho conocer ¡muchas gracias!

Von Newman aparecerá dentro de poco de nuevo en este hilo, voy a utilizar otro artefacto matemático creado por el para mejorar la aleatoriedad de un generador aleatorio, veremos que tal funciona en este caso.

Un abrazo y buen día!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/b6c4507f-5d29-40fc-85e7-44721fd29d38n%40googlegroups.com.

[Democrito]

Efectivamente Carlos, tal como recomiendas, he maximizado la ventana del terminal y ya se ve muy fluido el movimiento. Adjunto un vídeo.

[charli va]

Fantástico Demócrito! muchas gracias por testarlo. a ver si lo pulo un pelín para que no desincronice . De todas formas para la prueba que consistía en probar un diseño complejo con el oscilador creo que de momento vale.

Por otro lado , me ha dado tiempo a jugar un poco esta mañana con el tema aleatorio. He estado litearlmente jugando por intuición para organizar ya pruebas bien organizadas pero viendo por donde tirar y los resultados me tienen muy sorprendido. Con un cambio que he hecho muy tonto que consiste en vez de coger un bit de cada generador como hacía ayer, lo que estoy haciendo es generar los 16btis en serie (uno tras otro) a partir de 3 generadores que combino con un xor (el primero con el segundo y lo que sale on el tercero).

Esto es una práctica habitual en criptografía para seleccionar números aleatorios, cuando combinas de esta forma varios generadores aleatorios, el restulado es como mínimo el mejor de los generadores aleatorios individuales.

Con esto se consigue una precisión en el test de montecarlo del número pi de 3.16

Intentaré pasaros los diseños hoy o mañana, es un poco jaleó porque como no se puede generar directamente desde icestudio y tengo mitad en verilog mitad en icestudio, es como una circo el generar el bitstream, estoy viendo como montarlo para que sea práctico de compartir y probar.

Un abrazo y buen Domingo!

El dom, 9 jun 2024 a las 13:27, Democrito (<spo...@gmail.com>) escribió:

Efectivamente Carlos, tal como recomiendas, he maximizado la ventana del terminal y ya se ve muy fluido el movimiento. Adjunto un vídeo.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/2cd0df76-7a75-4dca-9ca1-186becb2a761n%40googlegroups.com.

[Democrito]

Como dicen por ahí, en algunos memes:

Para un matemático Pi = todos sus infinitos decimales

Para un físico Pi = 3,14

y para un ingeniero, Pi = 3

Es el típico chiste de "piques" entre matemáticos, físicos e ingenieros.

Otro fuerte abrazo!

[Jesus Arias]

Hola,

Si en un chip tienes varios osciladores de la misma frecuencia tienden a sincronizarse. Es lo que se llama "injection locking", y para la generación de variables aleatorias no creo que sea muy bueno. Por ello yo probaría a hacer cada anillo con un número de buffers diferente, a ser posible sin divisores comunes, por ejemplo: 79, 83, 89, 97, en lugar de 4 de 100...

[charli va]

Me parece muy buena idea!, mañana lo preparo junto con algún otro artefacto y os paso el código por si queréis experimentar.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f4fd6f96-5fd4-497f-9e64-1b34cf065917n%40googlegroups.com.

[charli va]

Jesús, nada sólo comentarte que me ha encantado el frecuencímetro.

Me ha parecido muy ingeniosa la forma de saber que has llegado  a la cuenta de las muestras  y como dejar el reloj parado mientras se resetean los rizados, sin usar lógica condicional, todo con  aritmética binaria.

¡Muchas gracias por estas perlas!

Yo ando organizando unas pruebas de forma algo más metódica y ver si hay alguna relación entre los retardos de las luts y la "posible" aleatoriedad .   De echo te quería preguntar porque me ha surgido la duda al ver tus gráficos. Según lo que aparece, quiere decir que los MSBs de todas las luts del anillo  tienen el mismo retardo? es dcir el MSB 5 por ejemplo de un anillo de 100 luts ,¿tieen el mismo retardo en todas las luts de ese anillo? Si es así realmente me parece muy curioso.

[Jesus Arias]

Hola

Permíteme que adjunte una versión un poco "pulida" del frecuecímetro.

[Jesus Arias]

Perdonad, que piqué en "enviar" antes de tiempo :( 

Ahora sí está adjuntado.

Respecto a los retardos de las LUTs: sí, todas ellas tenían los mismos bits en las entradas I3, I2, e I1. La idea era que la dependencia del retardo con el camino interno de la señal en la LUT iba a ser algo sistemático, tal vez debido a mismatches en el layout de la propia LUT, pero siempre los mismos.

Saludos

[charli va]

Si es que nos gana la ansiedad XD

Pensé que en cada etapa se generaría un retardo distinto  pero siendo así sistemático, al menos puede ayudar a "dejarse domar".

Como siempre muchísimas gracias por compartir todo esto!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3121ba4b-a322-45b3-b41d-1150a94d5367n%40googlegroups.com.