Comment éviter les verrous pendant la synthèse


9

Je veux concevoir un bloc de logique combinatoire à l'aide de VHDL, mais parfois le résultat synthétisé contient un verrou involontaire.

Quelles directives de codage dois-je suivre pour éviter que le synthétiseur infère des verrous?

Exemple: dans un petit segment de code, dois-je utiliser des instructions if-else?


Si l'on peut obtenir ce que j'essaie de demander, veuillez m'en informer

Je ne savais pas trop ce que vous vouliez dire dans votre exemple. Veuillez vérifier que la reformulation correspond à votre intention initiale.
W5VO

@fatai, j'ai déjà commenté, il existe une méthode spécifique pour supprimer votre compte disponible sur meta.stackexchange.com. J'ai lié la dernière question sur laquelle j'ai été signalé. Les modérateurs sur place n'ont jamais ce pouvoir. Cela nécessite de contacter l'équipe de développement.
Kortuk

Réponses:


13

Pour éviter les verrous, vous devez vous assurer que toutes vos sorties sont affectées à toutes les branches possibles du code.

par exemple,

if a = '1' then
   b(0) <= '1';
else
   b(1 downto 0) <= "00";
end if;

générerait un verrou, car dans la première condition, la valeur de b (1) n'est pas spécifiée, donc le compilateur a décidé que vous vouliez conserver la valeur précédente de b (1). Une façon d'écrire ceci qui ne générerait pas de verrou est:

if a = '1' then
   b <= prev_b;
   b(0) <= '1';
else
   b(1 downto 0) <= "00";
end if;

...

if rising_edge (clk)
    prev_b <= b;
end if;

Ici, vous indiquez explicitement que b doit conserver son ancienne valeur, puis remplacer b (0) par la nouvelle valeur.

Une autre façon est de donner une valeur par défaut à ba, comme dans la réponse de @ TomiJ.

Si vous publiez le code sur lequel vous obtenez un verrou, nous pourrions vous aider à trouver la raison spécifique.


Je ne pense pas que votre approche de b <= bpermettra d'éviter un verrou, car il nécessite toujours de conserver l'état du signal.
Tomi Junnila

Vous pouvez avoir raison; Je suis trop habitué à la logique cadencée. Je vais éditer.
fbo

6

Si vous utilisez des processus pour la logique combinatoire (et je le déconseille pour cette raison), assurez-vous que chaque chemin à travers le processus affecte quelque chose à chaque signal que le processus conduit. Aucune des sorties ne peut dépendre de l'une des sorties de la "dernière fois" que le processus s'est exécuté.

Sinon, vous déduisez un verrou car la prochaine fois que le processus est planifié, il doit conserver la valeur du signal qui n'a pas obtenu de nouvelle valeur la dernière fois.

Je préfère garder la logique purement combinatoire en tant qu'affectations continues et utiliser des processus pour la logique cadencée, alors je n'ai pas de verrous.


5

Quatre règles pour éviter les verrous:

  • Ne lisez pas les signaux auxquels vous écrivez.
  • Avoir une liste de sensibilité correcte (tous les signaux que vous lisez doivent être dans la liste de sensibilité)
  • Assurez-vous que tous les signaux auxquels votre écriture est affectée dans chaque chemin. (par exemple: dans chaque branche d'une instruction if-else)
  • Pour les processus qui utilisent une variable, assurez-vous que chaque variable est initialisée à une valeur par défaut avant de la lire (dans une autre variable ou un autre signal).

De plus, si vous avez plusieurs processus combinatoires, assurez-vous de ne pas créer de boucle.

Plusieurs styles de codage peuvent vous aider à respecter ces règles, par exemple le style dans la réponse de @ TomiJ. Comme le souligne @Martin Thompson, il peut être préférable d'éviter la logique combinatoire tous ensemble. Mettez tout à la place dans un processus cadencé.


+1 Joli ensemble de règles. Seriez-vous d'accord pour dire que votre règle n ° 2 (sur la liste de sensibilité) est réellement importante pour garantir des résultats cohérents entre la synthèse et les simulations, mais ne fait pas vraiment de différence sur l'inférence des verrous?
Rick

@rick AFAIK, rien ne garantit ce que fera un outil de synthèse avec des listes de sensibilité incomplètes. La norme IEEE pour la synthèse VHDL (1076.6-1999) stipule que: "La liste de sensibilité de processus doit contenir tous les signaux lus dans l'énoncé de processus. Les processus avec des listes de sensibilité incomplètes ne sont pas pris en charge." Cela dit, je sais que certains outils de synthèse (peut - être tous?) Accepter des listes incomplètes de sensibilité, mais simplement ignorer la liste de sensibilité tous ensemble. Si vous comptiez sur ce comportement au lieu de la norme IEEE plus stricte, je suppose que votre déclaration serait correcte.
Philippe

Merci, cela sonne bien, cela rendrait mon modèle non conforme à cette norme. Cela a juste attiré ma curiosité parce que tous les outils de synthèse que j'ai vus jusqu'à présent ignorent la liste de sensibilité, mais j'ai entendu des rumeurs selon lesquelles certains pourraient inférer des verrous.
Rick

3

Comme cela a été souligné par @fbo et @Martin Thompson, vous devez vous assurer que chaque signal piloté par le processus se voit attribuer une valeur dans chaque branche du processus, et cette valeur ne doit pas dépendre de l'état précédent de l'une des sorties du processus.

La façon la plus simple de garantir cela est d'attribuer une valeur par défaut à chaque sortie au tout début du processus, par exemple (exemple de cooptation de fbo):

COMBO: process(a)
begin
    b <= (others => '0'); -- Assign default value to b
    if a = '1' then
        b(0) <= '1';
    else
        b(1 downto 0) <= "00";
    end if;
end process COMBO;

1
C'est une bonne méthode que j'utilise souvent. Parfois cependant, un avertissement de verrouillage peut vous indiquer que vous avez oublié d'affecter certains bits, alors que cette méthode peut rendre le bogue plus difficile à trouver. Par exemple, si vous attribuez séparément tous les bits d'un signal large et que vous les mal comptabilisez accidentellement.
fbo

2
Uniquement dans un processus combinatoire. Dans un processus cadencé, vous déduisez une bascule, qui peut être exactement ce que vous voulez.
Martin Thompson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.