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.
[^] # Re: Un peu réducteur comme raisonnement...
Posté par glisse . En réponse au journal Enfin une chaîne de développement complètement open source pour un FPGA. É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.