2016-11-28 1 views
1

Pour résoudre la métastabilité causée par différents domaines d'horloge dans Verilog, une méthode à double registre est utilisée. Mais pour autant que je sache, la sortie finale de la métastabilité est indéterminée. La sortie est indépendante de l'entrée. Donc, ma question est de savoir comment garantir l'exactitude de la sortie en utilisant la méthode du double registre?Résolution de la métastabilité à l'aide d'une approche à double registre

Merci.

+1

Cette question pourrait être mieux adaptée à http://electronics.stackexchange.com/ –

+0

Ok, merci. Puis-je poster la question à nouveau? –

Répondre

1

Vous ne pouvez pas être complètement sûr que vous avez évité la métastabilité. Comme vous l'avez mentionné, la sortie d'une bascule métastable est imprévisible, donc vous pouvez potentiellement propager une mauvaise valeur quand vous avez de la métastabilité même avec l'approche 'two-register'. Cette méthode n'a toutefois jamais eu pour but de résoudre la métastabilité, mais tente de réduire la probabilité qu'une valeur métastable entre dans votre circuit. Ce qu'on appelle here MTBF (Mean Time Between Failure). Pour réduire le MTBF, vous pouvez même enchaîner plus de 2 registres.

Même si cela ne résout pas le unpredictive-ness d'une valeur, il est intéressant d'utiliser ces doubles registres parce que quand une valeur est métastable, il oscillera jusqu'à se stabiliser à 0 ou 1.

Cette oscillation fera tourner votre circuit et utilisera beaucoup d'énergie pour rien car chaque transition consomme de l'énergie. C'est pour cette raison qu'il est important d'utiliser des registres doubles pour le passage dans le domaine de l'horloge.

Pour vous assurer que vos données sont cependant valides, vous pouvez utiliser un mécanisme d'accusé de réception de demande entre les deux domaines d'horloge.

exemple rapide:

  1. Définir les données sur le bus (entrée d'un double registre)
  2. Wait 1 (ou plusieurs) cycle d'horloge pour être sûr que les données sont bien établi de l'autre côté
  3. Envoi d'un signal de demande (entrée d'un double registre)
  4. Dans le pire des cas: Le signal de requête est métastable et reste à 0 une fois stabilisé. Le cycle d'horloge suivant sera à 1 car il serait déjà réglé sur 1 pour au moins 1 cycle d'horloge. Meilleur cas: le cycle suivant la destination acceptera les données
  5. Les données sont stables, la demande est stable et à 1 -> les données peuvent être consommées. Envoyer un accusé de réception à la source.
  6. L'acquittement arrive (sur un double registre en cas de métastabilité). Si métastable il peut prendre un cycle d'horloge plus pour arriver.
  7. Demande de chutes.
  8. autre données peuvent être envoyées par l'intermédiaire du bus

Ce protocole est appelé protocole 4 phases. Vous pouvez trouver beaucoup de documentation à ce sujet sur le web car c'est un protocole classique pour les dessins asynchrones.

Il est assez simple à comprendre et à mettre en œuvre. Gardez à l'esprit cependant que cela va générer une surcharge dans la zone qui peut être très importante.

Espérons que ça aide.

+0

Merci Krouitch, mais j'ai encore une certaine confusion. Donc, après l'étape 4, ce que je peux seulement garantir, c'est que le signal de requête est stable et à 1, mais comment garantir la stabilité des données? Merci. –

+0

Si vous avez envoyé les données au moins un cycle d'horloge avant d'envoyer la demande, les données doivent être stables. Sinon, cela signifie que le chemin est trop long pour la période d'horloge que vous avez choisie. Voici un article qui illustre ce que je veux dire: http://www.eetimes.com/document.asp?doc_id=1276114 – Krouitch