|
|
Forum: FPGA, VHDL & Co. Theoriefrage asynchroner ResetAngenommen ich synchronisiere einen Reset der von außen kommt (Knopf z.b.) über 2 Flipflops ins FPGA ein. Diesen Reset verwende ich dann im restlichen Design asynchron zum Takt also
Spricht man dann noch von einem asynchronen Reset und sollte das dann einwandfrei funktionieren? soweit ich weiß, bügelt der Reset alles nieder - sollte also auf jeden Fall funktionieren. Armin schrieb: > soweit ich weiß, bügelt der Reset alles nieder - sollte also auf jeden > Fall funktionieren. Was ich genau meinte: Treten da auch noch Glitches auf so dass ein Teil der Schaltung noch im Resetzustand ist und der andere schon anläuft? D. I. schrieb: > Was ich genau meinte: Treten da auch noch Glitches auf so dass ein Teil > der Schaltung noch im Resetzustand ist und der andere schon anläuft? Nein, du hast ja geschrieben dass du den externen Reset einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben. Hiermit: D. I. schrieb: > if (rst ...) elsif (clock ...) end if; baust du Reset-Kombinatorik auf, welche sich u.U. kontraproduktiv auf die maximale Frequenz des Designs auswirkt. Nachtrag: ich gehe davon aus dass in deinem Design "hoffentlich" nur ein Takt verwendet wird. ja nur ein takt natürlich. Spricht man dann in dem Fall noch von einem asynchronen Reset oder von einem synchronen Reset? Ah ok. Die Frage ist natürlich berechtigt und da fehlt mir die praktische Erfahrung, um das zu beantworten. Aber Gegenfrage: was passiert, wenn du deinen RST nicht einsynchronisierst und trotzdem zufällig eine Flanke triffst beim Auslösen? Sollten die Teile nicht so designt sein, dass RST und CLK einen ähnlich langen Weg zu den Registern haben? Vielleicht kann man so etwas ja auch simulieren? Warten wir mal ein bisschen - das hat bestimmt schon mal ein Praktiker getestet ^^ Man kann sich natürlich auch fragen, warum es notwendig ist, einen asyncRESET-Eingang zu verwenden, wenn man ohnehin weiß, dass das Signal synchron ist. oh es gibt schon Antworten: spartanne schrieb: > Nein, du hast ja geschrieben dass du den externen Reset > einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben. Die Gefahr wird wohl eher sein, dass einige Register mit einer vorbeikommenden CLK-Flanke schon anlaufen, während andere noch im RST sind. Darauf hat sich mein Beitrag bezogen. Armin schrieb: > > Aber Gegenfrage: was passiert, wenn du deinen RST nicht > einsynchronisierst und trotzdem zufällig eine Flanke triffst beim > Auslösen? Der Fall ist mir schon bewusst, da kann Gott und die Welt passieren. Armin schrieb: > oh es gibt schon Antworten: > > spartanne schrieb: >> Nein, du hast ja geschrieben dass du den externen Reset >> einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben. > > Die Gefahr wird wohl eher sein, dass einige Register mit einer > vorbeikommenden CLK-Flanke schon anlaufen, während andere noch im RST > sind. Darauf hat sich mein Beitrag bezogen. Nochmal: wenn du ein externes Signal mit dem Takt einsynchronisierst und dieses synchronisierte Signal verwendest wirst du nie Probleme haben solange zu fmax nicht verletzt. Ein FPGA ist so konstruiert, dass das Clock-Signal quasi zeitgleich an allen Registern anliegt. Dafür hat Xilinx, Altera, Lattice und Co. zu sorgen und der Anwender kann sich darauf verlassen. D. I. schrieb: >> Aber Gegenfrage: was passiert, wenn du deinen RST nicht >> einsynchronisierst und trotzdem zufällig eine Flanke triffst beim >> Auslösen? > > Der Fall ist mir schon bewusst, da kann Gott und die Welt passieren. Da wird GARANTIERT etwas schiefgehen! Es gilt für alle externe Signale: einsynchronisieren, egal ob Reset oder sonstwas. Wer sich daran nicht hält ist selbst Schuld an der langwierigen Fehlersuche. Armin schrieb: > Man kann sich natürlich auch fragen, warum es notwendig ist, einen > asyncRESET-Eingang zu verwenden, wenn man ohnehin weiß, dass das Signal > synchron ist. Ein asynchrones Rest zu beschreiben macht schon Sinn, denn es benötigt weniger Resourcen als ein synchrones Reset und man erreicht damit oft auch höhere Taktraten. Das kann man auch schön sehen, wenn man sich so einen typische CLB näher betrachtet: Der besteht sehr vereinfacht aus einer LUT mit einem anschließendem FF. Der Ausgang der LUT geht an den D-Eingang des FF, aber dieses besitzt neben dem D-Eingang noch ein Enable und ein Reset (Clock natürlich auch). Wenn man z.B. ein LUT4 hat und das D-Signal aus 4 Signalen kombinatorisch gebildet wird, dann reicht ein LUT4 dafür aus. Wenn man dann aber noch das Reset synchron verwendet werden aus den 4 Singalen derer 5. Die Folge ist, dass dafür zwei LUT4 benötigt werden. => Mehr Resourcen und lägere Laufzeiten. Dafür bleibt aber der Reset-Eingang des FF frei ;-) Natürlich muss das Reset aber zuvor einsynchronisiert sein. Es ist und bleibt ein asynchroner Reset. Was soll das werden? Ich würde es gerne wissen damit ich es nicht aus versehen kaufe. > Spricht man dann in dem Fall noch von einem asynchronen Reset oder von > einem synchronen Reset? Es bleibt wie schon gesagt ein asynchroner Reset. Wenn das systemweit gemacht wird, dann wären die Whitepaper WP272 und WP275 von Xilinx mal einen Blick wert. Denn durch den asynchronen Reset werden z.B. bei Xilinx-FPGAs die FFs im FPGA in den asynchronen Modus geschaltet, der insbesondere die Setz-und Rücksetzeingänge beeinflusst. Das kann als zusätzlicher Aufwand und schlechteren Laufzeiten bemerkbar machen: http://www.lothar-miller.de/s9y/archives/70-Asynchroner-Reset.html Und etliche Möglichkeiten (wie z.B. Schieberegister in den LUTs) werden durch einen Reset (synchron oder asynchron) generell verhindert. > Ein asynchrones Rest zu beschreiben macht schon Sinn, denn es benötigt > weniger Resourcen als ein synchrones Reset und man erreicht damit oft > auch höhere Taktraten. Ich hatte mal ein Design bei Lattice MachXO-Bauteinen, da brachte ein lokaler asynchroner Reset an handverlesenen FFs tatsächlich eine Verbesserung... :-o Fazit: Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design herauskommen soll. >Fazit: >Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware >niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design >herauskommen soll. Da hat sich jemand besonnen ;O) VG, SuperWilly > Da hat sich jemand besonnen ;O)
Und das trotz geschlossener Wolkendecke ;-)
Und um nochmals fachliches Futter einzuwerfen, die Paper zu Reset von Cliff Cummings: http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_Resets.pdf http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf
Angehängte Dateien:
Diese Aussage auf Seite 2 in CummingsSNUG2002SJ_Resets stimmt so unbesehen allerdings nicht:
Es wird hier keinerlei zusätzliche Logik erzeugt (Bild_1)! Es wird lediglich (wie ja auch im Code beschrieben) das Reset-Signal unnötigerweise auf den Clock-Enable-Eingang des 2. FFs aufgeschaltet.
Es ist auch keineswegs (wie in dem PDF vorgeschlagen) nötig, 2 Prozesse zu verwenden. Es muß nur die Zuweisung an q2 ausserhalb des Reset-Zweigs passieren. Letztendlich ist der Satz, den Lothar geschrieben hat die ganze Wahrheit: > Fazit: > Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware > niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design > herauskommen soll. Xilinx empfiehlt explizit synchrone Resets, siehe auch Whitepaper WP231. Das widerspricht zum Teil dem, was Cliff Cummings in seinen Papers schreibt. Bei einem neuen Design habe ich kürzlich aus Neugierde ausprobiert, wie gross der Unterschied im Bezug auf Altera FPGAs ist, da es ein solch schönes Whitepaper bei Altera schlicht nicht zu geben scheint. Die Ergebnisse sind eigentlich recht eindeutig (Zumindest für mein recht kleines Submodul): CycloneII-C6: sync reset: 224 LUT, fmax 64,3MHz; asnyc reset: 187LUT, 69,5MHz (Vergleichbare Ergebnisse für CycloneIII-C7) Dem StratixIII wiederum ist es ziemlich Wurst, da ändern sich (mit dem selben Design) die Syntheseergebnisse marginal. Der Unterschied ist nur der Reset für insgesamt 73FFs. Weiter sagt z.B. der Altera DRC zu einem asynchronen Reset folgendes: Warning: (Medium) Rule R102: External reset signals should be synchronized using two cascaded registers. Found 1 node(s) related to this rule. Quartus möchte also wohl einen synchronisierten Reset, der allerdings auf die async_reset Pins der FFs geführt wird. Fazit: Literaturstudium (für die Zielplattform!) und ggf. eigene Tests sind bei solchen Streitfragen äusserst wichtig. Das "richtig" für alle Plattformen gibt es nicht. p.s. Übrigens gilt das gleiche auch für Verilog :-) Dann benutze mal ein Wörterbuch! "extraneous" bedeutet nicht zusätzlich, sondern belanglos... > This coding style will generate extraneous logic as shown in Figure 1.
extraneous:
fremd
irrelevant
unerheblich
unwesentlich
fremdländisch
nicht relevant
nicht zur Sache gehörig
In der Sache bleibt es gleich: es wird keine unwesentliche oder
belanglose (oder was auch immer) Logik generiert, weil eben überhaupt
keine Logik erzeugt wird.
Lothar Miller schrieb: > In der Sache bleibt es gleich: es wird keine unwesentliche oder > belanglose (oder was auch immer) Logik generiert, weil eben überhaupt > keine Logik erzeugt wird. Doch, es wird unnötige Hardware generiert: Ein ladbares Flipflop! In einem FPGA ist das egal. Dort hat man multifunktionale FFs. Aber in einem ASIC wird nun eine andere Zelle, nämlich eine mit lade Eingang, verwendet. Und ein solches ist nicht unerheblich größer. Sorry für den Doppelpost. Wie Du schon selber geschrieben hast, es kommt auf die darunter liegende Technologie an ;) > Aber in einem ASIC wird nun eine andere Zelle, > nämlich eine mit lade Eingang, verwendet. Richtig, ich hatte überlesen, dass in den PDFs eigentlich nur von ASICs geschrieben wird :-/ >Nochmal: wenn du ein externes Signal mit dem Takt einsynchronisierst und >dieses synchronisierte Signal verwendest wirst du nie Probleme haben >solange zu fmax nicht verletzt. Genau deshalb kannst du ein Problem haben! Das Einsynchronisieren nutzt dir bei der Verwendung als asynchroner Reset wenig, da die statische Timinganalyse beim Place and route Pfade die an asynchronen Eingängen enden nicht erfasst. Es kann dir sehr wohl passieren, das ein Teil der Schaltung aus dem reset fällt, während der andere Teil sich noch im selben befindet. Auch bei der Verwendung des dedizierten Reset Netzwerkes (Xilinx:StartUp-Komponente). Deshlab rät ja Xilinx seit VirtexII vom asnychronen Reset insbesonders bei großen FPGA's ab. Ein PERIOD constraint erfasst eben nicht die Pfade vom Ausgang der Synchronisierstufe bis zum nächsten Eingang. Das kann daher schon mal länger als eine Periode (oder eine halbe bei DDR -Output-FF) dauern. Bei Xilinx muss du dann schon ein FROM TO constraint setzen um ein asynchrones Erwachen zu verhindern, aber dann kannst du auch gleich einen synchronen Reset nutzen. Die FF bei Altera haben beide Eingänge - asynchron und synchron - deshalb ist bei diesen kein Vorteil bei der Resourcenausnutzung für synchron feststellbar. Falls die Implementierung mit synchr. Reset langsamer ausfällt, hilft es das letzte Synchronisier-FF zu vervielfachen, also den "vorsynchronisierten" Reset sternförmig zu verteilen und so mehrere lokale synchrone Resetquellen zu erzeugen. MfG, > Die FF bei Altera haben beide Eingänge - asynchron und synchron - > deshalb ist bei diesen kein Vorteil bei der Resourcenausnutzung für > synchron feststellbar. Sie haben laut Handbuch eine dedizierte synchrone Load and Clear Logik. Den zweiten Satz kann ich jedoch nicht unterschreiben, ein praktischer Versuch zeigt mir jedenfalls deutliche Unterschiede zwischen asynchron:
und synchron:
Die Werte hab ich weiter oben ja schon geschrieben. Aber hier gehts ja um die Theorie, also bin ich mit meiner Praxis jetzt mal ruhig. ******************************* Keine Asynchronen Resets bauen! ******************************* Ist bei FPGAs kontraproduktiv! Meistens braucht man nicht einmal einen globalen Reset, weil die Bausteine in definierte Startzustände gebracht werden können. Das einzige, was es braucht ist ist Möglichkeit, ALLE state machines wieder in einen Startzustand zu bringen. Das geht am besten voll synchron mit ihrem jeweiligen Takt. > Meistens braucht man nicht einmal einen globalen Reset Meistens gibt es nicht mal einen globalen Reset, denn aktuelle FPGAs haben kein dediziertes globales Reset-Netzwerk mehr... Fazit: Jeder Reset muß aufwändig quer durchs ganze FPGA geroutet werden. Jeder sollte sich die Frage stellen: Wofür brauche ich an dieser Stelle einen Reset? Und wenn die Antwort lautet: Nur für den Power-Up und den Reset-Taster. Dann hilft keine Ausrede mehr, denn: Power-Up-Zustände für Register können als Defaultwerte angegeben werden. Den Reset-Taster drückt ausser dem Entwickler niemals irgendjemand. (Und falls doch, dann ist das Design noch nicht fertig.) Hallo, also ich bevorzuge die Reseteinsynchronisierung in folgender Art. Reset wird asynchron ausgelöst und mit der fallenden Clockflanke losgelassen. Hier mal ein einfaches Beispiel: signal schieberegister : std_logic_vector(1 downto 0); ... process (ext_resetsignal, clock) begin if ext_resetsignal = '1' then schieberegister <= "00"; elsif falling_edge(clock) then schieberegister <= schieberegister(0) & '1'; end if; end process; reset <= schieberegister(1); Ansonsten (zur eigentlichen Frage): wenn der Reset mit 2 Flipflops einsynchronisiert wurde ist das kein asynchroner Reset mehr, da er die Clock benötigt um eine Auswirkung zu haben. Das ist bei der Schaltung hier nicht der Fall. Zu beachten ist, dass sich die meisten hier im Forum mit FPGAs beschäftigen. Die Vorschläge sind manchmal recht ungeeignet für ein ASIC. Und gerade beim Reset scheint das ganz besonders der Fall zu sein. Der Besucher > Reset wird ... mit der fallenden Clockflanke losgelassen. Verwendest du auch im restlichen Design den fallenden Takt? Falls nein, dann hast du ja nur die halbe Zeit für das Routing dieses Reset-Signals zur Verfügung, um die Setupzeit tsu der angeschlossenen FFs nicht zu verletzen... Denn wie gesagt: im FPGA gibt es kein Reset-Netz. Das wird alles handverdrahtet. > Zu beachten ist, dass sich die meisten hier im Forum mit FPGAs be- > schäftigen. Die Vorschläge sind manchmal recht ungeeignet für ein ASIC. Ja, gut, das Forum heißt ja auch FPGA, VHDL & Co ;-) Und auch die Frage ganz zu Beginn des Freds bezog sich ziemlich definitiv auf ein FPGA: >>>> synchronisiere einen Reset ... über 2 Flipflops ins FPGA ein. Im Zweifel hätte ich auch den Reset auf der entgegengesetzten Taktflanke losgelassen. Wenn ich ihn mit der gleichen Taktflanke loslasse mit der auch die Register arbeiten habe ich ja viel eher ein race zwischen dem gerade losgelassenen Reset und dem Taktnetzwerk. @Fpga Kuechle: Es gibt ja zb Reset Removal bei der Timing-Analyse, wird sowas dabei nicht berücksichtigt? Ich glaube an dieser Stelle muss erst noch mal geklärt werden, was genau ein asynchrones Reset ist! Asynchron bedeutet, dass ein Register (FF) unabhängig von seinem Clock in einen bestimmten Zustand wechselt. Dabei ist es völlig unabhängig ob das Reset zuvor einsynchronisiert wurde oder nicht. Ganz gefährlich wird es wenn man dieses asynchrone Signal nicht in Bezug zu dem verwendeten Takt des Registers bringt. Stichwörter: Metastabilität, undefinierte Zustände, etc. Damit es mit dem asynchronen Reset zu keinen Schwierigkeiten kommt, muss das Reset-Signal mit dem zugehörigen Takt in Verbindung gebracht werden. Sprich: einsynchronisiert. Es gibt aber einige weitere wichtige Kriterien, die für die Verwendung eines asynchronen Resets wichtig sind: - Es muss glitchfrei sein. Daher keine Kombinatorik sondern immer ein Ausgang eines Registers! - Es muss das Timing des Resetpfades sichergestellt sein. Constraining! - Es muss eine Mindestlänge haben. Sonst kann es zu Metastabilität führen. Vor allem letzter Punkt wird oft nicht beachtet. Es schwirren dazu viele Codefragmente die genau diesen Punkt unberücksichtigt lassen. Folgender geposteter Code steht für ein solches fehlerhaftes Beispiel:
Problematisch ist daran, dass wenn das eingehende ext_resetsignal nur ein sehr kurzer spike (oder eine Störung) ist. Da kann es im schieberegister(1) am Ausgang zu einem metastabilen Zustand kommen. Funktionieren würde das ganze wenn das Bit schieberegister(1) nicht im asynchronen Resetpfad durch ext_resetsignal bedient. Dieses Design funktioniert nur Sicher wenn das ext_resetsignal eine mindestlänge garantiert. Sollte aber eine Mindestlänge garantiert sein, dann reicht es meist auch aus das externe Reset einfach über zwei Register einzusynchronisieren. Nun nochmal zur Theorie: Macht es Sinn ein Reset asynchron zu verwenden? Da lautet die Antwort ganz klar Ja!. Die Register bieten nun mal die Resourcen an, wärend man bei einer synchronen Verwendung weitere Resourcen verschwendet. Aber man muss da genau wissen was man tut, dass es zu keinen Problemen kommt. Vor allem aber stellt sich an erster Stelle die Frage ob ein Reset überhaupt notwendig ist. Da hat Lothar völlig recht. Matthias schrieb: > Im Zweifel hätte ich auch den Reset auf der entgegengesetzten Taktflanke > losgelassen. Wenn ich ihn mit der gleichen Taktflanke loslasse mit der > auch die Register arbeiten habe ich ja viel eher ein race zwischen dem > gerade losgelassenen Reset und dem Taktnetzwerk. > > @Fpga Kuechle: Es gibt ja zb Reset Removal bei der Timing-Analyse, wird > sowas dabei nicht berücksichtigt? Was meinst du mit reset removal? Allgemein zur Timing analyse, prinzipiell kann jeder Pfad bei der Timing Analyse und damit beim Place und Route berücksichtigt werden. Und jeder Pfad kann auch ignoriert werden. In meinem Beitrag habe ich herausgehoben, das beim üblichen Vorgehen (PERIOD constraint setzen, I-O Pfade constrainen, sonst nix), die Pfade die an den asynchronen Eingängen enden NICHT analysiert werden. Das bedeutet sehr unterschiedliche und unter Umständen sehr lange Laufzeiten. Um eine maximale Laufzeit in dem Netzwerk zu garantieren, muß ein anderes constraint gesetzt werden. (die constraint PERIOD und FROM To beziehen sich hier auf die Xilinx-Tools). MfG, Matthias G. schrieb: > Nun nochmal zur Theorie: Macht es Sinn ein Reset asynchron zu verwenden? > Da lautet die Antwort ganz klar Ja!. Die Register bieten nun mal die > Resourcen an, wärend man bei einer synchronen Verwendung weitere > Resourcen verschwendet. Sorry, das stimmt so allgemein gesprochen nicht. Bei Xilinx kann man die FF entweder mit synchronen (SET/RESET) oder asynchronen (PRESET/CLEAR) Eingängen konfigurieren. (asynchron SET/RESET ist hier keine zusätzliche Resource sondern ein entweder .. oder) Werden nun wie bei einem Reset üblich, alle oder die meisten die FF asynchron initialisiert, muss man für setzen/löschen im "Normalbetrieb" Logik vor den Dateneingang D und das enable CE synthetisieren. Das führt insbesonders bei FSM zu zusätzlichen Logikleveln (mehr resourcenverbrauch) und verlangsamt das Design. Hier (Xilinx) ist der asynchrone Reset eine Verschwendung an ressorucen) Unklar bleibt die Begründung warum ein Design mit (ausschliesslich) synchronen Reset/Set mehr Resourcen benötigen soll als eines mit asynchronen. Bitte erläutern. MfG,
Angehängte Dateien:
Fpga Kuechle schrieb: > Unklar bleibt die Begründung warum ein Design mit (ausschliesslich) > synchronen Reset/Set mehr Resourcen benötigen soll als eines mit > asynchronen. Bitte erläutern. Ich habe dazu mal ein einfaches Beispieldesign geschrieben. Das Einsynchronisieren des Resets habe ich mal großzügig weg gelassen.
Dabei habe ich das ganze im Cyclone 3 implementiert. Der hat (vielleicht im Gegensatz zu Xilinx) keinen synchronen Reseteingang am FF. Das Resultat des Technology Map Viewers ist im Anhang zu sehen. Dabei wird schnell deutlich, dass die Variante mit dem asynchronen Reset nur ein LUT4 benötigt und das mit dem synchronen Reset zwei. Daher Ressourcen verschwendet und Geschwindigkeit verschenkt. Bei anderen Technologien kann das aber auch anders sein. Ich habe das ganze auch einmal testweise nur mit dem asynchronen Teil und einmal mit dem synchronen Teil compiliert. Einmal wird 1 "Total logic elements" benötigt und einmal 2. MfG Uups, zwei mal das gleiche Bild Sorry. Ich wollts nur einmal hochladen.
Angehängte Dateien:
> Ich habe dazu mal ein einfaches Beispieldesign geschrieben. > Dabei habe ich das ganze im Cyclone 3 implementiert. Der hat > (vielleicht im Gegensatz zu Xilinx) keinen synchronen Reseteingang am FF. Ich habe das mal für Xilinx synthetisieren lassen. Und das Ergebnis: es wird einfach nur die Betriebsart des FFs umgeschaltet (siehe Screenshot). Offenbar sind die Altera-FPGAs eher auf die traditionelle Schreibweise (wie sie in jedem Buch zu finden ist) mit asynchronem Reset ausgelegt. Über was man sich auf jeden Fall im Klaren sein sollte: Nicht das Eintreten in den Resetzustand ist kritisch. Spannend wird es, wenn der Resetzustand verlassen werden soll. Von solchen "trivialen" Dingen wie Spikes auf dem Reseteingang und daraus resultierend nur halb zurückgesetzten FPGAs mal abgesehen... :-o Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten
