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!
# L'EDA est un monde compliqué pour l'open source
Posté par woopla . En réponse au journal Enfin une chaîne de développement complètement open source pour un FPGA. É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!