Développer sur FPGA est très frustrant pour un libriste. Les fondeurs de FPGA ne fournissant pas les spécifications de leurs composants, il n’existait pas jusqu’à présent d'outils open sources pour générer les binaires de configuration appelés «bitstream».
Du coup c'est toute la chaîne de développement qui est compromise : pas d'outils de synthèse HDL, pas d'outils de placement routage, …
Il existe bien des projets universitaires comme VPR, RapidSmith ou ABC. Mais ces outils ne permettent de réaliser qu'une étape du développement et nécessite de repasser par les outils du fondeur pour générer le bitstream.
On trouve quelques projets de reverse de bitstream comme debit ou Torc. Mais ces projets n'ont pas encore aboutis (debit) ou imposent de repasser par les outils fondeurs (torc) pour ne pas les froisser (et garder leurs financements universitaire).
Bref, le développement FPGA restait jusqu’à présent un cauchemar de libriste. Obligé d'utiliser les outils horribles des fondeurs (archive de plus de 10Go buggés qui s'intègrent mal aux distributions Linux et je ne parle même pas de l'éventualité de les porter sur d'autres plate-forme que x86).
Mais tout cela est du passé (enfin presque) car il existe désormais une chaine complète de logiciel libre pour développer sur le FPGA de lattice ice40 !
Nous devons cela au travail de Wolf Clifford et Cotton Seed.
Clifford est l'auteur du logiciel de synthèse Verilog Yosys et Cotton du logiciel de placement routage Arachne-pnr. Clifford a publié une vidéo de son projet IceStorm, montrant comment générer un bitstream pour le FPAG ice40 du kit lowcost ($20) iCEstick.
Grâce à eux, il est désormais possible de faire du développement FPGA dans un environnement entièrement libre et à moindre prix en plus !
# Suite fondeur : si, ça marche
Posté par marzoul . Évalué à 10.
C'est quand même vachement partial. Exemple chez Xilinx : depuis au moins 6 ans, ça marche impeccable sur GNU/Linux, parfaitement intégré, autant en 32 qu'en 64 bits.
Les 10 Go et plus ne viennent pas (forcément) d'une volonté gratuite de flooder les disques du monde, il suffit de regarder la masse de références de FPGA supportées par la suite de dev, chacune livrée avec les biliothèques calibrées pour générer des choses optimisées pour la clible en question.
Pour les bugs, quand il y en a (quand ils sont remontés) ils sont corrigés dans la version suivante. L'apparition de nouveaux bugs n'est pas une caractéristique du monde non-libre…
Ce qui est embêtant est surtout que la suite de placement-routage est payante pour tous les FPGA de taille à peu près supérieure à zéro (chez la majorité des fondeurs, je crois). Pour ce qui est de la synthèse logique ou d'un front-end HLS, il y a des outils libres assez génériques, mais le placement-routage est bloquant.
Sinon, la nouvelle est de très bon augure ! Ce qui serait bien serait d'arriver à un outil de palcement-routage aussi générique que possible, pour faciliter le portage pour les FPGA d'autres fondeurs.
# L'EDA est un monde compliqué pour l'open source
Posté par woopla . Évalué à 10.
EDA = Electronic Design Automation, la CAO pour l'électronique en bon français.
Le problème de ces outils, c'est que ce sont des outils très spécialisés, utiles pour un nombre de personnes finalement assez restreint. De plus, ce sont des outils extrêmement complexes, ce qui rend leur développement et leur support long et fastidieux.
Un navigateur web, un noyau ou un langage (et son compilateur) sont utilisés par énormément de monde. Du coup, même 0,0005% de gens qui y contribuent, ça fait plusieurs centaines de contributeurs plus ou moins réguliers. Et surtout, il est finalement assez facile de vérifier que ça marche (au moins sur sa machine) - est-ce que la page web s'affiche, est-ce que mon programme s'exécute…
Un outil de Place & Route (P&R), c'est peut-être quelques dizaines de milliers de personnes dans le monde qui s'en servent. Et ces gens ne sont pas des programmeurs, ce sont des designers qui ont déjà un boulot suffisamment compliqué pour ne pas pouvoir passer du temps à coder un outil qui a quelques unes des caractéristiques suivantes:
- utilisation régulière de plusieurs centaines de gigaoctets de RAM (pour un processus)
- multithread le plus massif possible, mais compliqué parce qu'on doit avoir une vue unifiée de toute la puce, qui représente des dizaines de millions d'objets (chaque objet pouvant lui même contenir de nombreux sous-objets)
- utilisation de moult types de contraintes issues de domaines disjoints: timing (combien de picosecondes de retard a mon signal?), parasites (l'influence des fils qui passent à côté de mon signal critique), process (est-ce que le fondeur va pouvoir réaliser ce que je demande?), etc.
Il faut avoir une connaissance pointue de chacun des domaines de modélisation, des fichiers d'entrée qui sont eux mêmes issus d'autres programmes complexes, avoir des performances toujours meilleures parce que les procédés de fabrication se complexifient à vitesse V et que la taille des puces (en nombre de transistors) augmente elle aussi de manière faramineuse.
Chaque outil de P&R, ce sont plusieurs centaines de personnes qui travaillent dessus à plein temps, et qui ont besoin des connaissances métiers de leurs clients pour valider tout ça. C'est pas un projet qu'on commence tout seul dans son coin.
Du coup je vois mal comment un logiciel libre pourrait percer dans le milieu. Sauf à faire un outil open source pour lequel tu vends du support, à la RedHat. Mais les boîtes sont tout sauf prêtes à se lancer dans ce business model!
[^] # Re: L'EDA est un monde compliqué pour l'open source
Posté par Ms-Mac . Évalué à 10.
Tout projet libre qui vient au monde a le droit à un feu d'artifice même si
tu"le milieu" ou "le business model" annonce déjà sa mort. Savoir que des gens ont pensé autrement même une fois, mérite mes applaudissements.Tout le monde a un cerveau. Mais peu de gens le savent.
[^] # Re: L'EDA est un monde compliqué pour l'open source
Posté par woopla . Évalué à 4.
Ça n'est pas une critique de ce logiciel, loin s'en faut. Je trouve ça courageux. C'est plutôt une explication des raisons pour lesquelles si peu de logiciels libres existent dans ce domaine, et si encore moins ont du succès.
Un exemple d'outil qui a peu ou prou réussi c'est KLayout. Notamment parce qu'il tourne sous Windows, ce qui est pratique pour regarder vite fait un GDS depuis son ordinateur local (genre pour faire des screenshots).
Mais il ne faut pas se leurrer, il n'est pas utilisé dans des flots de production, ne serait-ce que parce qu'il n'y a pas de support payant - quelqu'un sur qui une boite peut hurler en cas de problème à deux jours de l'envoi du design chez le fabricant :)
[^] # Re: L'EDA est un monde compliqué pour l'open source
Posté par ntimeu . Évalué à 3.
Effectivement, peu de personnes travaillent directement sur des outils aussi spécialisés. Néanmoins, l'arrivée d'une telle chaîne d'outils est bienvenue. Je m'intéresse depuis quelques années aux FPGA, et le manque d'outils complets libres est assez flagrant dans ce domaine. Dommage que le VHDL ne soit pas supporté :)
# Un peu réducteur comme raisonnement...
Posté par Fabrice Mousset (site web personnel) . Évalué à 5.
Bon, je ne vais pas me faire des amis… Mais tampis, je me lance.
Ayant travaillé pendant plusieurs années avec des FPGA de divers sortes, surtout ceux de chez Altera, je me doit de réagir sur cette news.
Tout d'abord je suis heureux d'apprendre qu'un logiciel libre de ce genre existe et je félicite les auteurs pour leur travail et leur engagement. Ce n'est pas un travail simple.
Après, je ne suis pas du tout de l'avis de l'auteur de la news pour dire que les logiciels privateurs fournis par les fondeurs sont mauvais, bourrés de bug, etc. Je suis même plutôt de l'avis inverse. Xilinx a longtemps eu la réputation de fournir une suite logicielle pas trop terrible mais à pris un assez bon virage depuis ces 5 dernières années. Pour ce qui est d'Altera, je n'ai jamais hésité avant d'installer une mise à jour de leur suite de développement, c'est dire ce que je pense de la qualité de leur logiciels ;-) Après les autres, qui ne ramassent que les miettes et son dans des secteurs de niche, il n'est pas évident d'avoir une suite de bonne qualité.
Et il ne faut confondre logiciel libre et qualité/stabilité. L'un ne vient pas forcément avec l'autre! Ca serait trop simple.
Après, il faut comprendre pourquoi tout est aussi cloisonné. Quoi qu'on en dise, le secteur des FPGA/CPLD est un secteur très réduit et les coûts de développement (R&D+production) sont énormes. Les FPGA sont souvent précurseurs dans divers procédés de fabrication. Avoir un retour sur investissement n'est pas une chose simple.
Le nerf de la guerre se situe au niveau des outils de placement routage et d'analyse de timing qui nécessitent une parfaite connaissance de la structure même du FPGA et des temps de propagation des signaux entre les différents blocs du FPGA. Caractériser un FPGA pour ces outils là, demande beaucoup de temps et de travail et donc d'argent. Donc donné cela en libre accès, c'est donné également beaucoup d'informations sensibles aux concurrents, et donc un peu joué avec la santé de l'entreprise.
Après que cela soit frustrant pour un libriste convaincu je le conçoit aussi ;-)
[^] # Re: Un peu réducteur comme raisonnement...
Posté par glisse . Évalué à 4.
Je crois que tu surestimes l'importance des informations nécessaire pour le timing. Tout les constructeur de FPGA suivent les même principes et en gros c'est des blocs pour la logique (LUT, 2-3 flipflop, …), blocs mémoires et pour interconnecter le tout des switch-box. Il n'y a rien de secret ici, tout ça est décrit avec plus ou moins de détails dans les documents publique de ces constructeurs. Les différences sont plutôt sur des choix fin, comme l'inter-connectivité maximale entre les switch-box ou le ratio entre les différents blocs. Ces choix fin n'ont pas vraiment d'avantage intraséque, il vise a répondre au mieux à la majorité des cas. Souvent, d'ailleur, chaque constructeur change par petites touche ces aspects d'une génération à l'autre, preuve qu'il n'y pas de solution miracle. De plus les timing de chacun de ces blocs sont souvent décrit assez précisement dans les documentations publique.
Je pense que l'on peut facilement avoir le timing correct à 90% de la clock théorique maximal. Après oui quand on pousse le FPGA au limite de la fréquence maximal que ses blocs supportent, là il faut une connaissance très fine du delay de chaque bloc. Mais même cette information ne révéle pas grand chose (cela révèle probablement plus d'information sur le process utiliser pour faire le FPGA que sur la structure du FPGA lui même qui est déjà largement publique).
Personnellement je déteste utiliser les outils propriétaire pour les FPGA, ils sont lent, difficilement utilisable depuis un Makefile, les messages d'erreurs et de warning qu'ils produisent sont enchevétrés avec des informations annexes qu'il est souvent difficile de faire la part des choses. Il est presque impossible d'utiliser les blocs dure (controlleur mémoire, controlleur PCIE, …) sans avoir à intégrer un fichier avec une license douteuse dans son projet. Bref en ce qui me concerne ces outils sont un frein.
# TORC
Posté par bamban . Évalué à 3.
Il existe un truc (ciblé reconfigurable, certes), mais qui semble prometteur.
Site web du projet (un peu mort) : http://torc.isi.edu
Papier présentant le boulot sur cette page : http://www.isi.edu/~nsteiner/publications/
"Torc: Towards an Open-Source Tool Flow"
Bon, disons que je n'ai pas tout pigé au bouzin, mais il semblerait qu'il y ait la possibilité d'aller jusqu'au bout (ou alors ce n'est pas le cas mais c'est en cours de dev).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.