Métastabilité :
J'ai consulté 'rapidement' l'article et j'ai compris le problème de propagation du signal sur des bascules avec plusieurs clocks dans le système.
Mais est-ce c'est notre cas ? Tous les signaux clock et pulse ont la même base non ? Ou considères-tu qu'ils peuvent dériver suffisamment pour créer le phénomène ?
Le signal provenant du bouton n'est pas synchronisé avec l'horloge du FPGA. Il est donc possible qu'un front (montant ou descendant) survienne en même temps que le front montant de l'horloge.
Or, si cela arrive on viole les temps de setup/hold et le comportement du registre d'entré devient analogique. La valeur de sortie de la bascule va rester dans un état «entre-deux» pendant un temps plus ou moins aléatoire puis elle va basculer vers 0 ou 1. Mais ce temps peut devenir suffisamment long pour que la bascule suivante récupère cette valeurs analogique-instable et la transmette elle même dans tout le design. Cette instabilité sera d'autant plus amplifiée qu'il y aura de la logique entre les deux bascules.
C'est la raison pour laquelle il est recommandé de mettre deux bascules D en série d'un signal d'entrée qui n'est pas synchronisé avec l'horloge du système. Cela diminue la probabilité de métastabilité, mais ça peut tout de même arriver. Par contre si cette double bascule n'est pas mise, il est à peu prêt certain que l'on aura des problèmes de métastabilité, et le comportement du système sera vraiment bizarre.
Calcul bpm : pas suivi le calcul
MIN_NS 6e10 (1 minute en nanoseconde)
TP_NS = ??
Peut-être aussi que btn_per_i est aussi divisé par TP_NS mais cela ne m'a pas paru évident.
btn_per_i compte le nombre de période de timepulse TP_NS. Une autre manière d'écrire l'équation serait :
Entrée/sortie de module
L'entrée de per_count c'est btn_i (qui existait déjà mais est-ce le même), mais la sortie de debounce c'est btn_o.
J'imagine donc que ces variables sont locales au module.
Tout à fait, les liens entre les modules se font par les ports que l'on connecte dans le composant «TOP»
A quel moment se fait le lien entre les Entrées/Sortie des modules ?
Division :
Est-ce que tu as essayé de voir ce que ça donnait avec le logiciel de synthèse, ou tu es certains que cela n'en vaut pas la peine et qu'il ne faut jamais compter dessus ?
J'avoue ne pas avoir essayé, mais je ne suis pas sûr que Yosys aurait suivi. C'est fondamentalement une mauvaise idée de toute manière. Le verilog n'est pas un langage de description «de haut niveau», il faut le voir un peut comme le «langage assembleur» des FPGA. Mais même avec des langages générateurs comme Migen/Chisel/SpinalHDL/Clash/... tu ne fait qu'instancier un «module» de division explicitement. Si l'on veut juste décrire l'algoritme ou le calcul et laisser le logiciel trouver comment l'architecturer il faut passer à la «synthèse de haut niveau».
Quelque part tu l'as posé le calcul, le logiciel ne peut pas le reproduire ?
Ça n'est pas le rôle d'un logiciel de synthèse, c'est par contre le rôle d'un logiciel de synthèse de haut niveau dit «HLS» pour High Level Synthesis. Mais dans ce cas on prend carrément un programme en C, C++, Matlab, Python que le logiciel va tenter de convertir en une architecture logiciel+hardware.
[^] # Re: j'ai quelques questions msieur !
Posté par martoni (site web personnel, Mastodon) . En réponse à la dépêche TapTempo en Verilog. Évalué à 6.
Le signal provenant du bouton n'est pas synchronisé avec l'horloge du FPGA. Il est donc possible qu'un front (montant ou descendant) survienne en même temps que le front montant de l'horloge.
Or, si cela arrive on viole les temps de setup/hold et le comportement du registre d'entré devient analogique. La valeur de sortie de la bascule va rester dans un état «entre-deux» pendant un temps plus ou moins aléatoire puis elle va basculer vers 0 ou 1. Mais ce temps peut devenir suffisamment long pour que la bascule suivante récupère cette valeurs analogique-instable et la transmette elle même dans tout le design. Cette instabilité sera d'autant plus amplifiée qu'il y aura de la logique entre les deux bascules.
C'est la raison pour laquelle il est recommandé de mettre deux bascules D en série d'un signal d'entrée qui n'est pas synchronisé avec l'horloge du système. Cela diminue la probabilité de métastabilité, mais ça peut tout de même arriver. Par contre si cette double bascule n'est pas mise, il est à peu prêt certain que l'on aura des problèmes de métastabilité, et le comportement du système sera vraiment bizarre.
Ma référence sur la métastabilité et le franchissement de domaine d'horloge.
btn_per_i compte le nombre de période de timepulse TP_NS. Une autre manière d'écrire l'équation serait :
Tout à fait, les liens entre les modules se font par les ports que l'on connecte dans le composant «TOP»
Dans le top qui s'appelle taptempo.
La connexions du module debounce est donné par le code suivant :
J'avoue ne pas avoir essayé, mais je ne suis pas sûr que Yosys aurait suivi. C'est fondamentalement une mauvaise idée de toute manière. Le verilog n'est pas un langage de description «de haut niveau», il faut le voir un peut comme le «langage assembleur» des FPGA. Mais même avec des langages générateurs comme Migen/Chisel/SpinalHDL/Clash/... tu ne fait qu'instancier un «module» de division explicitement. Si l'on veut juste décrire l'algoritme ou le calcul et laisser le logiciel trouver comment l'architecturer il faut passer à la «synthèse de haut niveau».
Ça n'est pas le rôle d'un logiciel de synthèse, c'est par contre le rôle d'un logiciel de synthèse de haut niveau dit «HLS» pour High Level Synthesis. Mais dans ce cas on prend carrément un programme en C, C++, Matlab, Python que le logiciel va tenter de convertir en une architecture logiciel+hardware.
J'ai plus qu'une balle