Bonne remarque : une mise en contexte d'openFPGALoader vis-à-vis des autres outils aurait été utile.
En ce qui concerne les différences/équivalences avec xc3sprog :
openFPGALoader vise à supporter tous les fabricants et non seulement Xilinx (depuis le début de la semaine les GateMate de CologneChip le sont également donc même des composants qui ne sont pas encore disponibles). La liste des composants supportés par xc3sprog est très longue, celle de openFPGALoader pourrait/devrait être complétée en injectant, pour certains modèles, l'ensemble des IDCodes (les Artix, spartan6, cyclone ont étés suffisament testés pour considérer que le code est fonctionnel quelque soit la taille du composant)
La liste des câbles dans xc3sprog est relativement limitée (principalement du ftdi, du port parallèle et du cypress FX2) alors que openFPGALoader supporte pour le JTAG (évidemment) du FTDI (MPSSE et bitbang), les sondes altera USB-blaster, dirtyJTAG, orbtrace, … Mais également le DFU et l'accès direct aux flash SPI. Cette limitation des cables est parfois un soucis (sous l'impulsion de Uwe Bonnes - le mainteneur de xc3sprog - j'ai acheté une plateforme à base de coolrunnnerII avec une connecteur pour USB-blaster -> il a fallu faire usage de cables dupont pour tester avec xc3sprog et une sonde digilent)
Écrire un bitstream en flash, pour Xilinx et Altera/intel impose de charger en RAM un gateware dédié, avec xc3sprog, il doit être spécifié, avec openFPGALoader cet aspect est transparent pour l'utilisateur (utiliser un FPGA avec une flash interne ou externe se fait exactement de la même manière).
Et en effet, il semble que xc3sprog n'évolue plus trop, Uwe Bonnes semble se concentrer sur blackmagic à l'heure actuelle (et a contribué à openFPGALoader).
Evidemment ce n'est pertinent que pour utiliser verilator ou quand il y a un mélange verilog + VHDL sinon il devient possible de directement utiliser le VHDL comme présenté à ghdl-yosys-blink
Il y a également la série des smartfusion2 de microsemi. Une base de cortex-m3.
Là encore soft proprio, très pénible à installer et à utiliser (une énorme partie est en 32bits -> docker conseillé).
Comme le problème avec la somme de contrôle est mentionné dans cet article, je souhaitais signaler que celui-ci vient d'être réglé à la fois dans Apicula et openFPGALoader.
Maintenant plus de "fausse erreur"!
En effet, il existe un framework dédié aux FPGA dans le noyau et l'idée de openFPGALoader n'est pas d'entrer en concurrence avec celui-ci.
Le framework dans Linux a pour but de proposer une interface unifiée (plus ou moins) pour la configuration. Dans le cas des zynq ou socfpga les drivers correspondants vont taper directement dans la mémoire pour envoyer le bitstream. Dans le cas d'autres FPGAs tels que les ice40 ou machXO2 ils communiquent en SPI.
Le soucis avec ce modèle est qu'il ne réponds pas aux contraintes des cartes d'évaluations qui, la plupart du temps, se programment en JTAG par le biais d'un convertisseur (souvent un FTDI). Pour ces cibles il faut avoir un logiciel en espace utilisateur (ou alors créer un pilote avec le risque d'enter en conflit avec ftdi_sio et de perdre le port série généralement disponible) qui, souvent, est un logiciel propriétaire.
openFPGALoader a pour but de fournir un outil unifié pour répondre à ce cas de figure en bon voisinage avec le framework fpga du noyau.
Ne permettre que des jeux français n'est pas un choix sans raison... L'argent perdu par les français ne devrait pas sortir *théoriquement* du pays.
C'est comme pour l'essence tu n'as pas le droit d'utiliser des solutions plus économiques/moins polluantes car l'état n'a pas forcément de moyen pour toucher sa dîme.
[^] # Re: Différences par rapport à xc3sprog
Posté par gwenhael goavec-merou (site web personnel) . En réponse à la dépêche Sortie de la version 0.6.0 du configurateur de FPGA openFPGALoader. Évalué à 5.
Bonne remarque : une mise en contexte d'openFPGALoader vis-à-vis des autres outils aurait été utile.
En ce qui concerne les différences/équivalences avec xc3sprog :
openFPGALoader vise à supporter tous les fabricants et non seulement Xilinx (depuis le début de la semaine les GateMate de CologneChip le sont également donc même des composants qui ne sont pas encore disponibles). La liste des composants supportés par xc3sprog est très longue, celle de openFPGALoader pourrait/devrait être complétée en injectant, pour certains modèles, l'ensemble des IDCodes (les Artix, spartan6, cyclone ont étés suffisament testés pour considérer que le code est fonctionnel quelque soit la taille du composant)
La liste des câbles dans xc3sprog est relativement limitée (principalement du ftdi, du port parallèle et du cypress FX2) alors que openFPGALoader supporte pour le JTAG (évidemment) du FTDI (MPSSE et bitbang), les sondes altera USB-blaster, dirtyJTAG, orbtrace, … Mais également le DFU et l'accès direct aux flash SPI. Cette limitation des cables est parfois un soucis (sous l'impulsion de Uwe Bonnes - le mainteneur de xc3sprog - j'ai acheté une plateforme à base de coolrunnnerII avec une connecteur pour USB-blaster -> il a fallu faire usage de cables dupont pour tester avec xc3sprog et une sonde digilent)
Écrire un bitstream en flash, pour Xilinx et Altera/intel impose de charger en RAM un gateware dédié, avec xc3sprog, il doit être spécifié, avec openFPGALoader cet aspect est transparent pour l'utilisateur (utiliser un FPGA avec une flash interne ou externe se fait exactement de la même manière).
Et en effet, il semble que xc3sprog n'évolue plus trop, Uwe Bonnes semble se concentrer sur blackmagic à l'heure actuelle (et a contribué à openFPGALoader).
J'espère que ma réponse a clarifié ce point.
[^] # Re: CocoTB + tkinter pour rendre les simulations plus vivantes
Posté par gwenhael goavec-merou (site web personnel) . En réponse à la dépêche CocoTB 1.4.0, la maturité. Évalué à 3.
Il est en effet possible de faire
VHDL -> verilog -> synthèse.
C'est comme ça qu'enjoy-digital fait avec litex pour le microwatt (softcore POWER ISA).
Evidemment ce n'est pertinent que pour utiliser verilator ou quand il y a un mélange verilog + VHDL sinon il devient possible de directement utiliser le VHDL comme présenté à ghdl-yosys-blink
Globalement ça marche plutôt bien
[^] # Re: Nouveauté ?
Posté par gwenhael goavec-merou (site web personnel) . En réponse à la dépêche EOS S3, le bitstream libéré !. Évalué à 3.
Il y a également la série des smartfusion2 de microsemi. Une base de cortex-m3.
Là encore soft proprio, très pénible à installer et à utiliser (une énorme partie est en 32bits -> docker conseillé).
# somme de contrôle
Posté par gwenhael goavec-merou (site web personnel) . En réponse à la dépêche Apicula : lancement de la libération du FPGA Gowin GW1N. Évalué à 1.
Comme le problème avec la somme de contrôle est mentionné dans cet article, je souhaitais signaler que celui-ci vient d'être réglé à la fois dans Apicula et openFPGALoader.
Maintenant plus de "fausse erreur"!
[^] # Re: openFPGALoader
Posté par gwenhael goavec-merou (site web personnel) . En réponse à la dépêche La libération des FPGA et des ASIC bien engagée pour 2020. Évalué à 1.
En effet, il existe un framework dédié aux FPGA dans le noyau et l'idée de openFPGALoader n'est pas d'entrer en concurrence avec celui-ci.
Le framework dans Linux a pour but de proposer une interface unifiée (plus ou moins) pour la configuration. Dans le cas des zynq ou socfpga les drivers correspondants vont taper directement dans la mémoire pour envoyer le bitstream. Dans le cas d'autres FPGAs tels que les ice40 ou machXO2 ils communiquent en SPI.
Le soucis avec ce modèle est qu'il ne réponds pas aux contraintes des cartes d'évaluations qui, la plupart du temps, se programment en JTAG par le biais d'un convertisseur (souvent un FTDI). Pour ces cibles il faut avoir un logiciel en espace utilisateur (ou alors créer un pilote avec le risque d'enter en conflit avec ftdi_sio et de perdre le port série généralement disponible) qui, souvent, est un logiciel propriétaire.
openFPGALoader a pour but de fournir un outil unifié pour répondre à ce cas de figure en bon voisinage avec le framework fpga du noyau.
[^] # Re: Ca promet dans 10 ans ...
Posté par gwenhael goavec-merou (site web personnel) . En réponse à la dépêche Comment accéder à Internet (un guide de 2025). Évalué à 1.
C'est comme pour l'essence tu n'as pas le droit d'utiliser des solutions plus économiques/moins polluantes car l'état n'a pas forcément de moyen pour toucher sa dîme.