Toolchain Xilinx

[Carlos Venegas]

Buenas! abro este hilo nuevo para el nuevo ciclo de pruebas para las Xilinx.

Ando a ver si me compro una pero aun así neecesitaré bastante de los que ya tenéis y os habéis unido al excel, luego ya según se vayan probando más pues iremos ampliando el catálogo.

Solo tengo una duda Fernando por si me lo puedes aclarar, la ZXTRES la he excluido a no ser que me digas lo contrario, indicaste  xc7a100tfbg484 n pero ese empaquetado no existe en la prjxray-db (fbg484 solo para 200t) pero si su package real fuera xc7a100tfgg484 entonces si que la podríamos tener.

¿Me aclaras esto último?

Tengo ya bastante consolidada la toolchain la quiero dejar subida hoy, lo que sí hemos subido el paquete para incluir todas las tarjetas a 450MB aprox en cada plataforma. En los tiempos que corren no es nada pero implicará más descarga.

En cuanto Fernando me confirmo cierro la toolchain, la subo y propago el alta en apio de desarrollo (CI en icestudio).

[beni...@gmail.com]

Hola Charli

El ZXTRES tiene 3 versiones 

1.   ZXtres básico con   un xc7a15tcsg324-1
2.   ZXTres+ con un  xc7a100tfgg484-2
3.   ZXTres++ con un xc7a200tfbg484-2

Yo tengo la versión intermedia con 100K celdas --> xc7a100tfgg484-2

Aquí se ve en una imagen

Como puedes observar, tiene fácilmente accesible el puerto JTAG al que le puedes conectar cualquier programador JTAG que quieras.
Yo normalmente uso el FT2232H , FT232H, el nuevo CH347 que expliqué en otro post, o un USB-Blaster por ejemplo, el DirtyJTAG valdría también pero creo que es demasiado lento

Como curiosidad y para los que quieran trabajar con Vivado y no tengan un programador FT2232H o FT232H compatible con Vivado, pueden o bien flashear la EEPROM del FT2232H o FT232H genéricos de los chinos o bien usar una opción muy barata y bastante rápida que es una Pi PICO con el sistema XVC-PICO (https://github.com/kholia/xvc-pico) y programarla con el Vivado directamente mediante el modo Xilinx Virtual Cable. También existe una opción con el XVC y el CH347 

Incluso existe el modo XVC para la RP2040-Zero (https://github.com/andryblack/dirty-xvc). 

Saludos

Fernando Mosquera

[Carlos Venegas]

Muchísimas gracias por toda esta información Fernando! aquí eres el Maestro de las Xiliinx vamos a ver si conseguimos poner en marcha toda esta familia!

--
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/b610d318-8b24-47e7-a789-3c9877423af7n%40googlegroups.com.

[beni...@gmail.com]

De nada Charli,

Esperando a ver si veo en la lista de FPGAs de Xilinx los nuevos modelos

Por cierto, estaba probando añadir pines a la placa Sipeed Tang Nano, pero me encuentro con este problema; creo que se habló de cómo solucionarlo , pero no encuentro ahora el mensaje.

Creo que tengo demasiadas placas FPGAs y te estoy dando mucho trabajo 8-)))))

Saludos

Fernando Mosquera

[Carlos Venegas]

Para nada Fernando!! ahí el único problema es que estás trabajando en modo "developer" pero con una build que se supone no se debería de modificar porque si reinstalas perderás los cambios.

En plan para salir del paso y con cuidado de guardar el trabajo a parte por si reinstalas, sería simplemente en windows ir a ese directorio y darle permiso de escritura a todo el mundo.

En plan bien, clona la placa (botón clonar), le pones otro nombre o algún sufijo), eso te lo guarda en Documents en una carpeta icestudio que esa no se borra nunca y perteneces al usuario.

Icestudio te va a leer de ahí las tarjetas y las va a mergear con las de la distribución (te saldrá en todos los listados , buscadores). De esta forma puedes trabajar en tus tarjetas tranquilamente independientemente de actualizaciones.

Una vez tengas ya tu tarjeta lista, le dejas el nombre ok, sustituyes la carpeta en icestudio y hacer el PR.

Lo idea, para trabajar sobre las tarjetas de la distribución y para lo que está el botón de development mode es hacerte el clon del proyecto de github y lanzar icestudio con npm run start ahí ya si que todo es escribible y haces el pr directamente desde el proyecto.

Ando con varios vídeos de todo esto a medias, y de echo tengo dos vídeos en marcha a modo de tutorial, uno con la tang nano de 1K que ya tengo un fichero con todo el pinout recopilado de varios ejemplos para que icestudio lo tome bien , este sería el tutorial de placa en apio qeu aun no está en icestudio (caso de las xilinx) y ahí os explico como clonar el proyecto etc, lo que pasa que lo estoy haciendo en osx/linux en windows nunca he desarrollado con icestudio, entiendo que con wsl2 tiene que ser muy sencillo, voy a ver si monto un entorno y así os hago unos ejemplos.

El otro vídeo es de la placa icecream de Jesús que sería el ejemplo de una placa en desarrollo que no está ni. en apio ni en icestudio y que inicialmente el desarrollador puede lanzarla solo en icestudio incluso ahora podría distribuir con la placa la configuración de la tarjeta para instalarla en un icestudio sin ni siquiera hacer el PR a icestudio (esto creo que va a ser muy interesante).

En fin tenemos muchas cosas bonitas por delante, ahora estoy priorizando este paquete de las Artix que entre compilaciones voy avanzando el resto, quiero intentar llegar a tener la parte de simulación cerrada para que entre en la estable que vamos a releasear porque es una cosa que siempre ha carecido icestudio y que es muy necesaria, y he estado meses trabajando en un nuevo entorno para hacer sencilla la entrada a la simulación antes de que un alumno se pegue con testbenches los pueda entender y usar gráficamente, en los próximos días ya os lo liberaré.

Hoy sale seguro en apio en el día las artix estoy metiendo la zxtres+ que es la ue faltaba y voy a ir reconstruyendo paquetes para subir a apio y demás luego os aviso.

Y cualquier cosa aquí me tenéis, no hay problema por el bombardeo ;)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c7e57f9d-838c-4324-aa80-883f54d32663n%40googlegroups.com.

[Carlos Venegas]

Buenas! ya tenéis actualizado el Excel, he dejado lista la primera hornada, la familia Artix si os parece vamos a pegarnos con esta familia y cuando ya la tengamos integrado nos vamos a por las spartan y zynq.

Hay 14 placas nuevas y en icestudio lo que tenéis que hacer es (si podéis la última de icestudio o clon de git al día).

Luego si instaláis de cero seleccionar el paquete CI de apio y si ya lo tenéis instalado, simplemente ir a Tools->Toolchain y darle a update, asegurándoos de que el canal que elegís es CI:

Deberíais ver algo así, cada uno en su idioma:

Tras esto en el boardEditor , si dais a importar placas de apio ya os saldrán:

He creado un ejemplo mínimo (blinky) por placa tirando de ejemplos online pero no están probados, si encontrais errores  habrá que ir actualizando los diferentes paquetes de apio.

¡A jugar!!!

[Jo mo]

Hola Carlos,

And  updating apio, i got the error bellow.

So i tried reinstalling icestudio. the upload apio and got the same error

@Fernando: For info, i almost finished making the pinout.json (with the help of board editor too)  for the Qmtech Kintex XC7K325T Core board

[DemocritoBinary]

Hi everyone,

I'm familiar with this problem and I've tested it again to be sure.

The error occurs because even the slightest problem with the internet connection triggers this error. However, the installer continues despite the error message.

The solution I found for now: Using mobile phone data. If I do it this way, I won't have any problems.

For @Carlos:

Suggestions:

- Perhaps this part should stop the installation if an error occurs during the process. If it cannot continue, all downloaded files should be completely deleted.

- During downloads, if an error is detected, resume the download from that point.

Regards!

[Carlos Venegas]

Thanks to all my friends! The error you're seeing is the one Democritus described related to the download; I admit I didn't handle it well on my end. I'll try to improve it this weekend, and when I upload the simulator theme, I'll try to include improved download support in the same package.

Generally, it's a problem because GitHub imposes limits and IP blocks that are very annoying and quite complicated to manage, but I'll fix it, don't worry ;)

Best regards, and I hope it lets you proceed when you try again.

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 este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/5dc7a83f-51d3-4342-a601-740894954e80n%40googlegroups.com.

[DemocritoBinary]

Meanwhile, another solution could be to connect the PC's network cable (RJ-45) directly to the router. I haven't tried it, but it usually works.

[Carlos Venegas]

It's important detect de problem, could be something with windows, i'll try to reproduce it.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3f8bb3f3-b0db-4c87-ad98-71c7d58ce331n%40googlegroups.com.

[DemocritoBinary]

This also happens (at least to me) during the wip/build download, but the browser allows me to "resume".

[DemocritoBinary]

wip/build = https://downloads.icestudio.io/

[Carlos Venegas]

Hi Joaquim, the error shown in the screenshot isn't "file not found": it's EBUSY (resource busy or locked) for 'C:\Users\J\.icestudio\apio-bundle\apio.exe'. That indicates a file lock in Windows: something has apio.exe open (a running instance of apio, antivirus/Defender, an indexer, etc.), and the installer is trying to write to, extract to, or delete that file (resulting in EBUSY).

I'm checking to see if there's a bug in the Windows update process—let's see if I can reproduce it!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/5f89a903-e596-443e-acbe-f89814a8ff0fn%40googlegroups.com.

[Carlos Venegas]

I think I've found an asymmetry when updating the bundle on Windows. A call is made to `apilio --version` to check which version is already installed before updating, and since we're using a bundle that includes the embedded Python interpreter, I've noticed that Windows Defender and other antivirus programs can freeze the executable for a while after it runs.

If you can, Joaquim, while I look for an elegant solution for this, delete the `.icestudio` folder if you don't have anything critical configured. Instead of updating, install IceStudio from scratch using the wizard (if you do a clean install now, you won't need to update anything; the initial CI channel installation will already install the correct bundle). That shouldn't cause any problems.

And over the weekend, I'll try to figure out how to strengthen the updater.

Cheers!

[beni...@gmail.com]

Hello Charli,

Here I see the newly added FPGAs in Apio



We have a lot of new Xilinx Artix7 models. Thanks a lot !!!!

And here are the new Artix7 Boards 

I am going to test one or two boards, and I will write the conclusions 

Thanks, Charli, for your great job !!!!

Fernando Mosquera

[beni...@gmail.com]

Hello Charli,

I am testing the board ZXTRES+. I have created  the board with a minimal number of pins for initial testing

I have added the configuration of my JTAG programmer; when I only build the project, I get the error in the next screenshot

How can I import or create an XDC file to solve this issue?

Regards,

Fernando Mosquera

[Carlos Venegas]

Hi Fernando! Could be a bug, i’m fixing along the day.

Thanks for play with it

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/9b6a9cc5-388d-41ee-a227-fb52f35c1ba2n%40googlegroups.com.

[Jo mo]

Hola guys,

@Carlos, you were right, an apio.exe was still running this time, even after closing icestudio on my windows 10.  So i manually killed that process and then the apio update inside icestudio run just fine.

Sorry, for that dumb issue ;-) Thanks! 

Have a great weekend!

[Carlos Venegas]

Hi Fernando! Take the Basys3 as an example: the issue stems from a conceptual error in Icestudio - specifically, the `xc7` architecture was used for the Basys board, which isn't entirely correct.

I plan to support both `xc7` and `xilinx`, but for now, you should be able to proceed with your current version simply by changing the architecture from `xilinx` to `xc7`.

I'll get the `xilinx` support ready; in a day or two, I'll upload support for the "xilinx" architecture along with the new version I'm preparing (which includes the simulator).

Apologies for the mistake; I focused on adding the boards to Apio, but since I don't have the actual hardware to test with, I didn't verify it in Icestudio.

Thanks a million for the feedback!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/444a8767-805e-4ca0-af97-30988aeb1411n%40googlegroups.com.

[beni...@gmail.com]

Hello Charli,

When I select the Basys3 board and try to do the simple project to turn on one LED, I get the following error


The module fcntl doesn't exist in Python for Windows

Regards,

Fernando Mosquera

[beni...@gmail.com]

Hello Charli,

The error from the fcntl module doesn't appear on Linux. I have installed IceStudio on my WSL, and there are no errors. It works with my CH347 JTAG programmer !!!!

Thanks so much !!!

Regards,

Fernando Mosquera

[Carlos Venegas]

Hi Fernando! thanks again and again for the tests, i'm reviewing the windows toolchain that clearly  needs some  dependency.

Tell you soon.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/44ca1061-68a2-41cd-9ee0-5c57e23c8a53n%40googlegroups.com.

[Carlos Venegas]

Hi Fernando! I’ve found the problem.

I might not have it fixed until tomorrow because I have to rebuild the toolchain, and that takes a few hours. The issue is that we created the Windows port specifically for Apio/Icestudio—the original project doesn't have it—and although I’ve cleaned up the code significantly and rewritten OS-dependent parts, this `fcntl` call slipped through; `fcntl` is a module found in POSIX-compliant systems (Linux and macOS). I’m going to check if there are any other `fcntl` calls I missed.

Thanks again! Once the new toolchain is ready, you’ll just need to update the Apio toolchain from within Icestudio; it will definitely be ready by tomorrow.

I’ve run a battery of tests, but they have limitations—they only go so far since I don't have the actual boards. Even the Windows version is built on a Linux server using cross-compilation and tested via Wine (a Windows emulator for Linux), so I suspect some POSIX calls might be slipping through unnoticed. That’s why I’m so grateful for your real-world testing.

With everyone's help, we’ll have a super robust OpenCX7 in just a few days.

[Carlos Venegas]

Hi Fernando! You've got the package now. We got lucky: the change affected files that didn't require compilation, so I only had to package it up—which is really quick.

What you need to do now is uninstall the toolchain and reinstall it; let's see if it blows up on us somewhere else after that. XD

Tell me if all works!

[beni...@gmail.com]

Hello Chali,

In Windows, I got this new error

In Linux, it is working

Thanks and regards, 

[Carlos Venegas]

Thanks Fernando! again POSIX compatibility problem! i'll try to find more to fix all together.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/4241fa9f-fd5a-4d5c-811f-2519e1bb8b3en%40googlegroups.com.

[beni...@gmail.com]

Hello Charli,

In Linux, the ZXTres+ board works great !!!

Now, I am adding the pinout. Remember that this board has a lot of devices connected

It has :

• Memory:   2 MB SRAM +  64MB SDRAM
• PS/2 keyboard and mouse
• VGA (18 bits) video output, and optionally can be Scart
• DisplayPort output, compatible with HDMI through active adapters
• Audio: Audio stereo sigma-delta  + DAC I2S PCM5102
  
• 2 DB9 joystick ports compatible with Genesis
• microSD card socket

So, it is a good board to test a lot of projects

You can see a video here --> https://vimeo.com/1209191873?share=copy&fl=sv&fe=ci

Thanks for everything

Regards,

Fernando Mosquera

[beni...@gmail.com]

Hello Charli,

Now I am trying to generate a 28 MHz clock, given my main 50 MHz clock, using the PLL Primitive

Me da error

My Verilog file is attached to the message

Thanks and regards, 

Fernando Mosquera

[Carlos Venegas]

Wow!!! i'm very happy to see it!!! :)

Fernando continue telling us your great work!!

--
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/fc21064a-7e32-4857-afec-6b1853976080n%40googlegroups.com.

[Carlos Venegas]

I see... I'm going to look into it to find out who the culprit is XD

[beni...@gmail.com]

Hello Charli

I have solved the issue with the PLL Primitive

In this message, I have enclosed the block of the PLL from 50 MHz to 28 MHz as an example

I am using the following circuit to test it

Regards,

Fernando Mosquera

[beni...@gmail.com]

I have forgotten to include the PLL block.

Regards,

Fernando Mosquera

[beni...@gmail.com]

Hola a todos,

Otra nueva prueba de un proyecto para ZXTRES
Como el ZXTRES lleva incorporado un I2S Stereo PCM5102, he creado un ejemplo para que se pueda probar su uso

El Proyecto tiene un Generador de Audio (genera el sonido de una campana a 8 bits (se introduce en la memoria en hexadecimal) que suena intercaladamente en el canal izquierdo y luego en el derecho). Ese sonido es convertido en una señal de 16 bits firmada por cada canal.
Y finalmente tenemos un bloque transmisor I2S que genera las 4 señales que llegan al PCM5102 I2S, (la señal MSCLK no es necesaria)
A la vez que se genera el audio en cada canal se ilumina un LED para cada canal intercalados también

Os anado el proyecto en ICE

Saludos
Fernando Mosquera

[Carlos Venegas]

Buenas Fernando! Fantástico el fix a nivel de código que has hecho pero lo que te pasó de inicio ha destapado un bug de la opencx7, bueno bug destapado no, era un bug ya reportado en la propia opencxy ((openXC7 #38, #41 y gatecat#54) así que me he liado la manta a la cabeza y me he puesto a resolverlo y.... creo que ya lo tengo!! 

Estoy preparando los paquetes , cuando los tenga me gustaría pedirte si no es mucha molestia que lo pruebes con el primer código que fallaba, porque si funciona, lanzaré los PRs a OpenCX7, te nombraré en el PR como tester y parte del equipo en la resolución del bug si te parece bien.

Con esta van a ser ya 5 los bugs que he solucionado y que lanzaré como PRs pronto a opencx7 es una muestra más de como los proyectos open source se retroalimentan y mejoran con el propio ecosistema.

Y me alegro mucho de ver lo que has mandado , es una pasada ver la toolchain funcionando con cosas ya más serias.

Os aviso en cuanto tenga arriba el nuevo paquete.

Un gran abrazo!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/07cbd24d-9117-47c3-968d-d388cb730856n%40googlegroups.com.

[Carlos Venegas]

Hola Fernando! ya está el nuevo paquete con los fix tanto del PLL como de la compatibilidad POSIX para windows (he intentado adelantarme a posibles nuevos problemas y he localizado y fixeado otros 13 puntos de fallao en windows vamos a ver si conseguimos que esta vez cerremos un ciclo completo).

Actualiza de nuevo la toolchain , ya me contarás si todo va bien!

[beni...@gmail.com]

Hola  Charli

Parece ser que si, ahora ya sintetiza y sube el bitfile igual que lo hace en Linux.
Funciona en el caso del ejemplo del PLL , como en el caso del Tests de sonido I2S.
Enhorabuena por los cambios !!!

Se avecinan proyectos muy interesantes y la razón es que las placas FPGA que tengo son bastante completas con VGA, Teclado PS2, Sonido I2S, Memoria SDRAM, Tarjeta SD, y entrada de Joysticks

Saludos

Fernando Mosquera

[Carlos Venegas]

Wow!!! me alegro mucho! seguimos avanzando.

Quiero rodar este primer lote de nuevos chips y tarjetas que las tengamos ya inegradas en icestudio y pasamos al siguiente lote.

Muchísimas gracias!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/5315fd4b-0e4b-492a-9d66-4dbeb9e298adn%40googlegroups.com.

[beni...@gmail.com]

Hola Charli,

Estoy acabando de rellenar todos los pines de las 3 versiones del ZXTRES, y tengo 2 preguntas

1) ¿Cómo se puede indicar que un pin está en PULL-UP  y su voltaje?

     Por ejemplo en la línea del SD sd_miso hay que activar el Pull-up en el archivo XDC de la siguiente manera

    set_property PACKAGE_PIN M5 [get_ports sd_miso]
    set_property IOSTANDARD LVCMOS33 [get_ports sd_miso]
    set_property PULLUP true [get_ports sd_miso

    y en algunas líneas de su salida DisplayPort cambia el voltaje

    set_property -dict {PACKAGE_PIN A15 IOSTANDARD LVDS_25} [get_ports dp_tx_auxch_tx_p]

    

2) ¿Adónde hay que subir las configuraciones de las placas ?  A que githbub como pull request
     Yo tengo las placas guardadas en   "C:\Users\benit\Documents\Icestudio\boards"

Gracias 

Saludos

Fernando Mosquera

[Carlos Venegas]

Hola Fernando!! déjame que mire lo de los voltajes porque como no he trabajado con estas placas no conozco aun bien toda la nomenclatura, voy a ver el proyecto openxc7 y veo como funciona y te cuento.

Sobre como subirlo, termino mañana martes un tutorial que ando preparando para subir placas y si no te importa con ese tutorial lo pruebas y así vemos si cubrimos bien el proceso por si faltara o  no quedara algo claro ya lo rematamos para otros usuarios.

De momento me alegra mucho ver que el sistema de desarrollo "local" está funcionando bien, va a dar mucha agilidad para placas nuevas.

Saludos y muchísimas gracias por el trabajo!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ab873a5a-4ba3-41a7-be4b-f1a71536368bn%40googlegroups.com.

[Carlos Venegas]

Buenas Fernando! te cuento, he estado revisando el código de la toolchain y estas son mis conclusiones:

1) Pull-up, usar PULLTYPE, no PULLUP true

El parser XDC de openXC7 guarda cualquier propiedad (podrías poner "papas fritas y colaría", pero el generador de bitstream solo consume PULLTYPE. La forma Vivado set_property PULLUP true se acepta sin error pero se ignora en silencio, así que la forma correcta:

  set_property PACKAGE_PIN M5 [get_ports sd_miso]
  set_property IOSTANDARD LVCMOS33 [get_ports sd_miso]

  set_property PULLTYPE PULLUP [get_ports sd_miso]

Valores: PULLUP, PULLDOWN, KEEPER, NONE.

Lo he comprobado empíricamente, la cadena es  ->  fasm emite RIOB33_X57Y103.IOB_Y1.PULLTYPE.PULLUP para M5 y fasm2frames lo acepta (existe realmente en el silicio). 

SLEW y DRIVE que vi en el parser del código también funcionan (verificado SLEW.FAST, DRIVE.I12_I8).

2) "Voltaje" del pin, va implícito en el IOSTANDARD

  No hay propiedad de voltaje aparte ahora mismo, el estándar lo define, y el VCCO del banco lo pone la placa (en el ZXTRES el banco del DP aux ya está alimentado para 2.5 V o eso creo por lo que he visto en el esquemático en github pero loe he mirado rápido esto seguro que tu lo tienes más claro). La línea correcta sería:

  set_property -dict {PACKAGE_PIN A15 IOSTANDARD LVDS_25} [get_ports dp_tx_auxch_tx_p]

  Soportados por pin: LVCMOS12/15/18/25/33, SSTL12/135/15, TMDS_33, LVDS/LVDS_25 y los prefijos DIFF_*. 

Las líneas INTERNAL_VREF se ignoran sin error (solo importarían para entradas SSTL/HSTL).

  3) DisplayPort

  - El buffer diferencial debe instanciarse explícitamente en el HDL (OBUFDS/IBUFDS, el packer los soporta); yosys no lo infiere solo tienes que ponerlo implícito.
  - Constreñir los dos puertos del par (_p y _n) con su PACKAGE_PIN y el mismo IOSTANDARD.
  - La ruta de salida LVDS_25 existe y emite los features correctos, pero está menos rodada que LVCMOS (en el código de opencx7 tienen un TODO sobre un bit de banco en entrada), así que esto hay que verificarlo en placa y si no funcionara y me pasas el código le pego unas simulaciones y te voy pasando nuevas toolchains como con el pll e igual lo echamos a andar.

Si necesitas ayuda con esto te puedo hacer un "smoketest" con todas las opciones, algo sencillo que generae una onda cuadrada por algún pin o similar y que use varias de las oopciones para ver que las cosas mínimas funcionan, si lo necesitas dímelo y lo preparo con gusto.

Vete contándonos! vaya aventura!

[Fernando Mosquera]

Hola Carlos,

Paro entirndo que el tema del pull-up deberia de poderse guardar si configuracion en la misma lista de pines.

En la señal SD_Miso , al estar conectada fisicamente ese lector de tarjetas en la placa, siempre habra que configurarla como Pull-Up

Por tanto ese pull-up en ese pin ha de estar activado sienpre

El voltaje similar 

Y para el DisplayPort si te digo la verdad es que es muy limitado y solo hay un core que lo usa, ppr tanto no lo veo importante 

Saludos y graciaa a ti

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: Monday, 13 July 2026 15:35:11
To: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com>
Subject: Re: Toolchain Xilinx

 

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

[Carlos Venegas]

Eso es Fernando, las propiedades deben declararse una sola vez y todo junto, he estado mirando varios códigos originales de Vivado y voy a ver si te puedo preprar un ejemplo básico por si aporta algo.

Luego os envio lo del tutorial que tengo que acabarlo.

saludos!

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

[Fernando Mosquera]

Hola Charli,

La duda que me surge en el proceso de creacion del bitfile desde Icestudio de proyectos para XC7 es si la generacion del archivo XDC (con la asignacion de señales y pines) se realiza desde la configuracion que se crea y salva en Icestudio o desde Apio.

Si es desde Icestudio, podrias añadir una nueva columna donde podramos incluir el pull-up, pull-donw o nada, y otra con el Voltaje? Es posible esto? 

Del mismo modo habra que estudiar una forma de poder incluir los constrains de los relojes empezando por el del reloj principal 

Saludos

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: Tuesday, 14 July 2026 07:02:40

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

[Carlos Venegas]

Ahora mismo icestudio lo que hace es transportar el xdc a apio y apio a su vez a yosys y nextpnr y mantiene el formato estándar que creo que es compatible con vivado (esto no me hagas mucho caso pero creo que si).

Otra cosa es que en icestudio pudiéramos crear otro formato propio, más verboso y que luego tradujéramos, esto es totalmente posible, lo que nos limita es en sí la toolchain openxc7 y sus limitaciones actuales por ejemplo creo que el tema voltajes no sé si lo tiene soportado, tendría que mirarlo bien.

De todas formas en cuanto pueda preparo un ejemplo con todo lo que vea en el código de openxc7 que soporte que se puede hacer y a ver si con eso vamos clarificando posibilidades igual que el tema relojes.

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

[beni...@gmail.com]

Hola Charli,

Por ejemplo, para el siguiente circuito, 


Icestudio genera el siguiente archivo main.xdc 

# Code generated by Icestudio 1.0.0.PRw202607080407

set_property -dict { PACKAGE_PIN H13 IOSTANDARD LVCMOS33 } [get_ports {LED_vba23e7}]
set_property -dict { PACKAGE_PIN G15 IOSTANDARD LVCMOS33 } [get_ports {LED_ve4340a}]
set_property -dict { PACKAGE_PIN Y18 IOSTANDARD LVCMOS33 } [get_ports {CLK_50_vd38648}

Pero al llevar un reloj en las recomendaciones de Xilinx hay que incluir los constraints del reloj principal, y este constraint es común para todos los proyectos de la placa (en este caso ZXTRES+)

create_clock -name  CLK_50_vd38648   -period 20 [get_ports  CLK_50_vd38648]

Pero ojo, ese periodo de 20 ms depende del reloj primario de la placa (en el caso del ZXTRES+ el reloj es de 50 Mhz).
Ese periodo se calcula así: 
                     1/50 Mhz = 0.02 x 10^-9 = 20 ms.

Se supone que cada placa debería de tener en IceStudio un campo en su configuración en el cual habría que introducir el valor en Mhz del reloj principal y según ese valor que en el archivo main.xdc se creará esa línea con el nombre del puerto del reloj  (en el ejemplo es CLK_50_vd38648)

Gracias y un saludo,

Fernando Mosquera

beni...@gmail.com

[Carlos Venegas]

Muy buenas ! mándame si no te importa este .ice y tu carpeta de la zxtres en boards y así hago unas pruebas.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/57157418-02c2-43ec-961f-ce88c6aeb91cn%40googlegroups.com.

[Carlos Venegas]

Me he adelantado ya con unas pruebas y efectivamente voy a meter una sección de "constraints" en el board editor para poder definir cosas como el reloj o cualquier otra que pueda surgir para esta placa y para otras.

Muchísimas gracias Fernando por todo este trabajo y feedback, va a quedar una versión "increible".

Os aviso en cuanto lo tenga pero mándame cuando puedas los ficheros con los que estás trabajando.

Ando cerrando los vídeos que ayer tuve un problema con la cámara y no pude grabar la placa, hoy espero ya tenerlo solucionado.

¡Buen día!

[Fernando Mosquera]

Hola Charli

Ahora no estoy en el ordenador, te mandare los archivos en unas pocas horas.

De momento y para que vayas teniendo algo he solicitado a la IA que me cree un script en python para generar el modulo pll de relojes compatible con Yosys y XC7 y que genere tambien el archivo XDC, puede que lo necesitenos al igual que el icepll para las Ice40.

En la respuesta hay informacion muy interesante sobre compatibilidad de formato.

Aqui tienes el link de la consulta a la IA

https://share.google/aimode/P06lJqrTL4XKEe2gn

Saludos

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: Wednesday, 15 July 2026 00:36:45

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

[Carlos Venegas]

Gracias Fernando! seguro que es útil, yo ya lo estoy encarrilando en icestudio, he creado una nueva sección "constraints" que nos permitirá ir añadiendo features por placas que lo necesiten las cosas ya claras como los relojes tendrán su asistente como el que estoy cradno para poder añadir incluso múltiples relojes y luego un campo genérico para cosas particulares de placas que requiera un esfuerzo demasiado grande hacerlo genérico pero que se puedan configurar para cosas excepcionales:

Entre hoy y mañana tendré cerrada esta versión , para el finde disfrute incluido simulador ;)

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

[beni...@gmail.com]

Hola chali,

Muy chulo la nuevo opción en IceStudio
Aquí tienes el archivo iCE que me has pedido 

Este es un poco más avanzado porque tiene un PLL

Tienes el archivo zxtres-plus.zip con la configuración de los pines de la placa ZXTRES+. 
El resto de placas ZXTRES y ZXTRES++ llevan los mismos pines, solo cambia el tipo de FPGA así que lo montaré cuando acabe el ZXTRES+

Te adjunto además un fichero zxtres.XDC de un core completo del core de Amiga Miniming para el ZXTRES, para que veas todo lo que lleva, incluido el tema de timing constraints.

Si te fijas, existen más timing constraints para señales internas. En ese core mediante PLL se generan 2 relojes, uno de 28 Mhz para la CPU  y otro de 114 Mhz para la SDRAM

En el archivo amiga_clk_zx3.v tienes la generación de relojes, pero ojo esa primitiva como está, no es compatible con Yosys + XC7, pero te dará una idea

Y por último he creado un módulo con la generación de varios relojes que creo que sí es compatible con Yosys + XC7, está en el archivo llamado relojes.ice.

Espero que todo te sirva
Un Saludo

Fernando Mosquera

[Carlos Venegas]

Oro puro!! muchas gracias Fernando!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f8a83a35-f29f-4c2b-b33b-d23eb26207f1n%40googlegroups.com.

[Carlos Venegas]

Hola Fernando, ando investigando esto hay temas complejos pero creo que va a salirr algo "muy bueno de todo esto.

Tenía en el todo y siempre lo dejo aparcado por falta de ganas más que de otra cosa,  una herramienta para generar los pll en icestudio directamente para diferentes placas, como veo que para las xilinx va a ser caballo de batalla por lo que he leído en el prompt que me has pasado, después de cerrar varias cosas de estas creo que podemos diseñar entre todos y que así valga incluso de ejemplo y sea una interacción bonita un plugin para generar bloques de icestudio directamente con las primitivas del pll que corresponda a la placa.

Id dándole una vuelta.

Ando investigando av er que se puede y no se puede hacer con opencx7 con el tema relojes en las xilinx al tener tantas posibilidades , anda la cosa "verde" en españa por si alguien lo traduce, no es algo bueno, sino que está con bajo nivel de soporte.

Lo que pasa que esto viendo posibilidades y vías incluso de poder mejorarlo, termino de evaluarlo todo y ya os cuento.

[Carlos Venegas]

Buenas Fernando, ya tengo implementado el tema de los relojes , solo he subido la nueva toolchain y apio (en apio directamente podrías probarlo), voy a ver si al final del día puedo ya subiros nueva versión de icestudio , si no en el peor de los casos mañana.

Ahora ya apio es capaz de reportar fmax y los recursos reales de la FPGA  para xilinx (en la captura icestudio también lo rellena correctamente porque es mi copia de desarrollo que ya tiene casi todo funcionando):

La ventana muestra el uso de recursos con apio shell ejecutando "report".

Como te digo tengo que cerrar algunas cosas aún pero avanza a buen ritmo, hay limitaciones que luego os indicaré cuando ya suba icestudio, la más importante es que la frecuencia de reloj que se usará para nextpnr si hay varios relojes definidos en constraints será la menor ya que opencx7 no es capaz aun de gestionar eso (aunque he visto el código y una vez tengamos esto igual intento añadir esa mejora y hacerles PR).

De regalo con todo esto se ha beneficiado en apio la familia Gowin que tenía problemas similares en el report de recursos y relojes.

Os sigo contando!

[beni...@gmail.com]

Hello Charli,

Quería aclarar un poco el tema de los relojes , para que sea 100% compatible con XC7 , hay que incluir varios buffers , el de entrada ha de ser tipo IBUF y los de salida del tipo BUFG

    //------------------------------------
    // Input buffering
    //------------------------------------
    wire clk_in1_clk_wiz_0;
     IBUF clkin1_ibufg(
     .O (clk_in1_clk_wiz_0),
     .I (clk_50mhz));

   
    //-----------------------------------
    // Output buffering
    //-----------------------------------

    wire clk_out1_clk_wiz_0;
    BUFG clkout1_buf(
     .O   (clk_28mhz),
     .I   (clk_out1_clk_wiz_0));

Otras reglas son que  DIVCLK_DIVIDE y CLKFBOUT_MULT,  CLKOUT0_DIVIDE ,  CLKOUT1_DIVIDE , ...  han de ser enteros sin decimales

PLLE2_ADV #(
        .BANDWIDTH("OPTIMIZED"),
        .COMPENSATION("ZHOLD"),
        .STARTUP_WAIT("FALSE"),
        .DIVCLK_DIVIDE(1),
        .CLKFBOUT_MULT(28),
        .CLKFBOUT_PHASE(0.000),
        .CLKOUT0_DIVIDE(50),
        .CLKOUT0_PHASE(0.000),
        .CLKOUT0_DUTY_CYCLE(0.500),
        .CLKIN1_PERIOD(20.000)
    ) pll_inst (
        .CLKFBOUT(clkfbout_clk_wiz_0),
        .CLKOUT0(clk_out1_clk_wiz_0),
        .CLKOUT1(),
        .CLKOUT2(),
        .CLKOUT3(),
        .CLKOUT4(),
        .CLKOUT5(),
        // Input clock control
        .CLKFBIN(clkfbout_buf_clk_wiz_0),
        .CLKIN1(clk_in1_clk_wiz_0),
        .CLKIN2(1'b0),
        // Tied to always select the primary input clock
        .CLKINSEL(1'b1),
        // Ports for dynamic reconfiguration
        .DADDR(7'h0),
        .DCLK(1'b0),       // DCLK necesita un reloj, le damos el de entrada
        .DEN(1'b0),
        .DI(16'h0),
        .DO(do_unused),
        .DRDY(drdy_unused),
        .DWE(1'b0),
        // Other control and status signals
        .LOCKED(locked),
        .PWRDWN(1'b0),
        .RST(rst)
    );

rst es el reset , hay que dejarlo a 0 para que funcione el PLL

y locked es una señal que se pone a 0 cuando la salida del reloj PLL se ha estabilizado. Normalmente se usa para controlar la estabilizacion de PLL en el arranque 

Os dejo adjunto el módulo del PLL que partiendo de un reloj base de 50 Mhz no da como salida un reloj de 28 Mhz

Espero que quede claro, saludos

Fernando Mosquera

[Carlos Venegas]

Muchas gracias Fernando! con esto puedo ir probando la síntesis y ver que nada "explota" porque ya he ido solucionando bugs de cosas que literalmente crasheaban la toolchain.

Uno de los problemas de opencx7 es que usan una versión muy antigua de yosys/nexpnr estoy evaluando la posibilidad de migrarlo , daría mucha vida al proyecto, he visto que el desarrollo lo tienen bastante estancado, voy a ver si hablo con  uno de los desarrolladores que tengo un contacto común y el enlace puede ser sencillo para charlar un poco con el a ver que futuro ven al proyecto porque viendo vias de mejorarlo no me gustaría que nos quedáramos ahí "estancados" y me planteo hacer un fork si fuera necesario para poder ir a nuestro ritmo.

Lo voy teniendo ya bastante cerrado pero tenía otras features arrancadas de integración del nuevo motor en el actual icestudio y quiero cerraros todo el tema para pasaros paquete. 

Esto de las xilinx me ha liado más de lo que pensaba, porque nos hemos metido a más que a integrar la toolchain, estamos corrigiendo bugs de la toolchain, ampliando funcionalidades (por ejemplo opencx7 no reporta fmax de los relojes, ahora tenemos el fmax de cada reloj en el reporte aunque solo podamos fijar como target para nexpnr uno pero el report lo tenemos, esto he tenido que tocar el core de c++, esto luego ha derivado a mejorar el reporte de la toolchain en Apio y así , es como cuando crees que está todo limpio, levantas la alfombra. y te encuentras a los tigres XD

Cuento conque en el fin de semana terminaré de rematar flecos en los varios frentes y ya os dejo una nueva versión publicada.

Sobre el código y demás lo ideal Fernando es que acabaras preparando una colección, "Artix" , no digo xilinx porque imagino que las primitivas cambiarán por chip o al menos algunas. Para los PLL es menos problema porque si hacemos un asistente con tener el c´doigo verilog lo idea sería que el asistente cubra todas las familias que podamos de todas las fpgas y tengamos un único generador de plls, pero para el resto de bloques que sean primitivas propias de la placa una colección y que la metamos en icesHub sería lo ideal.

Tengo pendiente como baja prioridad el cerrar el entorno colaborativo en iceHub y iceTutorial (básicamente que cualquier persona pueda subir sus tutoriales, tarjetas, diseños....) sin tener que pasar por github o desde sus propios githubs pero publicando en el pool común el paquete, bueno esto ya os lo explicaré cuando lo montemos.

Me gustaría que diera tiempo a montalo antes de cerrar la estable pero a ver como vamos que lo de las xilinx está llevando trabajo.

Cualquier prueba que vayas avanzando o problemas que vayas encontrando lo vamos viendo.

Un abrazo a todos!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/8e2f718b-c799-4621-a2de-0d632c543818n%40googlegroups.com.

[beni...@gmail.com]

Hola Charli,

Sí, este toolchain XC7 tiene bastantes incompatibilidades, por ejemplo , estoy intentando crear un proyecto que me genere una pantalla por VGA de 640x480 y por más que veo que el código está bien , me da error al sintetizar

Por favor, ¿le podrías echar un visitacillo?

Te adjunto el ice del proyecto

Gracias y un saludo
Fernando Mosquera

[beni...@gmail.com]

Hola Charli,

Según parece, el error es de Yosys y más acusado con las Xilinx 7 series.
Se llama AST and Width interference

Y aquí la IA me lo explica detalladamente

The "AST width-inference crash" is not a problem with your logic; it is a C++ exception thrown by the Yosys compiler itself when its internal math gets confused by certain Verilog syntax patterns.

Here is a detailed breakdown of what is happening, why it crashes, and why our workarounds fix it.

---

1. What is the AST and Width Inference?

When Yosys reads your Verilog code, it doesn't immediately turn it into gates. First, it parses the text into an Abstract Syntax Tree (AST)—a massive, interconnected web of C++ objects where every variable, operator, and literal is a "node."

Verilog is a "loosely typed" language regarding bit widths. If you write a + b, and a is 8 bits and b is 4 bits, Yosys has to figure out how many bits the result should be. This process is called Width Inference. Yosys traverses the AST, passing "width context" up and down the tree to ensure every node knows exactly how many bits it is supposed to be.

2. The Root Cause of the Crash

In certain versions of Yosys (particularly those bundled with open-source flows like F4PGA/SymbiFlow for Xilinx 7-series), there is a bug in the C++ code that handles width inference for specific comparison operators (especially >= and >) when they are mixed with complex boolean logic or inline assignments.

When Yosys encounters a triggering pattern, the width propagator gets confused. It fails to assign a bit-width to a temporary AST node, leaving it at 0 bits.

Later in the compilation flow (usually during the opt optimization pass or the techmap technology mapping pass), the C++ backend tries to read or write to bit index 5 of this 0-bit vector. Because the vector's size is 0, C++ throws a fatal exception:

          terminate called after throwing an instance of 'std::out_of_range'
          what():  vector::_M_range_check: __n (which is 5) >= this->size() (which is 0)

The compiler literally crashes to your desktop, aborting the scons build.

3. The Specific Triggers (Why your code crashed)

Trigger A: The >= Operator and Parameter Widths

        localparam H_SYNC_START = 816;
        // ...
        hsync <= (h_count >= H_SYNC_START);

By default, Verilog parameters are parsed as 32-bit signed integers. Your h_count register is 11-bit unsigned. When Yosys evaluates >=, it has to extend the 11-bit register to 32 bits to do the comparison. The AST node for $ge (greater-than-or-equal) in these specific Yosys versions has a bug where it miscalculates the resulting width during this signed/unsigned extension, resulting in the 0-bit vector crash.

Trigger B: Inline Wire Initialization with Comparisons

        wire display_en = (h_count < 800) && (v_count < 600);

When you initialize a wire on the exact same line you declare it, Yosys builds the AST slightly differently than if you used a separate assign statement. If the right side of the = contains a comparison operator, the AST builder sometimes fails to propagate the 1-bit boolean context correctly, again resulting in a 0-bit width inference.

Trigger C: Deeply Nested Inline Boolean Logic

      hsync <= ~((h_count < 816) ^ (h_count < 912));

When you put complex logic (~, ^, &&) directly inside a sequential always block, Yosys has to create "temporary" AST nodes to hold the intermediate results. The width propagator struggles to pass the 1-bit context through multiple layers of inline temporary nodes, leading to the same 0-bit crash.

4. How the Workarounds Fix the AST

The "bulletproof" Verilog style we used isn't just about avoiding bugs; it's about forcing Yosys to use its most stable, heavily tested C++ code paths.

Fix 1: Replacing >= with < and ~

     // BAD (Triggers the $ge bug):
     wire x = (h_count >= 816);

     // GOOD (Uses the highly stable $lt node):
     wire h_lt_816 = (h_count < 816);
     wire x = ~h_lt_816;

The < (less than) operator is the oldest, most battle-tested comparison operator in Yosys. By replacing >= with < and a logical NOT (~), we force Yosys to use the $lt AST node, which has perfect width inference. 

Fix 2: Separating Wire Declarations from Assigns
     // BAD (Triggers inline init bug):
     wire display_en = (h_count < 800) && (v_count < 600);

     // GOOD (Forces standard continuous assignment parsing):
     wire display_en;
     assign display_en = (h_count < 800) && (v_count < 600);   

By separating the declaration from the assignment, we force Yosys to parse the wire as a standard node, and the assign as a standard continuous assignment. This bypasses the buggy inline-initialization AST builder entirely.  Fix 3: Atomic Decomposition (Flattening the AST)

    // BAD (Deeply nested temporary nodes):

     hsync <= ~((h_count < 816) ^ (h_count < 912));

    // GOOD (Flat, 1-bit atomic wires):
    wire h_lt_816; assign h_lt_816 = (h_count < 816);
    wire h_lt_912; assign h_lt_912 = (h_count < 912);
    wire h_sync_region; assign h_sync_region = (~h_lt_816) && h_lt_912;

    always @(posedge clk) begin
        hsync <= ~h_sync_region; // Trivial 1-bit register update
    end

By breaking the logic into individual wire assignments, we flatten the AST. Instead of Yosys having to calculate the width of a massive, nested expression tree all at once, it calculates the width of tiny, 1-bit atomic gates. The always block then becomes a trivial, flat register update, which is guaranteed not to crash.

Summary

The "Yosys AST width-inference crash" is essentially the compiler's C++ backend tripping over its own shoelaces when trying to figure out how many bits a complex, inline, mixed-signedness comparison should be. By writing flat, atomic, Verilog-1995 style code using only the < operator, we bypass the buggy C++ code paths entirely and force the compiler to synthesize the exact same hardware safely.

Saludos

Fernando Mosquera

[Carlos Venegas]

Hola Fernando!, si este tipo de crashes son los que os comentaba anteriormente y que ya he arreglado 4, tengo pendiente subir todo loque he ido avanzando de la toolchain a nivel de código aun no lo he hecho porquenecesito sentirme "seguro" con mi codebase antes de compartirlo y hacer PRs pero creo que vamos a aportar mucho al proyecto madre.

Por otro lado gran parte de estos crashes es por usar versiones antiguas de yosys, ahora posiblemente muchos de estos problemas que son como quien dice del "core" del algoritmo interno ya están solucionados en las nuevas versiones de yosys pero es lo que os comentaba que opencx7 usa versiones bastante antiguas del código base, mi  sensación es que el proyecto anda bastante estancado.

Tengo un amigo muy amigo del principal desarrollador tengo pendiente hablar con el a ver si saco feeling del estado real del proyecto y ver como orientar nuestra colaboración.

En cualquier caso gracias por el research siempre ayuda, en principio la ia  te está dando consejos de como orientar el código verilog, básicamente para "esquivar" las deficiencias de yosys en estas fpgas, básicamente si yosys explota aquí , intenta evitar pasar por ahí.

Voy a ver bien el código generado por tu .ice y depuraré a ver donde explota en yosys exactamente, estoy planteandome intentar una migración al nuevo yosys porque puede que nos ahorraría muchos pasos.

Lo bueno de esto es que tal cual lo tenemos ahora todo montado, podemos congelar icestudio yo diría a partir de la semana que viene en cuanto os suba el último lote de mejoras este finde, probamos y sacamos estable.

En paralelo podemos ir mejorando la toolchain porque eso ya se puede ir actualizando literlamente sobre la marcha.

De echo estoy preaprando una mejora par apio porque la verificaciónd e las xilinx falla en casos complejos más allá del led (todos los que has mandado fallan al verificar) y el problema en este caso es de apio que está derivando verilator a las ice40 casi en cualquier caso y en cuanto aparece cualquier primitiva rara explota, y esto la solución está en apio en incluir en función de la fpga una serie de ficheros extra para que verilator sepa donde sacar el código.

Seguimos!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/2a00c006-78ed-48e0-be73-aff39fae8e76n%40googlegroups.com.

[Carlos Venegas]

Buenas Fernando, vas cavando en la mina de oro y encontrando todas las "vergüenzas" XD

Ya está solucionado y aparentemente parece que el build funciona ;) eso sí tienes que actualizar apio y hacer un cambio en el .ice te lo explico en el desarrollo del mensaje, ya nos dirás si funciona!

y de paso he arreglado la verificación en las xilinx:

El .ice que has mandado moría en apio build con el mensaje  libc++abi: terminating due to uncaught exception of type std::out_of_range: vector (SIGABRT, sin mensaje )

Lo que hice fue lanzarlo y ejecutarlo en modo debug con lldb (es como gdb pero de la suite llvm) y saqué  el backtrace que me indicó exáctamente donde fallaba el frontend JSON de nextpnr-xilinx, en el importador jerárquico (merge_nets, frontend/frontend_base.h).

El problema era un vector interno (net_old_indices)  que nunca se redimensionaba, esto como me imaginaba y os comenté antes era un bug latente del fork desde su origen, que el mainline de nextpnr corrigió hace años (dos emplace_back() que el fork de opencx7 nunca portó). 

Hasta ahora nunca lo vimos porque synth_xilinx no aplana por defecto y lo que habéis probado hasta ahora entre Juan y tú eran diseños de prueba de un solo módulo.

Este código que has hecho es el primero más complejo que contiene módulos anidados con assigns de passthrough, en realidad  es el primer diseño jerárquico real que pasa por la toolchain y  que ha disparado merge_nets a la primera.

 Lo que he dejado hecho:

  1. El crash  frontend-hier-merge-nets.patch, el ejemplo que has mandado pasa.
  2. Robustez del report descubierta de rebote. Si el análisis de timing falla (p. ej. lazos combinacionales por un feedback de PLL mal cableado), el hook de report abortaba el build entero después de rutear bien y sin escribir el fasm. Ahora captura el error y devuelve tabla vacía y el build termina (apio va a ganar un montón de pequeñas features para todas las placas gracias a esto,no solo para xilinx).
  3. Cobertura para que no reincida, he añadido a la suite de tests un caso jerárquico añadido al CI de Windows.
 

Por otro lado he estado viendo el diseño, a parte del crash, creo que el diseño no funcionaría aunque sintetizara porque por lo que he podido ver el pll no está bien cableado (como no puedo probarlo en una fpga real me lo tienes que confirmar), te cuento sobre el código de tu .ice:

 CLKFBOUT(clkfbout_clk_wiz_0)  es la señal que el  PLL  saca  el feedback.
 CLKFBIN(clkfbout_buf_clk_wiz_0)  es la señal por la que el PLL espera recibir el feedback .
 

pero nada conecta el primero con el segundo: clkfbout_buf_clk_wiz_0 está declarado y nunca conducido. En el template original de Vivado que he localizado de este pll hay un tercer buffer, la sección "Feedback buffering" con BUFG clkf_buf que parece que es lo que conecta uno con otro.
 

De echo yosys avisaba con Wire ...clkfbout_buf_clk_wiz_0 is used but has no driver.....

  El fix es añadir ese BUFG, lo único que cambia son las 4 líneas marcadas; el resto del bloque queda idéntico, incluida la instancia del PL):

      //------------------------------------
      // Input buffering
      //------------------------------------
      wire clk_in1_clk_wiz_0;

      wire clk_in2_clk_wiz_0;

      IBUF clkin1_ibufg(
       .O (clk_in1_clk_wiz_0),
       .I (clk_50mhz));

      //assign clk_in1_clk_wiz_0 = clk_50mhz;

      //-----------------------------------
      // Feedback buffering                  // <-- AÑADIDO: cierra el lazo
      //-----------------------------------          //     CLKFBOUT -> BUFG -> CLKFBIN
      BUFG clkf_buf(                           // <-- AÑADIDO
       .O (clkfbout_buf_clk_wiz_0),    // <-- AÑADIDO
       .I (clkfbout_clk_wiz_0));            // <-- AÑADIDO

      //-----------------------------------
      // Output buffering
      //-----------------------------------

      BUFG clkout1_buf(
       .O   (clk_25mhz),
       .I   (clk_out1_clk_wiz_0));
      //assign clk_28mhz = clk_out1_clk_wiz_0;

Añade esa parte al pll del .ice y actualiza Apio y con eso debería de funcionar o eso creo.... crucemos los dedos!!!!!!

[beni...@gmail.com]

Hola Charli, 

Acabo de modificar lo que me has dicho del PLL y he actualizado el Apio (desinstalado y vuelto a instalar)

¡ Ahora ya funciona !  ¡Muchísimas gracias, Charli!

Esto es lo que se muestra en pantalla

Y finalmente el archivo ICE es asi

Con los cambios en el PLL que propusiste

La verdad es que para que fuera 640x480 a 60 Hz , el reloj debería de ser de 25.175 MHz pero yo le he metido 25 Mhz

Y aquí se ve cómo es la señal, 59.4 Hz de sincronismo vertical. De todos modos la mayoría de los monitores admiten esa pequeña variación 

Adjunto el archivo ICE para que Obijuan lo pueda probar en su Basys 3, aunque la VGA del Basys 3 es de 12 bits ( 4 bits por color), algo se deberá de ver. Pero en la Basys3 el reloj es de 100 Mhz , así que hay que modificar el PLL para que partiendo de 100 Mhz se genere uno de 25 Mhz o 25.125 Mhz

¡Veo que vamos mejorando mucho el toolchain y si seguimos así lo vamos a dejar niquelado!

Un saludo a todos

Fernando Mosquera

[Carlos Venegas]

Ostras Fernando!! me alegro mucho!! yo ahora me siento como en la peli de "the martian" , estoy en el centro de control mandándote cosas pero el que prueba de verdad y está en el campo real eres tú XD

Me ha hecho mucha ilusión verlo funcionando, la verdad, a ver si alguien más se anima a probar en otras placas xilix y vamos completando el cuadro.

Si no surge nada más que me retrase intentaré terminar el nuevo bundle y los tutoriales sobre alta de tarjetas este fin de semana.

Cualquier novedad en el frente me contáis!

¡Buen finde!

--
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/610a73be-dae5-414b-9eb2-8cfb0e458b1dn%40googlegroups.com.