De mon point de vu, ce projet est un grand coup de pied dans la fourmilière du monde des FPGA. En avançant sur ce projet tu casses le mythe d'un FPGA qui ne serait accessible qu'aux très grosses compagnies et ultra-verouillés (Il parait que pour lire la datasheet des librairies de fondeurs, il faut d'abord signer un premier accord de non divulgation (NDA) pour pouvoir lire l'accord principal de non-divulgation ;).
Je connaissais Archipelago, mais il n'a jamais atteint aucune fonderie, et surtout il s'est visiblement cantonné à un seul projet/thèse à Berkley.
Pour en revenir au reset asynchrone, c'est un vaste (et vieux) débat ;) Beaucoup de FPGA vont accepter les deux, par contre il faudra que ce soit homogène. Si on choisi asynchrone, il faut que tout le design soit en reset asynchrone.
Si l'on veux plusieurs type de reset il faudra séparer en «domaine de reset» de la même manière que l'on parle de «domaine d'horloge». Et il faudra bien soigner les «franchissements» de domaines.
En règle générale, dans le monde du FPGA on fait du reset asynchrone, dans le monde de l'ASIC du synchrone. Ça a d'ailleurs longtemps été un des points noir du langage Chisel, qui n'acceptait que le reset synchrone car ciblant les ASIC (pour produire les Risc-V à base de RocketChip).
Le (un des) Problème du reset asynchrone c'est le «relâchement» du reset qui doit être synchrone. Le (un des) problème du reset synchrone c'est qu'il faut ... une horloge pour faire le reset, et le franchissement des domaines d'horloges est (encore) plus compliqué.
Bref, le choix reset synchrone/asynchrone est loin d'être une évidence. Mais s'il est vrai que «à l'école» on apprend tous à faire du VHDL avec un reset asynchrone ;)
[^] # Re: chapeau
Posté par martoni (site web personnel, Mastodon) . En réponse au journal Nouvelles de kFPGA, le FPGA libre. Évalué à 5.
Bravo !
De mon point de vu, ce projet est un grand coup de pied dans la fourmilière du monde des FPGA. En avançant sur ce projet tu casses le mythe d'un FPGA qui ne serait accessible qu'aux très grosses compagnies et ultra-verouillés (Il parait que pour lire la datasheet des librairies de fondeurs, il faut d'abord signer un premier accord de non divulgation (NDA) pour pouvoir lire l'accord principal de non-divulgation ;).
Je connaissais Archipelago, mais il n'a jamais atteint aucune fonderie, et surtout il s'est visiblement cantonné à un seul projet/thèse à Berkley.
Pour en revenir au reset asynchrone, c'est un vaste (et vieux) débat ;) Beaucoup de FPGA vont accepter les deux, par contre il faudra que ce soit homogène. Si on choisi asynchrone, il faut que tout le design soit en reset asynchrone.
Si l'on veux plusieurs type de reset il faudra séparer en «domaine de reset» de la même manière que l'on parle de «domaine d'horloge». Et il faudra bien soigner les «franchissements» de domaines.
En règle générale, dans le monde du FPGA on fait du reset asynchrone, dans le monde de l'ASIC du synchrone. Ça a d'ailleurs longtemps été un des points noir du langage Chisel, qui n'acceptait que le reset synchrone car ciblant les ASIC (pour produire les Risc-V à base de RocketChip).
Le (un des) Problème du reset asynchrone c'est le «relâchement» du reset qui doit être synchrone. Le (un des) problème du reset synchrone c'est qu'il faut ... une horloge pour faire le reset, et le franchissement des domaines d'horloges est (encore) plus compliqué.
Bref, le choix reset synchrone/asynchrone est loin d'être une évidence. Mais s'il est vrai que «à l'école» on apprend tous à faire du VHDL avec un reset asynchrone ;)
J'ai plus qu'une balle