Réinitialiser: synchrone vs asynchrone

15

Je travaille avec des fpgas depuis des années et j'ai toujours utilisé des réinitialisations synchrones pour toutes les parties (qui en ont besoin) de mes circuits. Il aide le circuit à être réinitialisé globalement à un cycle d'horloge donné.

Cependant, on m'a dit que dans les circuits ASIC, les gens ont tendance à utiliser la réinitialisation asynchrone partout. Je me demande pourquoi, et si c'est aussi le cas dans certains modèles fpga. J'aimerais entendre des opinions professionnelles.

Merci

fpga reset asic Aurelien Ribon
la source

Réponses:

11

Il semble y avoir beaucoup de vues sur celui-ci.
L'affirmation asynchrone, la désaffirmation synchrone serait une bonne pratique. Cela évite le problème de l'horloge ne fonctionnant pas (ou fonctionnant trop lentement pour capturer le signal de réinitialisation) lors d'une assertion synchrone, et d'une métastabilité possible lors d'une désaffirmation asynchrone.

Vous utiliseriez un synchroniseur de réinitialisation (deux FF) avec la sortie liée au reste des conceptions réinitialisées:

Réinitialiser

Quelques discussions:
Async et sync reset
Letters On Sync vs Async Resets

Oli Glaser
la source
Comment les exigences de temps de configuration / maintien entre la libération du signal de réinitialisation d'un verrou et son horloge se comparent-elles à celles de l'entrée de données? Je me sentirais plus à l'aise si les verrous du système voyaient la fin du signal de réinitialisation se produire sur le front d'horloge inactif. La libération d'une réinitialisation asynchrone sur un front d'horloge actif serait-elle garantie de ne pas affecter le cycle où elle se produit?
supercat
Non, la libération de la réinitialisation de manière asynchrone n'est pas garantie d'être propre en raison du temps de récupération de la réinitialisation nécessaire (comme la configuration / le maintien). C'est pourquoi vous devez libérer la réinitialisation de manière synchrone.
Oli Glaser
Ma question est de savoir si le fait de laisser un verrou1 libérer le signal de réinitialisation alimentant le verrou2 sur le même front d'horloge que celui utilisé par le verrou2 est complètement casher, c'est-à-dire si le temps de propagation minimum de l'horloge du verrou1 à sa sortie satisferait l'exigence de maintien pour l'entrée de réinitialisation du verrou2. BTW, que pensez-vous de ma réponse ci-dessus? Le circuit que vous avez dessiné offre peu d'immunité aux impulsions runt sur la ligne de réinitialisation, alors qu'une immunité presque totale devrait être possible.
supercat
Après un examen plus approfondi, on pourrait ajouter une protection contre les impulsions runt en ajoutant un troisième verrou et en faisant en sorte que son signal de réinitialisation asynchrone soit une version sans pépin du signal envoyé aux deux premiers, de sorte qu'un signal qui a perturbé de manière asynchrone le troisième verrou soit garanti pour réinitialiser proprement les deux premiers. Une impulsion runt sur l'entrée de réinitialisation pourrait provoquer une impulsion runt sur la ligne de réinitialisation principale de la puce, mais si une telle impulsion se produisait, elle serait suivie d'une impulsion de réinitialisation synchrone.
supercat
Désolé, je pense que je vois ce que vous voulez dire maintenant. Si vous entendez la sortie du deuxième verrou du synchroniseur vers la réinitialisation du système FF, je crois comprendre que le temps de récupération de réinitialisation est généralement inférieur au temps de configuration des données pour le même FF, donc ça devrait aller. Je suis d'accord sur les impulsions runt, il n'offre aucune immunité à ceux sans quelque chose comme vous suggérez d'être mis en œuvre.
Oli Glaser
7

Je préférerais une réinitialisation asynchrone à une réinitialisation synchrone pour plusieurs raisons (sans ordre particulier):

  • L'ajout d'un ensemble asynchrone ou d'une fonction de réinitialisation à une bascule entraînera probablement une conception plus petite en raison de l'intégration de la logique dans une seule cellule (par rapport à une bascule non réinitialisable avec une porte ET sur l'entrée)
  • Moins de portes entraîne un câblage / un lieu et un itinéraire moins encombrés
  • Il s'agit d'un processus plus simple / plus facile pour réinitialiser la puce (plus convivial pour l'utilisateur / test)
  • Rendre le chemin de réinitialisation asynchrone simplifie le partitionnement de l'analyse de synchronisation statique du signal de réinitialisation
  • Une réinitialisation synchrone ajouterait une logique supplémentaire au chemin critique du flux de données et rendrait plus difficile de répondre aux exigences de configuration et de maintien
  • Alors qu'un FPGA a une fonction logique arbitraire à 4-6 entrées sur l'entrée, vous "payez" pour chaque entrée dans une porte sur un ASIC (plus d'entrées = plus grande porte; fonctions complexes = plusieurs portes)

En fin de compte, je ne pense pas que ces problèmes soient des bouchons, mais ils contribueraient certainement à une forte préférence de réinitialisation asynchrone sur les ASIC.

W5VO
la source
2
Un danger avec l'utilisation de la réinitialisation asynchrone dans sa logique interne est qu'une impulsion runt sur l'entrée de réinitialisation peut causer des ravages de toutes sortes. Si l'on veut permettre à ses circuits d'être réinitialisés de manière asynchrone, on devrait concevoir les circuits d'entrée de manière à garantir que toute impulsion de réinitialisation suffisante pour éventuellement provoquer tout type de réinitialisation asynchrone pour atteindre les circuits internes sera également garantie de provoquer une réinitialisation synchrone doit se produire.
supercat
4

La réinitialisation asynchrone avec désaffirmation synchrone fonctionne très bien. Comme mentionné ci-dessus, les flops de réinitialisation asynchrone sont plus petits et ne nécessitent pas d'horloge active pour assurer la réinitialisation, vous pouvez donc forcer une pièce à se réinitialiser (généralement un état de faible puissance connu) avec juste de la puissance et une seule broche ou alimentation câblée lors de la réinitialisation.

Si vous voulez vraiment approfondir cela, vous pouvez lire les articles de Cumming à ce sujet, en particulier:

http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf

À votre santé.

mixed_signal_old
la source
Un problème que je pense que M. Cummings manque dans son article est que, bien que les détecteurs de pépins puissent supprimer ce qui serait autrement des impulsions runt, ils peuvent également transformer ce qui serait des impulsions de longueur légitime en impulsions runt. L'effet de ceci est qu'une impulsion qui est juste de la bonne longueur pourrait arbitrairement obstruer l'état du système sans provoquer une réinitialisation appropriée. Comme il est très difficile d'éviter la métastabilité dans tous les cas sans double synchronisation, je suggérerais d'avoir deux circuits de capture asynchrone, dont l'un a un critère de détection de
parasites
... organisez les choses de manière à ce qu'un petit problème puisse ou non provoquer une réinitialisation un ou deux cycles plus tard, mais une impulsion suffisamment longue provoquera une réinitialisation immédiate. De plus, bien que l'utilisation d'entrées de «réinitialisation asynchrone» sur des bascules puisse faciliter la synthèse dans certaines topologies, cela ne signifie pas qu'elles doivent être utilisées de manière asynchrone. Il peut être utile de synchroniser la plupart des signaux de réinitialisation internes avec l'horloge même lors de la commande d'entrées de «réinitialisation asynchrone» sur les verrous.
supercat
Cummings dit que les filtres anti-parasites "sont laids". Je n'en ai jamais vu dans les circuits intégrés sur lesquels j'ai travaillé. Nous avons tendance à utiliser les déclencheurs de Schmitt sur toutes les cellules du pavé d'entrée pour éviter ces problèmes, et les réinitialisations à la mise sous tension que j'utilise sont nettoyées de la même manière. Au fait, dans quels cas auriez-vous des impulsions courtes sur une ligne de réinitialisation? J'ai vu cela dans certains scénarios de test de numérisation, mais ils sont toujours de l'ordre de longues impulsions de cycle d'horloge et non utiles. Sur votre dernier commentaire, la désaffirmation de la réinitialisation doit être synchronisée avec l'horloge pour éviter les violations s / h lors de la réinitialisation et garantir que tous les flops quittent la réinitialisation sur le même front.
mixed_signal_old
Les filtres anti-parasites sont souvent utiles pour déterminer quels types d'entrées peuvent entraîner une métastabilité, mais ils n'éliminent pas les états métastables. Le but d'un filtre anti-parasites devrait être de garantir que tous les états métastables qui peuvent se produire se trouvent dans des situations "peu importantes". Parfois, il est nécessaire qu'un appareil soit capable de réinitialiser un autre appareil qui y est branché. À moins que le fil de réinitialisation ne soit synchronisé à deux reprises, il y aura un risque d'impulsions de runt à partir d'événements ESD à proximité et d'autres événements similaires.
supercat
En ce qui concerne le dernier point, je disais simplement que même un synthétise une conception sur du matériel qui fournit des entrées de réinitialisation asynchrone "gratuites" sur des bascules, cela ne signifie pas que l'on ne peut pas synchroniser complètement le signal avec l'horloge principale sur les deux. affirmation et libération. Les signaux orientés vers l'extérieur peuvent devoir réagir de manière asynchrone à une entrée de réinitialisation, mais cela ne signifie pas que l'on doit réinitialiser de manière asynchrone tous ses verrous. En effet, pour éviter des états incohérents, il peut être utile de faire en sorte que tous les verrous sauf deux dans la conception soient synchrones.
supercat
2

Une autre approche, qui semblerait encore plus sûre que l'approche 'async assert / sync release', serait d'avoir un détecteur de réinitialisation asynchrone (tout comme décrit ailleurs, avec 'assert' asynchrone et 'release' synchrone), mais avec la sortie de cette porte tout périphérique d'E / S orienté vers l'extérieur sans réinitialisation asynchrone quoi que ce soit (autre que le verrou dans le détecteur lui-même). Si l'on utilise deux détecteurs de réinitialisation asynchrones, un pour les lignes d'E / S et un pour alimenter le détecteur de réinitialisation synchrone, et si l'on conçoit celui pour les lignes d'E / S de manière à ce qu'il ne soit déclenché que par des impulsions de réinitialisation suffisamment solides pour être fiables déclencher le détecteur principal, on peut même éviter d'avoir des pépins de sorties dans les cas qui ne vont pas réinitialiser le CPU. Notez que si l'on fait cela, une impulsion de réinitialisation de longueur légitime réinitialisera les sorties de manière asynchrone,

Une autre chose à considérer est que les systèmes ont souvent des registres qui ne sont pas censés être affectés par une réinitialisation. Si une réinitialisation asynchrone pouvait frapper un circuit qui écrit dans ces registres, il serait possible qu'une impulsion de réinitialisation qui arrive au mauvais moment désobéisse à ces registres, même s'il s'agit d'une impulsion propre (non exécutée). Par exemple, si le code essaie d'écrire à l'adresse 1111 et qu'une réinitialisation asynchrone qui arrive juste avant qu'une impulsion d'horloge force l'un des verrous d'adresse à zéro juste au moment où l'impulsion d'horloge arrive, cela pourrait provoquer une écriture erronée à l'adresse 1110. Alors que on pourrait utiliser plusieurs lignes de réinitialisation internes avec des retards combinatoires pour garantir que les écritures de registre ont été désactivées avant que l'adresse ne soit encombrée, l'utilisation d'une logique de réinitialisation interne synchrone évite complètement le problème.

BTW, voici un circuit illustrant le concept. Près du coin inférieur gauche se trouvent deux entrées logiques pour la réinitialisation. L'un générera une impulsion de réinitialisation "propre", et l'autre générera une impulsion vraiment délicate. La LED jaune indique la réinitialisation du système principal; la LED cyan indique que les E / S sont activées. Une réinitialisation nette entraînera une "réinitialisation" immédiate des sorties; frapper une réinitialisation icky entraînera une réinitialisation retardée des sorties, ou les laissera inchangées (dans le simulateur, il n'y a aucun moyen de provoquer le cas `` ne les affectez pas '').

supercat
la source
Je pense que cela semble être une bonne idée. tant de nuances de gris avec des choses apparemment simples comme réinitialiser.
Oli Glaser
0

En tant qu'ingénieur expérimenté ( 3 ans avec la conception FPGA et les systèmes embarqués ), je vous dis que vous devez vérifier la fiche technique et le guide d'utilisation du FPGA. Ce n'est pas une réponse simple.

Vous devez faire de vos FIT de conception le type de FPGA que vous avez choisi. Certains FPGA ont des FlipFlops qui ont été conçus pour une réinitialisation Async, certains sont conçus pour une réinitialisation Sync.

Vous devez vérifier le guide de l'utilisateur FPGA pour savoir quel type de FlipFlops vous avez.

L'Implémenteur / Mappeur choisira des routes dédiées pour votre réinitialisation (le code peut s'exécuter à une fréquence plus élevée et prend moins d'espace ) si vous faites correspondre votre code avec le type de primitives FPGA.

Votre conception fonctionnera dans tous les cas , mais parfois l'implémentateur FPGA se mettra en quatre pour faire fonctionner votre logique ( ajoute plus de logique ), mais cela entraînera une fréquence maximale inférieure et / ou plus de ressources FPGA.

Exemple: testé avec le ZYNQ de Xilinx (le FPGA est conçu pour une réinitialisation synchronisée - voir le guide d'utilisation des primitives ). En changeant la réinitialisation de l'async à la synchronisation , la fréquence stable maximale est passée de 220 MHz à 258 MHz et j'ai donc dépassé ma marge de fréquence.

Je pourrais également ajouter que l'implémenteur ne sait pas ce qu'est une horloge et un signal de réinitialisation. Il attribue des broches de bascule aux signaux par ORDRE, pas par nom. Ainsi, dans certains FPGA, l'implémenteur choisit le premier signal après "process () begin" dans VHDL comme horloge, dans certains comme réinitialisation, selon le FPGA sur lequel l'implémentateur est défini.

Achex
la source
Je ne suis pas d'accord avec votre affirmation selon laquelle "l'implémentateur ne sait pas ce qu'est une horloge et un signal de réinitialisation". Les outils de synthèse déduisent quelle est l'horloge et qui est réinitialisée par la façon dont ils sont utilisés. Le signal d'horloge est utilisé avec une spécification de front, la réinitialisation ne l'est pas. De plus, n'importe quelle bascule peut être utilisée avec une spécification de réinitialisation synchrone et, comme vous l'avez observé, cela conduit souvent à des chemins critiques plus rapides.
Joe Hass