repositorios oficiales openXC7

[Carlos Venegas]

Buenas! esto es una pregunta sobre todo para  Obijuan o  para cualquiera que quiera entrar en el debate y que pueda dar su opinión.

La actual toolchain para las Xilinx está basada en el repositorio de https://github.com/f4pga el cual depende de la Chips Alliance y está prácticamente abandonado/gestionado por dependanbot y poco más, los PR están atascados desde hace años.

La gente de openxc7 se cansaron y abrieron sus forks https://github.com/openXC7/prjxray que es un fork a su vez de https://github.com/jrrk2/prjxray que debió ser el primero en estar cansado del ritmo (y de echo es uno de los contribuidores más activos).

Es decir la cadena es f4pga->jrrk2->openXC7

jrrk2 colabora activamente en openXC7 y yo creo que de echo es donde está actualizando principalmente.

Os iba a proponer cambiar nuestro origen de la toolchain a los repositorios de openXC7 , la diferencia es brutal, de las mejoras/bugs que he estado haciendo , una por ejemplo me la he  encontrado esta mañana ya hecha hace 6 meses en openXC7, es decir si hubiéramos estado ahí me habría ahorrado bastante trabajo.

Había dado por hecho que estábamos usando la última toolchain oficial y que por alguna razón estaba estancada (falta de fondos de las fundaciones, o cualquier cosa similar), y no había indagado en la "telenovela" que debe haber montada.

La diferencia entre uno y otro es prácticamente mejoras y actualizaciones que cubren más de 1 año de diferencia , con muchos bugs solucionados y soporte de tarjetas, además de que se ve una actitud activa ante nuevos PRS,etc (ayer por ejemplo dieron de alta bastantes virtex de unos prs externos).

Decidme si os parece bien que migre lo que tenemos a estos forks como referencia para que ya que es algo que arranca nuevo, arranquemos bien y no ya obsoletos, en los próximos días voy a subir todo el código que tengo mejorado y patcheado de la toolchain y unos workflows para github para que se generen los paquetes solos cuando haya cambios.

Sería ideal si ya de paso lo dejamos contra un fork que esté al día si no hay nada que por algún motivo que desconozca prefierierais que no.

Ya me decís con lo que sea.

Saludos!!

[Fernando Mosquera]

Hola Charli,

Creo que es mejor usar la rama mas actualizadda.

Por lo tanto, estoy de acuerdo contigo al 100%

Un abrazo

Fernando Mosquera

Get Outlook for Android

---

From: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com> on behalf of Carlos Venegas <char...@gmail.com>
Sent: Thursday, 30 July 2026 08:46:05
To: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com>
Subject: repositorios oficiales openXC7

 

--
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/CAEQ-VCbuJZ7nNp-Ot-sRhs_xKEhEvCTCkLaTbm%3D2rW5Gg0kYBw%40mail.gmail.com.

[Juan Gonzalez Gomez]

Las toolchains que utilicé desde el principio para la basys3 son las de openxc7. En concreto la versión 0.8.2 de https://github.com/openXC7/nextpnr-xilinx/

Saludos, Obijuan

--

[Carlos Venegas]

Curioso! el tema es qeu el 0.8.2 es de 2024! luego tu al partir de ahí realmente era la 0.8.2 con algunos prs de openxc7 de Marzo de 2025.... acojonante! y han estado en standby hasta hace 2 días!!! (literal)

Al ver lo de la 0.8.2 literalmente pensé que estábamos tirando de la original....

En fin , pues muchíiisimas gracias por la aclaración, ahora todo tiene sentido :)  así que en cualquier caso , tiramos adelante con opencx7 y actualizaré con lo que han subidos estos días (incluido lo que os he comentado).

Buena tarde!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CABqu7xqxpbHPP2A5ER97q6x6TNO6480ZP%3DcBm9SYyuC_WnqU8g%40mail.gmail.com.

[Carlos Venegas]

Si podéis probar con la última CI de Apio (actualizando en icestudio la toolchain ) y decirme si funcionan bien los ejemplos que vais haciendo.

He actualizado la toolchain pero no a la última porque falla bastante, pero he actualizado hasta la versión del 13 de Julio de este año, donde aparentemente funciona todo. Les voy a abrir unas issues de las últimas actualizaciones que me da la sensación de que han roto cosas pero por el momento hemos ganado bastante.

Si podéis confirmar sería genial. Estos dáis prepararé los workflows para poder automatizar el generar nuevas toolchains según vayan sacando cambios en openXC7

Muchas gracias Equipo!!

[Fernando Mosquera]

Estoy ahora mismo de Vacaciones y hasta el martes que viene no vuelvo a casa.

En cuanto vuelva te lo pruebo.

Tengo ademas una proposicion que creo puede resultar intetesante. Se que este tema requiere de un nuevo hilo pero voy a ir soltando la liebre.

Desde el grupo de Discord del Mega65 he estado comentando los avances que tenemos con IceStudio y el sistema Mega65 y en la discusion a alguien se le ocurrió preguntar si era posible sintetizar el core principal de la implementacion de la maquina del Mega65.

Ese core esta escrito en un 90% en VHDL y el resto en Verilog.

Pues a un iluminado se le ha ocurrido usando el pluging de VHDL para yosys sintetizar el core, y ese core es bastante grande.

Mirad lo que comenta:

It runs! A carved mega65-core booting to BASIC on the wukong board through a fully open flow: ghdl → yosys → nextpnr-himbaechel → prjxray fasm2frames. CPU running at 20 MHz for now.

In the build (real, hardware-exercised logic):

- 45GS02 CPU (gs4510) with hypervisor mode

- Hyppo hypervisor + its BRAM (boots, mounts FAT, loads ROM)

- VIC-IV (viciv) with the full HDMI/DVI output path

- sdcardio — SD card interface, F011 floppy emulation, hypervisor registers (fpgatemp inside it stubbed to a constant reading)

- Both CIAs, C65 UART, keyboard matrix plumbing

- The serial monitor

- All memories: 384KB chipram (shadowram), colour RAM, charrom, hyppo work RAM, character/screen buffers

- MMCM clocking, slow_devices skeleton

como veis es bastante completo, pero fijaros en el flujo.

Ellos usan

https://github.com/YosysHQ/nextpnr

especificamente esto

https://github.com/YosysHQ/nextpnr/tree/32324500c4ae33670df429d2e8e2a83b51b062ab/himbaechel/uarch/xilinx

you have to tell it to build the xilinx uarch for the himbaechel db

you can find semi recent build instructions for all of the tools in the makefile in https://github.com/LAK132/fpga-toolchain

(this repo is specifically set up to build MEGA65 cores)

Los cores para Mega65 son cores para la Artix7 200 que lleva esa maquina

Si se ha podido generar el core de Mega65 con lo complejo que es eso, quiere decir que al menos este desarrollador del Mega65 ha resuelto muchisimos problemas con la toolchain del Openxc7 y podenos sacar muchas ideas de el.

Y ya llegados a este punto, por que no añadir soporte al IceStudio de bloques en VHDL?

Estuve preguntando a la IA y me dio un monton de informacion y el roadmap requerido para ello con algunos scripts en python para partiendo del formato JSON que usa IceStudio, convertirlo a VHDL incluso con instancias o bloques anidados. La informacion de la consulta vale oro.

Os comparto la consulta para que saqueis vuestras propias conclusiones

Click the link to view conversation with Kimi AI Assistant https://www.kimi.com/share/19fbc6c4-ada2-87c7-8000-0000a95e05ab

Con todo esto que os he puesto hay mucho trabajo pero seria fantastico poder trabajar con VHDL porque academicamente es lo que se enseña en la mayoria de universidades de USA y Europa.

Un Abrazo,

Fernando Mosquera

---

From: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com> on behalf of Carlos Venegas <char...@gmail.com>

Sent: Friday, July 31, 2026 10:17:32 AM
To: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com>
Subject: Re: repositorios oficiales openXC7

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCY4h85aW06sAiyWOFWavQQYwrvU6HPH7GPBXSAnNSFG5Q%40mail.gmail.com.

[Carlos Venegas]

Buenas Fernando! tranquilo y disfruta las vacaciones!!!

Sobre lo del MEGA65 un gran hilo y todo lo aprendido y probado hay que valorarlo y verlo porque es oro, lo miraré con calma.

En cuanto a VHDL yo lo tengo en mi roadmap, de echo no solo VHDL sino otros lenguajes como spinalhdl ,Silice (este en concreto lo tengo ya muy avanzado, el creador es un amigo y se lo debo ya desde hace tiempo) o Amaranth que está cogiendo mucha tracción.

Como os comenté tengo una versión de icestudio aun más avanzada de la que os estoy actualizando , aunque poco a poco os estoy metiendo muchas cosas de las más "interesantes", pero tiene muchos cambios muy drásticos, y quiero aunque esté aumentando el sav día a día con todas estas cosa nuevas que congelemos una versión estable en breve y luego os plantearé mi roadmap, totalmente abierto a incorporar ideas nuevas , incluso a , si hay compromiso, preparar y definir tareas para que quien quiera pueda ayudar.

Mi objetivo es pasaros ya esta semana la versión que creo que deberíamos congelar como estable, que va a contener un par de mejoras bastante importantes a nivel general para todas las placas no solo para las xilinx a parte de incluir esto que andamos trabajando.

Después con la estable congelada plantearía el roadmap y entre todos le damos prioridades, si hay mucho interés por el soporte de vhdl lo podemos priorizar, todo es verlo, son todo temas interesantes.

Y en paralelo hay otros proyectos que llevamos entre manos que son muy interesantes y que os van a encantar, estoy seguro, que ahora hemos parado un poco por priorizar este tema de Icestudio por las unis pero pasado el pico retomaremos.

Un abrazo a todos y buenas vacaciones!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/PH7SPRMB000738498B828AA2D76E9FD0FFD72%40PH7SPRMB0007.namprd12.prod.outlook.com.