Zurücksetzen: synchron vs. asynchron

Ich arbeite seit Jahren mit fpgas und habe immer synchrone Resets für alle Teile (die es brauchen) meiner Schaltungen verwendet. Es hilft der Schaltung, bei einem bestimmten Taktzyklus global zurückgesetzt zu werden.

Mir wurde jedoch gesagt, dass die Leute in ASIC-Schaltungen dazu neigen, überall asynchrones Zurücksetzen zu verwenden. Ich frage mich warum und ob es auch bei einigen FPGA-Designs der Fall ist. Ich würde gerne professionelle Meinungen hören.

Vielen Dank

Antworten (5)

Es scheint viele Meinungen zu diesem Thema zu geben.
Asynchrone Assertion, synchrone Deassertion sollen gute Praxis sein. Dies vermeidet das Problem, dass die Uhr bei synchroner Bestätigung nicht läuft (oder zu langsam läuft, um das Rücksetzsignal zu erfassen), und mögliche Metastabilität bei asynchroner Deaktivierung.

Sie würden einen Reset-Synchronisierer (zwei FFs) verwenden, dessen Ausgang mit den restlichen Design-Resets verbunden ist:

Zurücksetzen

Einige Diskussionen:
Async- und Sync-Reset
Letters On Sync vs. Async-Resets

Wie verhalten sich die Erfordernisse der Einrichtungs-/Haltezeit zwischen der Freigabe des Rücksetzsignals eines Latches und seiner Uhr im Vergleich zu denen für die Dateneingabe? Ich würde mich wohler fühlen, wenn die Latches im System das Ende des Rücksetzsignals an der inaktiven Taktflanke sehen würden. Würde die Freigabe eines asynchronen Resets an einer aktiven Taktflanke garantiert keinen Einfluss auf den Zyklus haben, in dem es auftritt?
Nein, die asynchrone Freigabe von Reset ist aufgrund der erforderlichen Wiederherstellungszeit für das Zurücksetzen (wie Setup/Halten) nicht garantiert sauber. Aus diesem Grund würden Sie das Zurücksetzen synchron freigeben.
Meine Frage ist, ob es vollständig koscher ist, wenn ein Latch1 das Reset-Signal freigibt, das Latch2 auf derselben Taktflanke wie Latch2 speist, das Latch2 verwenden würde, dh ob die minimale Laufzeit vom Takt von Latch1 zu seinem Ausgang die Halteanforderung für den Reset-Eingang von Latch2 erfüllen würde. BTW, was hältst du von meiner Antwort oben? Die von Ihnen gezeichnete Schaltung bietet wenig Immunität gegen Runt-Impulse auf der Reset-Leitung, wenn eine fast vollständige Immunität möglich sein sollte.
Bei weiterer Überlegung könnte man einen Schutz vor Runt-Impulsen hinzufügen, indem man einen dritten Latch hinzufügt und sein asynchrones Rücksetzsignal eine Glitch-unterdrückte Version des Signals ist, das den ersten beiden zugeführt wird, so dass ein Signal, das den dritten Latch asynchron stört, wäre Die ersten beiden werden garantiert sauber zurückgesetzt. Ein Runt-Impuls am Reset-Eingang könnte dazu führen, dass die Haupt-Reset-Leitung im Chip einen Runt-Impuls erhält, aber wenn ein solcher Impuls auftritt, würde ihm ein synchroner Reset-Impuls folgen.
Entschuldigung, ich glaube, ich verstehe jetzt, was du meinst. Wenn Sie die Ausgabe vom zweiten Latch im Synchronisierer zum Zurücksetzen des System-FF meinen, ist meines Wissens nach die Wiederherstellungszeit für das Zurücksetzen normalerweise kürzer als die Dateneinrichtungszeit für denselben FF, daher sollte es in Ordnung sein. Ich stimme den Runt-Impulsen zu, sie bieten denen keine Immunität, ohne dass so etwas wie Sie vorschlagen implementiert wird.
Der Reset-Eingang zu den Flops wird von den meisten statischen Timing-Tools berücksichtigt, sodass die synchrone Deassertion in der Synthese richtig getaktet und extrahierte statische Timing-Prüfungen platziert und weitergeleitet werden können.

Ich würde aus einigen Gründen (in keiner bestimmten Reihenfolge) ein asynchrones Zurücksetzen einem synchronen Zurücksetzen vorziehen:

  • Das Hinzufügen einer asynchronen Set- oder Reset-Funktion zu einem Flip-Flop führt wahrscheinlich zu einem kleineren Design aufgrund der Integration der Logik in eine einzelne Zelle (im Vergleich zu einem nicht rücksetzbaren Flip-Flop mit einem UND-Gatter am Eingang).
  • Weniger Tore führen zu weniger überlasteten Kabeln/Platz und Route
  • Es ist ein einfacherer/einfacherer Prozess, den Chip zurückzusetzen (benutzer-/testfreundlicher)
  • Den Reset-Pfad asynchron zu machen, vereinfacht die statische Zeitanalyse-Partitionierung des Reset-Signals
  • Ein synchrones Zurücksetzen würde dem kritischen Pfad des Datenflusses zusätzliche Logik hinzufügen und es schwieriger machen, die Setup-and-Hold-Anforderungen zu erfüllen
  • Während ein FPGA eine beliebige Logikfunktion mit 4-6 Eingängen am Eingang hat, "zahlt" man für jeden Eingang in ein Gatter auf einem ASIC (mehr Eingänge = größeres Gatter; komplexe Funktionen = mehrere Gatter).

Letztendlich denke ich nicht, dass eines dieser Probleme Show-Stopper ist, aber sie würden definitiv zu einer starken Präferenz für asynchrones Zurücksetzen auf ASICs beitragen.

Eine Gefahr bei der Verwendung von asynchronen Resets in der eigenen internen Logik besteht darin, dass ein Runt-Impuls am Reset-Eingang jede Art von Chaos anrichten kann. Wenn man zulässt, dass seine Schaltung asynchron zurückgesetzt wird, sollte man die Eingangsschaltung so konzipieren, dass sichergestellt ist, dass jeder Rücksetzimpuls, der ausreicht, um möglicherweise eine asynchrone Rücksetzung zu verursachen, die interne Schaltung garantiert auch verursacht ein synchroner Reset erfolgt.

Asynchrones Zurücksetzen mit synchroner Deassertion funktioniert sehr gut. Wie oben erwähnt, sind asynchrone Reset-Flops kleiner und erfordern keinen aktiven Takt, um das Zurücksetzen sicherzustellen, sodass Sie einen Teil in den Reset zwingen können (normalerweise ein bekannter Zustand mit geringem Stromverbrauch) mit nur Strom und einem einzelnen fest verdrahteten Stift oder Strom. beim Zurücksetzen.

Wenn Sie sich wirklich damit befassen möchten, können Sie Cummings Artikel dazu lesen, insbesondere:

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

Beifall.

Ein Problem, das Mr. Cummings meiner Meinung nach in seinem Artikel vermisst, ist, dass Glitch-Detektoren zwar unterdrücken können, was sonst Runt-Impulse wären, sie aber auch Impulse mit legitimer Länge in Runt-Impulse umwandeln können. Der Effekt davon ist, dass ein Impuls, der genau die richtige Länge hat, den Systemzustand willkürlich beeinträchtigen könnte, ohne ein ordnungsgemäßes Zurücksetzen zu bewirken. Da es ohne Doppelsynchronisierung sehr schwierig ist, Metastabilität in allen Fällen zu vermeiden, würde ich vorschlagen, zwei asynchrone Erfassungsschaltungen zu haben, von denen eine ein "strengeres" Glitch-Erkennungskriterium hat, und dann ...
... arrangieren Sie die Dinge so, dass ein kurzer Fehler ein oder zwei Zyklen später zu einem Reset führen kann oder nicht, aber ein ausreichend langer Impuls führt zu einem sofortigen Reset. Auch wenn die Verwendung von "asynchronen Reset"-Eingängen an Flip-Flops die Synthese in einigen Topologien unterstützen kann, bedeutet dies nicht, dass sie asynchron verwendet werden müssen. Es kann hilfreich sein, die meisten internen Reset-Signale mit dem Takt zu synchronisieren, selbst wenn "asynchrone Reset"-Eingänge auf Latches getrieben werden.
Cummings sagt, Glitch-Filter seien „hässlich“. Ich habe noch nie einen in den ICs gesehen, an denen ich gearbeitet habe. Wir neigen dazu, Schmitt-Trigger an allen Eingangs-Pad-Zellen zu verwenden, um diese Probleme zu vermeiden, und die von mir verwendeten Einschalt-Resets werden ähnlich bereinigt. Übrigens, in welchen Fällen würden Sie kurze Impulse auf einer Reset-Leitung haben? Ich habe dies in einigen Scan-Testszenarien gesehen, aber sie sind immer noch in der Größenordnung von langen Taktzyklen und nicht von absichtlich kurzen Impulsen. Bei Ihrem letzten Kommentar muss die Deassertion von Reset mit der Uhr synchronisiert werden, um s / h-Verletzungen beim Reset zu vermeiden und sicherzustellen, dass alle Flops Reset auf derselben Flanke verlassen.
Glitch-Filter sind oft nützlich, um zu bestimmen, welche Arten von Eingaben Metastabilität verursachen können, aber sie beseitigen keine metastabilen Zustände. Das Ziel bei einem Glitch-Filter sollte es sein, sicherzustellen, dass irgendwelche metastabilen Zustände, die auftreten können, sich in "Nicht-Pflege"-Situationen befinden. Manchmal ist es notwendig, dass ein Gerät ein anderes angeschlossenes Gerät zurücksetzen kann. Wenn der Reset-Draht nicht doppelt synchronisiert ist, besteht die Gefahr von Runt-Impulsen von ESD-Ereignissen in der Nähe und anderen ähnlichen Problemen.
Zum letzten Punkt habe ich lediglich gesagt, dass sogar einer ein Design auf Hardware synthetisiert, das "freie" asynchrone Reset-Eingänge für Flip-Flops bereitstellt. Das bedeutet nicht, dass man das Signal nicht vollständig mit der Hauptuhr auf beiden synchronisieren kann Behauptung und Freigabe. Nach außen gerichtete Signale müssen möglicherweise asynchron auf einen Reset-Eingang reagieren, aber das bedeutet nicht, dass man alle Latches asynchron zurücksetzen muss. Um inkonsistente Zustände zu vermeiden, kann es in der Tat nützlich sein, nur alle bis auf zwei der Latches in dem eigenen Design synchron zu haben.
Ein asynchrones Latch zeigt an, dass es seit dem letzten "bestätigten" Zurücksetzen möglicherweise einen Rücksetzimpuls gegeben hat; der andere weist darauf hin, dass es sicherlich einen gab. Alle Ausgänge sind eine kombinatorische Funktion des zweiten asynchronen Zwischenspeichers und der synchronen Logik.

Ein anderer Ansatz, der noch sicherer erscheint als der Ansatz „Async Assert/Sync Release“, wäre ein asynchroner Reset-Detektor (ähnlich wie an anderer Stelle beschrieben, mit asynchronem „Assert“ und synchronem „Release“), aber die Ausgabe von die alle nach außen gerichteten I/O-Geräte ausschalten, ohne irgendetwas asynchron zurückzusetzen (außer dem Latch im Detektor selbst). Verwendet man zwei asynchrone Reset-Detektoren, einen für I/O-Leitungen und einen zur Speisung des Synchron-Reset-Detektors, und konstruiert man den einen für I/O-Leitungen so, dass er nur durch Reset-Impulse ausgelöst wird, die zuverlässig genug sind Auslösen des Hauptdetektors, kann man in Fällen, in denen die CPU nicht zurückgesetzt wird, sogar vermeiden, dass die Ausgänge Glitch haben. Beachten Sie, dass in diesem Fall ein Reset-Impuls mit legitimer Länge die Ausgänge asynchron zurücksetzt.

Eine andere zu berücksichtigende Sache ist, dass Systeme oft einige Register haben, die von einem Reset nicht betroffen sein sollen. Wenn ein asynchroner Reset eine Schaltung treffen könnte, die in diese Register schreibt, wäre es möglich, dass ein Reset-Impuls, der zur falschen Zeit ankommt, diese Register überfällt, selbst wenn es sich um einen sauberen (Nicht-Runt-) Impuls handelt. Wenn beispielsweise der Code versucht, an die Adresse 1111 zu schreiben, und ein asynchroner Reset, der unmittelbar vor einem Taktimpuls ankommt, einen der Adress-Latches auf Null zwingt, gerade als der Taktimpuls ankommt, könnte dies zu einem fehlerhaften Schreiben an die Adresse 1110 führen. Während Man könnte mehrere interne Reset-Leitungen mit kombinatorischen Verzögerungen verwenden, um sicherzustellen, dass Registerschreibvorgänge deaktiviert wurden, bevor die Adresse geschlagen wurde, wobei die Verwendung einer synchronen internen Reset-Logik das Problem vollständig vermeidet.

Übrigens, hier ist eine Schaltung, die das Konzept veranschaulicht. In der Nähe der unteren linken Ecke befinden sich zwei Logikeingänge zum Zurücksetzen. Einer erzeugt einen "sauberen" Reset-Impuls, der andere einen wirklich ekligen. Die gelbe LED zeigt das Zurücksetzen des Hauptsystems an; die cyanfarbene LED zeigt die E/A-Aktivierung an. Ein sauberer Reset bewirkt ein sofortiges "Reset" der Ausgänge; Das Drücken eines ekligen Resets führt entweder zu einem verzögerten Reset der Ausgänge oder lässt sie unbeeinflusst (im Simulator gibt es keine Möglichkeit, den Fall „Belassen Sie sie unbeeinflusst“ zu verursachen).

Ich denke, das klingt nach einer guten Idee. so viele Grauschattierungen mit scheinbar einfachen Dingen wie Reset.

Als erfahrener Ingenieur ( 3 Jahre mit FPGA-Design und eingebetteten Systemen ) sage ich Ihnen, dass Sie das Datenblatt und das Benutzerhandbuch des FPGA überprüfen müssen. Es ist keine einfache Antwort.

Sie müssen Ihr Design passend zu dem von Ihnen gewählten FPGA-Typ machen . Einige FPGAs haben FlipFlops , die für Async-Reset entwickelt wurden, andere sind für Sync-Reset konzipiert.

Sie müssen im FPGA-Benutzerhandbuch nachsehen, welche Art von FlipFlops Sie haben.

Der Implementor/Mapper wählt dedizierte Routen für Ihren Reset ( Code kann mit höherer Frequenz ausgeführt werden und nimmt weniger Platz ein ), wenn Sie Ihren Code mit dem FPGA-Primitiven-Typ abgleichen.

Ihr Design wird in JEDEM Fall funktionieren , aber manchmal wird der FPGA-Implementierer alles daran setzen, dass Ihre Logik funktioniert ( fügt mehr Logik hinzu ), aber das führt zu einer niedrigeren maximalen Frequenz und/oder mehr FPGA-Ressourcen.

Beispiel: Getestet mit ZYNQ von Xilinx ( FPGA ist für synchronisiertes Zurücksetzen ausgelegt – siehe Benutzerhandbuch für Grundelemente ). Durch das Ändern des Resets von async auf sync ging die maximale stabile Frequenz von 220 MHz auf 258 MHz, und so habe ich meinen Frequenzspielraum überschritten.

Ich könnte auch hinzufügen, dass der Implementierer nicht weiß, was ein Takt- und Rücksetzsignal ist. Es weist Signalen Flipflop-Pins nach ORDER zu, nicht nach Namen. In einigen FPGAs wählt der Implementierer das erste Signal nach „process() begin“ in VHDL als Takt, in einigen als Reset, je nachdem, auf welches FPGA der Implementierer eingestellt ist.

Ich stimme Ihrer Aussage nicht zu, dass "der Implementor nicht weiß, was ein Takt- und Rücksetzsignal ist". Die Synthese-Tools leiten daraus ab, welche die Uhr ist und welche zurückgesetzt wird, je nachdem, wie sie verwendet werden. Das Taktsignal wird mit Flankenvorgabe verwendet, der Reset nicht. Darüber hinaus kann jedes Flip-Flop mit einer synchronen Reset-Spezifikation verwendet werden, und wie Sie beobachtet haben, führt dies häufig zu schnelleren kritischen Pfaden.