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
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:
Einige Diskussionen:
Async- und Sync-Reset
Letters On Sync vs. Async-Resets
Ich würde aus einigen Gründen (in keiner bestimmten Reihenfolge) ein asynchrones Zurücksetzen einem synchronen Zurücksetzen vorziehen:
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.
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 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).
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.
Superkatze
Oli Glaser
Superkatze
Superkatze
Oli Glaser
mixed_signal_old