Pourquoi les verrous présumés sont-ils mauvais?

Mon compilateur se plaint des verrous inférés dans mes boucles combinatoires ( always @(*), dans Verilog). On m'a également dit que les verrous présumés devraient de préférence être évités.

Qu'est-ce qui ne va pas exactement avec les verrous déduits? Ils facilitent certainement l'écriture des boucles combinatoires.

Un «verrou» est différent d'un «bascule» en ce qu'un FF ne modifie sa sortie qu'en réponse à un front d'horloge. Un verrou peut changer sa sortie en réponse à autre chose qu'une horloge. Par exemple, un SR-Latch a un ensemble et une entrée de réinitialisation et si l'un ou l'autre est actif, la sortie peut changer. Là où un SR-FF ne répond qu'à un ensemble ou à une réinitialisation lorsqu'il y a aussi un front d'horloge.

Dans un FPGA, vous voulez que votre logique soit entièrement synchrone. Cela signifie que tous les éléments de stockage (comme les FF) sont tous synchronisés à partir d'une seule source d'horloge. Tout ce qui est asynchrone à cette horloge doit être traité très soigneusement sinon des erreurs de synchronisation se produiront.

Un verrou est essentiellement un élément de stockage asynchrone. Il n'a pas d'entrée d'horloge et ne peut donc être synchronisé avec aucune horloge. Je dois noter qu'il existe des FF avec réinitialisation asynchrone et entrées de réinitialisation, et celles-ci doivent être traitées avec le même soin que les verrous normaux.

Entrer dans tous les problèmes de synchronisation que les verrous peuvent causer est bien au-delà de ce qui peut être couvert ici, mais permettez-moi de vous donner un exemple:

Disons que vous avez un SR-Latch et que vous souhaitez qu'il soit défini chaque fois qu'un compteur 8 bits atteint une certaine valeur. Je ne suis pas sûr du code Verilog, mais en VHDL, le code est: set <= '1' when count = "11010010" else '0'; Ce signal défini va à l'entrée définie sur notre SR-Latch.

La logique qui en résulte est purement combinatoire; un mélange de portes et, ou de portes et d'onduleurs (ou LUT). Mais les chemins du signal à travers cette logique combinatoire ne sont pas toujours parfaits et le signal "set" pourrait avoir des défauts. Le chemin du signal à travers un groupe particulier de portes pourrait prendre plus de temps qu'un autre groupe, provoquant l'activation de la sortie définie pendant un bref instant avant que la sortie ne se stabilise.

Ce problème de sortie pourrait entraîner le réglage de notre SR-Latch, même s'il n'était pas censé le faire. Si nous passons d'un SR-Latch à un SR-FF, cadencé à la même horloge que le compteur, alors le SR-FF attendra un cycle d'horloge entier avant de changer d'état. En substance, il attendra que le signal défini se stabilise avant de le regarder.

Si les chemins à travers la logique combinatoire pour le signal défini sont simplement routés différemment (provoquant des retards différents), alors le comportement de pépin changera également. La logique peut fonctionner correctement, mais parce que vous avez modifié quelque chose de complètement indépendant, cette logique est acheminée différemment et le bug apparaît donc. La température et la tension changeront également la synchronisation du signal et peuvent donc changer le comportement de pépin.

Cette incertitude dans le timing est pourquoi vous devez éviter les verrous dans votre logique. Les FF sont beaucoup plus sûrs à utiliser. C'est pourquoi votre compilateur vous avertit des verrous, car il est facile de faire un verrou par erreur et vous ne le voulez probablement pas de toute façon.

Bien sûr, des verrous sont parfois nécessaires. Vous devez simplement les utiliser très rarement, uniquement lorsque cela est absolument nécessaire, puis vous devez concevoir la logique correctement afin qu'il n'y ait aucun problème possible.

Qu'est-ce qui fait un verrou inféré?
Pour la logique combinatoire, la sortie du circuit est fonction de l'entrée uniquement et ne doit contenir ni mémoire ni état interne (verrou).

En Verilog, une variable gardera sa valeur précédente si elle n'est pas attribué une valeur dans un toujours bloc. Un verrou doit être créé pour stocker cette valeur actuelle.

Une instruction if-else incomplète générera des verrous. Une instruction if-else est considérée comme "incomplète" si l'état de sortie n'est pas défini pour toutes les conditions d'entrée possibles. Il en va de même pour une déclaration de cas incomplète ou une déclaration de cas qui n'a pas de valeur par défaut: item.

Pourquoi les verrous présumés sont-ils mauvais?
Les verrous déduits peuvent servir de «signe d'avertissement» indiquant que la conception logique pourrait ne pas être implémentée comme prévu. Uneinstructioncruciale if-else ou case peut manquer dans la conception.

Les verrous peuvent entraîner des problèmes de chronométrage et des conditions de course. Ils peuvent conduire à une rétroaction combinatoire - routage de la sortie vers l'entrée - qui peut être imprévisible.

Pour éviter de créer des verrous déduits:

• Inclure toutes les branches d'une instruction if ou case
• Attribuez une valeur à chaque signal de sortie dans chaque branche
• Utilisez les affectations par défaut au début de la procédure pour que chaque signal soit attribué.

Quelques parties paraphrasées de "FPGA Prototyping by Verilog Examples" par P. Chu

Les verrous sont très difficiles à utiliser dans les FPGA ou les CPLD, donc beaucoup de gens les évitent complètement. L'une des raisons est que de nombreux FPGA n'ont pas de verrou intégré, ils sont donc fabriqués à partir de portes logiques - cela peut provoquer des problèmes de synchronisation désagréables.
De plus, vous n'avez aucun contrôle sur les retards de synchronisation et les conditions de course lors de l'utilisation d'un verrou (sauf s'il existe un élément natif)

Je déconseille d'utiliser des verrous à moins que vous ne puissiez absolument pas vous en passer (par exemple, emprunter du temps pour répondre à une fréquence d'horloge maximale nécessaire) et utiliser des techniques de codage pour rendre les verrous accidentels moins probables.

Les conceptions de logique séquentielle construites en utilisant la logique combinatoire et la rétroaction font généralement une hypothèse qui semblerait raisonnable lors de l'utilisation de portes physiques: que la sortie d'une porte ne changera pas en réponse à un changement d'entrée, jusqu'à ce que quelque temps après que l'entrée ait réellement changé. Il y a des cas où cette hypothèse peut ne pas tenir lors de l'utilisation de vraies portes (par exemple si une porte NOR rapide et un onduleur rapide sont tous deux entraînés par un signal qui monte lentement de VSS à VDD, et si l'onduleur commute à 1,2 volts tandis que le NOR la porte ne commute pas avant 1,7 volt, la porte NOR peut voir la sortie de l'onduleur descendre avant de voir que le signal qui monte lentement est devenu élevé) mais de tels problèmes peuvent généralement être résolus en ajoutant un tampon chaque fois qu'un changement lent le signal est acheminé vers plusieurs destinations. Malheureusement,

Le problème est que, sauf indication contraire explicite, un compilateur FPGA peut remplacer arbitrairement un circuit combinatoire par un circuit totalement différent qui a le même comportement en régime permanent, mais peut avoir une synchronisation entièrement différente. Par exemple, supposons qu'une fonction combinatoire complexe F prenne six entrées U à Z. F est directement envoyée au circuit P et (F NAND Z) est envoyée au circuit Q. Le compilateur peut se rendre compte que la valeur fournie à Q ne dépendra que de F lorsque Z est élevé, et peut calculer une fonction F 'qui est comme F sauf que Z est supposé élevé; Q peut alors être alimenté avec (F 'NAND Z) plutôt que (F NAND Z). Il serait tout à fait possible que la réalisation la plus efficace de P ait cinq retards de porte, mais la réalisation la plus efficace de Q n'en aurait que deux. Ainsi,

Si un circuit a une boucle de rétroaction combinatoire, un compilateur FPGA devra ajouter des nœuds de signal physiques qui, physiquement, auront un retard positif (une boucle de rétroaction à retard nul ne peut pas exister dans le monde réel), mais rien ne garantit que ces nœuds seraient ajoutés aux endroits nécessaires pour que le circuit se comporte comme souhaité. Il n'y a même pas de garantie qu'un léger changement dans la conception ne fera pas passer le compilateur d'un placement arbitraire qui fonctionne dans le monde réel à un placement arbitraire différent qui échoue.

Les détails sur la façon d'attraper un verrou dans la conception sont brièvement expliqués dans ce lien.

https://www.doulos.com/knowhow/fpga/latches/