Mandelbrot Machine Simulator 🔥

[charli va]

Hola amigos! con la perla que nos ha dejado Jesús no he podido evitar usarlo como prueba de fuego para una cosa que me traigo entre manos......esto es una imagen durante el desarrollo ( abajo vídeo navegando por el fractal ):

Estoy preparando un sistema de simulación, que integraré en icestudio, pero también se puede usar desde código directamente (usando módulos y frameworks ya montados en verilog), desde la web con una interfaz muy chula o desde el propio icestudio dentro del flujo de trabajo.

Ahora mismo voy teniendo piezas ya funcionales, que voy avanzando con las pruebas que hago para el desarrollo de icestudio (intento encontrar sinergias entre las diferentes historias para llevarlas lo más en paralelo posible).

Entre ellas tengo ya bastante estable, el framework del simulador VGA, es una idea muy tonta pero funcional, lo que permite es coger un diseño que tengas y que use una pantalla VGA y sin tocar nada en tu códifo poder simularlo y verlo funcionar. 

El reto que me plantee es no tener que tocar nada del diseño original, ya que esta técnica que no es nueva, hay mucha gente haciendo cosas de este estilo ,  siempre implica montar un circo con el diseño, la gracia de esto es un "plug and play" ahora mismo a nivel de código, instanciar en un top, conectar señales y listo.

La pasada no es solo poder ver en la pantalla, sino que puedes sacar mensajes por consola, medir tiempos , sacarte tablas,.... en tiempo de simulación! :)

En el ejemplo que os traigo, he integrado el gamepad y puedo navegar por el fractal mientras se simula!  :)

Esto no es una traducción a software del diseño de Jesús, es literalmente el diseño simulado lo más a tiempo real que se puede bit a bit (ahora mismo mi equipo da 15FPS , aunque esto depende mucho de la máquina que ejecute, estoy bastante orgulloso del simulador porque muchas de estas simulaciones van a 1FPS, 0.05 FPS y cosas así, vamos que te mueres antes de ver un frame y de echo así empezó el framework, con un ejemplo muy sencillo apenas conseguía 1.5FPS.

Ahora mismo con un ejemplo sencillo obtengo unos 52 FPS en mi equipo y en Mandelbrot que es un diseño ya complejo, estamos entre 15 y 17, suficiente para poder interactuar.

Incluso si solo diera 1FPS para la depuración esta técnica de depuración es muy muy útil.

Así que nada, pensé.... el diseño de Jesús es ideal como una prueba de fuego... podemos ver si esto es funcional y si tiene sentido (porque si requiriera hacer muchos cambios en el diseño original, el concepto pierde sentido). 

El diseño de JEsús, cumplía todos los puntos críticos:

1) Utiliza una memoria externa (diversión asegurada).

2) Como Jesús es un mago de la optimización y usa la SRAM con maestría funciona en flancos de subida y bajada, para leer y escribir en el mismo ciclo y aunque eso con el hardware real una vez sincronizas las señales es fácil, en simulación tiene su miga porque el simulador las cosas "asíncronas" y con buses flotentes se le atragantan y te puede generar "alucinaciones" o retraso en las señales de forma que se generen bloqueos en el diseño así que, crear un modelo de sram que funcionara con el diseño de JEsús sin tocar sus señales, era un reto.

3) Utiliza una resolución no estándar, el módulo debería de más o menos pintar sin tener que ajustar nada (me esperaba peor resultado del obtenido). La idea es hacer el módulo tolerante pero de momento está en un estado inicial.

4) Tiene interacción con un gamepad, así que otro handicap ¿podemos simular algo con lo que podamos interactuar? y además al igual que antes, sin modificar el código origina. Pues la respuesta es... Sí, también he creado un módulo para simular el gamepad de la NES y enchufarlo a la máquina de Mandelbrot como si fuera un pad de NES, pero realmente lo que toma son las pulsaciones de las teclas del teclado.

Las simulaciones no son perfectas, a veces hacen estragos y son muy estrictas con el código (en el fondo te obligan a hacer las cosas muy bien), por lo que intentar simular así a la primera un código como este pues me planteaba que podría errar y no conseguirlo.

También nos enfrentamos a al eficiencia, en cosas pesadas como esta puede ir extremadamente lento que por ejemplo para interactura se podría convertir en algo inusable.

Al final ha sido un éxito , el diseño ha funcionado prácticamente a la primera en cuanto he tenido el modelo de sram operativo y ajustar algunos anchos de buses (verilator es muy estricto).

La integración del pad también me ha parecido muy práctica.

Esto es muy útil a parte de molón, porque imaginad, se pueden probar por ejemplo los multiplicadores, podrías probar el diseño con una memoria más grande a más resolución, etc y todo con un esfuerzo muy medido y sin necesidad de tener ese hardware (imaginad que estais pensando en diseñar una tarjeta pero dudáis en ciertas características y puedes simular las diferentes configuraciones para tomar datos y tomar decisiones con datos).

No os quiero bombardear con mil cosas si realmente no son de interés, si realmente os apetece ver las tripas, levantad la mano y le doy unas pinceladas al código y hago una pequeña documentación y os lo lanzo el finde.

A mi personalmente no me importa hacer ese trabajo porque si me dais feedback de las pruebas, o si mas adelante lo usáis en cosas vuestras y me reportáis problemas o ideas para mi es muy gratificante y constructivo, pero eso ya me decís, si no sigo con ello a mi aire y ya os contaré más adelante.

Inicialmente sólo os lo mando así porque he tenido un "pico" de emoción al ver aparecer Mandelbrot dentro de mi pequeño simulador, pero realmente el framework que son 3 ficheros tontos fuciona muy bien y quizá os puede ser útil, al igual que el modelo simulado de sram que eso os puede dar juego.

Por cierto como veréis se descuadra un poco (se me sale por la derecha y aparece por la izquierda),  y es porque uno de mis objetivos es que el framework actúe literalmente como una pantalla vga y tenga cierto margen para soportar pequeñas desincronizaciones en los modos, por ejemplo realmente el simulador está trabajando a 640x480 y acepta las señales que emite Jesús a 512x480, tengo que robustecer eso porque ahora mismo como veis se me desfasa un poco.

Os dejo el vídeo, no es gran cosa pero lo veréis en ejecución y yo ando pulsando las teclas para navegar por el fractal.

https://youtu.be/UHdCIeJDxCQ

Ya me contáis que os parece, espero que os guste y si os motiva, mano arriba! y el finde os lo paso :)

[Democrito]

Todo esto suena muy interesante Carlos. Somos muchos los que estamos deseando ver el nuevo Icestudio, así que mucho ánimo! 

[Democrito]

Por cierto, (/mode on philosophical) cuando veo fractales en el que te puedes sumergir (hacer zoom) de forma infinita, siempre me viene el pensamiento de que a Dios no hay que buscarlo en los cielos, sino en el interior de los átomos.

Se trata de encontrar quién pone esos ladrillos para que surja todo. Por suerte soy ateo y simplemente contemplo la existencia. Este tipo de "búsquedas" es como si una bacteria tratase de comprender cómo funciona un ordenador.

Perdón por el off topic.

[charli va]

Los /mode on philosophical merecen la pena ;) bonita reflexión.

Los fractales son un campo de investigación increible elleno de cosas aún por descubrir, no sólo son objetos matemáticos "bellos", esconden muchísimos secretos  y ni siquiera hoy día conocemos su potencial. Yo los he puesto en práctica un par de veces en cosas en proyectos prácticos obteniendo resultados increibles, es todo un área apasionante.

Cogí con gusto el proyecto de Jesús,a parte de que me viniera estupendo por la idiosincrasia del proyecto como tal,  porque también a mi, ha sido algo que me obsesionó tiempo. De echo si os gusta este tema os recomiendo estos dos libros que os paso, si os motiva  al menos conseguirlos en pdf ( no sé si estarán en archive.org) para echarles un vistazo, merecen bastante la pena:

.       

En cuanto termine de depurar un poco más el tema del desplazamiento de la pantalla  os pasaré el código verilog para el que quiera jugar con ello o probarlo. Me está dando que igual tengo un bug y el desplazamiento es un artefacto del modelo de sram (al emular la asincronicidad con sincronicidad igual estoy decalando un ciclo el dato escrito en memoria y a efectos prácticos está desplazando la imagen, no lo tengo claro pero algo me huele).

Que tengáis buena tarde!

--
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/1a56d25a-2fc3-4f0d-b523-e804a2f3f860n%40googlegroups.com.

[Democrito]

El único libro de esta temática que leí cuando tenía 20 y pocos años fue Caos, de James Gleick. Es divulgación científica, por tanto muy ameno de leer. Lo disfruté mucho porque además tiene un toque biográfico de personajes de ciencias.

Se puede encontrar gratis muy fácilmente y no pongo enlace para evitar problemas. 

[Jesus Arias]

Hola Carlos,

Si estás jugando con la máquina de Mandelbrot creo que sería conveniente que usaras estas fuentes un poco más actualizadas, y que tienen parametrizado el ancho en bits de los datos.

Van también los fuentes de varios multiplicadores:

   fmul.v:   versiones antiguas para 16 y 24 bits

   fmulbooth.v: Tu multiplicador de Booth

   fix_mpy.v: versión de ancho de bit en parámetro

Saludos

El viernes, 16 de mayo de 2025 a las 10:31:42 UTC+2, charliva escribió:

[Jesus Arias]

Hola otra vez,

El modo de vídeo es el VGA de toda la vida, con un reloj de 25MHz y  total de 800 pixeles por línea, de los cuales los visibles son 512 en lugar de los 640 habituales. Esto lo hice porque no me alcanzaba la SRAM para una resolución de 640x480 y 4 bits/pixel y no debería ser un problema para la simulación.

Abrazos

El viernes, 16 de mayo de 2025 a las 10:31:42 UTC+2, charliva escribió:

[charli va]

Fantástico! esto se pone divertido XD, os actualizaré también ficheros mañana o pasado porque el de booth tenía algún bug que ya he solucionado y ando preparando algún otro multiplicador que no me acaba de funcionar. Parte del interés  es probar multiplicadores así que la verdad que el update es buenísimo :)

Jesús, una pregunta, sobre el overflow en los multiplicadores , ¿qué criterio te gusta más? es decir hay tres opciones:

1) No hacer nada, que se desborde y que cada uno se apañe.

2) Que desborde pero sacar una señal de overflow
3) Saturar el multiplicador

Gracias Jesús!

--
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/6c784534-b9b9-4767-9d0c-0571d89d526cn%40googlegroups.com.

[charli va]

Si si efectivamente es lo que os comentaba, inicialmente pensé que era por algo relacionado con que se pintaran menos pixels (no había mirado exactamenet el módulo de video y pensé que hacías alguna triquiñuela) pero luego vie el módulo de video y vi que exactamente era 640x480 así que deduje que casi seguro que era problema mio , algún bug en el modelo de sram, como juego con captura en flanco negativo para simular la asincronicidad, seguro que desplazo una o dos columnastoda la imagen.

Ahora con la simulación podemos meter la memoria que nos plazca y probar incluso más resoluciones :) quiero solucionar ese bug de la memoria y os lo paso para que juguéis.

--
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/99019cd2-f163-46e3-a01c-87e7e4876081n%40googlegroups.com.

[charli va]

Me lo apunto! tendríamos que tener un hilo off-topic de libros seguro que nos aportaríamos mucho.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/e5574f89-be46-4518-8ead-939df3f87a2en%40googlegroups.com.

[Jesus Arias]

Hola de nuevo

Lo cierto es que los overflows no los he tenido en cuenta. Los bits MSB del resultado se truncan sin más.

Esto no sería un problema si la parte entera de las variables se limitase al bit de signo, pero si tenemos más bits en la parte entera el producto en "crudo" va a tener el doble de bits y vamos a tener que truncar los bits MSB para que el resultado tenga el mismo formato de coma fija que los multiplicandos.

En estos casos lo ideal sería proporcionar un flag de "overflow". Con este flag y los signos de los multiplicandos es fácil generar los valores máximos y mínimos si se quiere un resultado con saturación.

Saludos

[charli va]

Gracias por tu opinión Jesús, el tema es que yo todos los multiplicadores los estoy planteando con detección de overflow y saturación para evitar que nos explote el cohete en pleno lanzamiento XD. cuando he trabajado con DSPs era algo habitual que funcionara así, pero claro esto suma LCs a la cuenta de nuestras pequeñas FPGAs.

Igula los planteo con unos ifdef y que podamos seleccionar el modo con el que lo queremos generar porque igual en un momento dado dices mira pues para este caso no necesito la lógica de overflow y sin ella me caben x más cosas.

Este finde a ver si consigo que funcionen un par que ando trabajando y os paso los avances que llevo.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3f87961b-e967-4cad-b063-b3aaad5068e8n%40googlegroups.com.

[charli va]

Hola a todos! os paso el código del proyecto, la verdad que ha sido una experiencia muy bonita y satisfactoria.

Mi objetivo inicial era sólo ver si el framework que estaba preparando se podía adaptar fácilmente a un diseño más complejo y la prueba de fuego de intentar meter Mandelbrot que además es un diseño funcional era todo un reto.

La experiencia no ha podido ir mejor porque el diseño de Jesús ha funcionado prácticamente a la primera. (por mi parte me ha valido para depurar el framework que tenía bugs gordos, pero la parte de Mandelbrot al ser ya un diseño funcional realmente ha entrado a la primera con cuatro cambios).

Las simulaciones no son perfectas, es típico que cosas simuladas no funcionen en real o que aparezcan artefactos generados por la propia simulación. Por ejemplo en Mandelbrot, si veis el vídeo que os subí, veréis que a la izquierda se pintan las últimas líneas de la derecha (como si la pantalla desbordara), pensé que era el modelo de la sram que al simular la asincronía con los flancos de reloj se me hubiera desfasado el dato 1 ciclo. Pero no, resulta que en el módulo videomodule hay un registro del conteo del refresco horizontal que aunque en real funciona, en la simulación en vez de inicializarse, arrastra el último dato al volver a cero, simplemente he tenido que añadir una línea para que el registro se inicialice a cero al llegar al final.

También te he cambiado, Jesús, en el mismo modulo, la sintaxis de los argumentos del módulo porque las nuevas versiones de yosys y verilator no les gusta que definas en la cabecera el nombre y luego le asignes por ejemplo el tipo registro en el código, el arreglo más sencillo es añadir el reg en la definición ( output reg por ejemplo) y en el cuerpo del módulo si tiene inicialización ponerle el initial delante. Este cambio de yosys en icestudio ha sido un dolor de cabeza en muchos bloques hecho desde hace tiempo, Obijuan se ha pegado una paliza importante poniéndolos al día (gracias!).

En las próximas semanas tengo intención de hacer un documento detallado de todo esto o algún vídeo tipo tutorial  y con algún ejemplo sencillo para entender como conectar los diferentes elementos, sobre todo para los que no estén acostumbrados a este tipo de cosas y quieran aprender, pero para los que os manejéis y  queráis jugar con ello os lo dejo por aquí.

Esto va a ir integrado en icestudio junto con otros componentes de simulación, y se podrá hacer visualmente pero ahora mismo está en estado primigenio, la idea es hacer transparente la complejidad de montar todo el entorno de simulación, por ejemplo en el caso de mandelbrot, el entorno de simulación provee sin tener que tocar ni desarrollar nada:

1) Una memoria sram

2) Un gamepad NES 

3) Una pantalla VGA

El desarrollador (vosotros) no tenéis por qué meteros en como se programa la interfaz con la ventana del sistema operativo o como se captura el teclado y se le pasa a verilog o como se toman las señales vga y se convierten en una ventana gráfica dentro del sistema operativo, simplemente tenéis que conectar los módulos en el top y ejecutar el makefile (make clean && make). 

Eso os generará un archivo ejecutable (en linux se llama sim) que al ejecutarlo os abrirá la ventana y a disfrutar.

La ventana captura las flechas (cursor del pad) y los botones A y B que son Z y X en el teclado (start y select los he mapeado en el teclado A y S).

En la consola cuando lancéis el ejecutable saldrán los display que hayáis puesto en el código (esto es super cómodo para depurar, es casi como depurar software).

Para el proyecto de Mandelbrot no hay ningún cambio, su módulo de vídeo está conectado a vga_sink como si este módulo fuera el CRT y recibe el gamepad como si tuviera un gamepad real conectado, y habla con una memoria que se comporta como la memoria real que espera.

Como es una simulación con vga no he activado la generación del VCD porque al pintar todos los frames se generan ficheros gigantes, pero con una bandera en verilator además de simular generaría el fichero para abrirlo con gtkwave igual que con iverilog.

Cualquier idea decidme que si la veo factible e interesante la incorporo a futuras mejoras.

No esperéis un videojuego, el simulador va lo más rápido que puede pero va "apretado",  para este tipo de simulación gráfica no tiene mucho sentido temporizar porque lo que interesa es ver visualmente el resultado y el equipo va con la lengua fuera, por ejemplo el Mandelbrot que he dejado es el que pasó JEsús último con la multiplicación a 32bits y sólo saca 4FPS de visualización real (la simulación va ciclo a ciclo).

Pero es funcional y al final es muy útil e interseante poder probar el diseño tanto en desarrollo como por ejemplo en este caso probar un diseño para una placa que no tenemos.

Ahora mismo el framework solo simula 640x480 estándar, laidea es ampliarlo a otras resoluciones (inferiores y superiores), pero bueno como os comento esto ha sido la primera prueba de concepto.

Ayer estuve mirando el Defender que tiene Jesús también para la Simretro que parece un proyecto interesante, pero lo voy a abordar un poco más adelante porque no contaba conque hay que simular la flash para cargar las roms, me parece super interesante la verdad, ademas, la parte del sonido he pensado que podía ser muy interesante que el simulador permitiera volcar a un fichero para luego poder escucharlo o abrirlo en un programa de audio, esto se podría trasladar a volcar señales para poder luego abrirlas en cualquier entorno matemático o de graficado.

Otra cosa que me interesa de esta historia para más adelante es poder conectarla con qspice para alimentar el modelo con simulación de señales y que sea más ágil que volcar a disco datos y cargarlos, pero bueno son ideas que ya se irán materializando poco a poco.

Se me olvidaba, solo por indicar, necesitáis tener instalado las librerías de SDL de desarrollo y los compiladores g++ y por supuesto verilator (si tenéis yosys ya os va de serie).

En linux para aseguraros de tener todo para los que no suelan desarrollar:

apt install build-essential apt install libsdl2-dev

Y si alguno quiere probarlo pero no tiene ni quiere instalar yosys, en ubuntu puede hacer:

apt install verilator

No me enrollo más os dejo esto para el que quiera jugar.

[Jesus Arias]

Hola Carlos

Estoy teniendo algún problema para compilar. Te comento:

- He tenido que quitar la opción "-march=armv8-a" en el archivo Makefile (sorry, no apples today ;)

- Ahora llego hasta aquí:

Error fatal: no se puede crear /usr/share/verilator/include/verilated.o: Permiso denegado

Me parece que  la variable $(VERILATOR_INCLUDE) tiene valores muy diferentes de los tuyos. Voy a intentar chapucearlo...

Buen día

[charli va]

Disculpame Jesús! se me fué completamente la cabeza, al principio no pasaba de 0.5FPS y me lié la manta a la cabeza optimizando e incluso probando opciones específicas para la máquina más potente quet engo que es un apple M1 (trabajo entre mi equipo de sobremesa, intel de toda la vida con linux ubuntu y el portatil que es un apple M1 de hace ya 10 años pero que tira que da gusto).

Ahora mismo lo corrijo y os l paso, disculpad!

--
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/71296578-6068-4580-8c53-92e1bfb010ebn%40googlegroups.com.

[Jesus Arias]

He cambiado los paths y he pasado el verilated.o Ahora me quedo en  verilated_threads.o:

/usr/share/verilator/include/verilated_threads.h:48:17: error: ‘atomic’ in namespace ‘std’ does not name a template type

   48 |     static std::atomic<vluint64_t> s_yields;  // Statistics
      |                 ^~~~~~

Parece que tengo alguna incompatibilidad con los archivos *.h del verilator. Puede que por seguir con una distro vieja de Lubuntu....

[charli va]

Jesús te adjunto el Makefile si puedes probarlo que ahora no tengo a mano el linux y me confirmas. Cometí otro error que es que yo tiro del verilator de icestudio con una variable global que me exporto en el bash y como está en la carpeta de usuario puedo escribir, pero tu tendrás la del sistema opertivo de verilator con apt y esa no se puede escribir.

Relamente esuna tontería es solo indicarle que escriba todos los .o en el directorio del proyecot, lo hice así por dejar los .o de verilator en verilator pero es algo chapuza la verdad, mucho mejor así.

La bandera de arm se puede quitar no aporta nada, la metí para ver si optimizaba inicialmente aunque era algo redundante porque no es una compilación cruzada y ahí se quedó.

Prueba este a ver si te va y gracias por probarlo que así mucho mejor.

[charli va]

Os adjunto otra versión del Makefile que incluye los fuentes de todos los multiplicadores para que solo tengáis que cambiarlo en system en el código y os compile perfecto.

Olvidé comentar que quité los includes de system para evitar bucles de includes que con verilator es un dolor de cabeza y cambié algún nombre de fichero porque verilator le gusta que cada fichero tenga el nombre delmódulo que contiene, se puede quitar ese warning pero es un poco rollo, por eso saqué de fmul.v fmul24 y cree fmul24.v

Son temas cosméticos nada más.

Que tengáis buen día!

[charli va]

Ahora te digo jesus que puedes usar los de icestudio dame un rato que estoy fuera y te digo cómo hacerlo 

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/2210268b-6bd3-46bc-83f9-c9aa221f8b1en%40googlegroups.com.

[charli va]

Voy a instalarme en una máquina virtual esa distro y así veo que me interesa ver los problemas de este tipo.

Que versión es?

[charli va]

Parece que es por la versión de gcc que tiene que soportar al menos 

C++11 

Voy a ver si se puede compilar con soporte legacy o buscar una solución.

Te digo luego gracias por probar!

[charli va]

Jesus mira a ver si puedes hacer :

apt install g++-12




Luego en el makefile tendrás que indicar que use g++-12 imagino que se llamará así el ejecutable prueba antes en la consola a ver cómo se llama g++ y darle al tabulador a ver qué opciones saca)




O busca con apt search g++ a ver qué versiones oficiales te deja instalar

Hay repositorios para tu distro con las últimas versiones de gcc pero primero intentaría lo estándar 

[charli va]

He estado viendo como instalar las últimas versiones de gcc en ubuntu 22.04 (es lo mismo que lubuntu para este tema) y he encontrado esta guía, por si te ayuda:

https://linuxcapable.com/how-to-install-gcc-compiler-on-ubuntu-linux/

No me ha parecido una distribución demasiado antigua pero justo verilator ha pegado un salto en las últimas versiones de este año importante y han cambiado un montón de argumentos y opciones (se han pasado a pthreads intensivamente, incluso en nuestro caso que no usamos threads y la simulación es monohilo, pero el motor en sí usa estos nuevos contextos atómicos de c++ 11).

La guía parece sencilla y explica como convivir incluso con varias versiones, hay un comando para elegir unas u otras. Si se te hace mucha bola, me instalo este finde tu misma versión y veo como hacerlo, me interesa que esto se fácil de usar y no me ha parecido que lubuntu 22.04 sea tan obsoleto.

¡Que tengáis buena tarde!

[Jesus Arias]

Hola Carlos

Sigo teniendo el mismo error

/usr/share/verilator/include/verilated_threads.h:48:17: error: ‘atomic’ in namespace ‘std’ does not name a template type

No he tenido tiempo de mirarlo más en detalle, pero me parece que que los "includes" de verilator no están muy bien.

Buenas noches

[charli va]

Gracias por insistir con esto, sé que estos problemas son un infierno.

No pierdas tiempo, voy a intentar preparar "un kit" que se pueda descargar y usar para estos propósitos independientemente del sistema operativo, me interesa mucho que esto sea fácil de utilizar y estas primeras pruebas tuyas fuera de mi entorno valen para ver que va a dar problemas.

En el fin de semana os voy contando.

Buen sábado!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/35063bd5-07ee-4624-89ad-9af576ba5d14n%40googlegroups.com.