Ein erstklassiges Forum. Ich habe nun eine ganze Weile die fpga/vhdl Beisträge durchgearbeitet. Dennoch, oder vielleicht deshalb, bin ich etwas durcheinander. Ich habe wohl weniger verstanden als ich zwischendurch dachte und weil in einigen Threads durchkam, zu was man wohl nach einer einsemestrigen Vorlesung in der Lage sein sollte, versuche ich nun Lücken aufzufüllen. Ich bin mir sehr wohl bewusst, daß die Lernfähigkeit meines Hirns nicht mit jemand im studentischen Alter mithalten kann, aber was muss das muss... Frage bezieht sich auf den Reset. Ich habe für mich aus den Beiträgen gezogen, das ein Reset nicht gemacht werden soll. Ein asynchroner auf gar keinen Fall. Die Begründung so wie ich es verstanden habe ist, daß man nicht 100% sicher sein kann, daß alle FF bei jeder Pulsform das Signal mitbekommen und dann teilweise zurückgesetzt sind, teilweise nicht. Ein emv spike auf dieser Leitung wäre z.B. ein solcher Auslöser. Nun liest man aber in fast allen Büchern (und nicht nur exotischen sondern auch den empfohlenen Lehrbüchern) Beschreibungen mit asynchronem Reset. Schreiben die ohne nachdenken voneinander ab, denn wenn das Problem so gravierend ist, würde ja gefährliche Praxis vermittelt. Zur allgemeinen reset frage noch einige konkrete. Reset würde von den Tools intern über ein reset Netz verteilt. ist das richtig? Wenn das so ist sollte doch das Problem, daß die FF reset zeitlich extrem versetzt bekommen entschärft sein? Und einen noch so kurzen Puls bekommen doch trotzdem alle angeschlossenen FF irgendwann mit. Wenn nach einem reset eine gewisse Zeit kein clk anliegt, gibt es dann Probleme mit nicht zurückgesetzten FF? Als gefährlich war ja auch das Szenario beschrieben wenn reset eben unmittelbar vor clk eintritt. Stoppt der reset Knopf den Takt - keine Probleme? Sollte man dann ein reset Signal eintakten und im ganzen Design taktsynchron verwenden? Bei Herrn Miller ist ja eine Schaltung vorgestellt, die einen (nahezu) beliebig kurzen Puls auf Taktlänge bringt. Dann wäre nach einem Reset alles im fpga wenigstens auf default Werten was für mein Gefühl irgendwie wünschenswert ist. Ich denke an Automaten, default Registerwerte usw. die doch zum Rest des zurückgesetzten Systems passen müssen. Wie gesagt, ich habe riesige Verständnislücken das ist mir bewusst. Die sollen wenn möglich gefüllt werden, das kann auch länger als die Zeit einer Vorlesung dauern. viele Grüße
Die Sache mit dem Reset ist mehr oder minder eine Geschmackssache, ob synchron oder asynchron. Problematisch ist der asynchrone Reset deshalb, weil er metastabil sein kann und die Removal Time verletzt sein kann. In der Praxis heißt das, dass bei unsauberem Design Probleme entstehen: Manche Register werden resettet, manche gar nicht und manche einen Taktzyklus früher oder später. Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber noch lange nicht, dass der Reset alle Register zeitgleich erreicht. Oft wird daher beim asynchronen Reset folgendes empfohlen: Asynchron anlegen und synchron zurücksetzen. Dadurch wird der Reset eingetakt und Probleme mit der Metastabilität umgangen. Wobei für synchrone Rücksetzen die Removal Time beachtet werden muss d.h. in diesem Ausnahmefall macht es möglicherweise Sinn auf der fallende Flanke (statt der steigenden) das Resetsignal zurückzusetzen.
"Oft wird daher beim asynchronen Reset folgendes empfohlen: Asynchron anlegen und synchron zurücksetzen." Könntest du das mit einem pseudo Code Schnipsel konkretisieren? ich bin mir nicht ganz sicher, daß ich dir vollständig richtig folge. Danke
Ich denke er meint das man den Reset einfach mit 1-2 FF's Einsynchronisieren sollte.
Sym schrieb: > Reset wird bei den FPGAs über ein Taktnetz verteilt. Aber garantiert nicht bei allen! > Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber > noch lange nicht, dass der Reset alle Register zeitgleich erreicht. Genau das muss ein Taktnetz aber garantieren. > Dadurch wird der Reset eingetakt und Probleme mit > der Metastabilität umgangen. Bleib mit der Metastabilität aus diesem Thema raus. Es ist zum überwiegendsten Teil ein Problem von simplen Laufzeiten. http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren Ich würde wetten, du hast bei Taktfrequenzen kleiner 200MHz bei aktuellen FPGAs noch nie ein Problem mit einem metastabilen FF gehabt. Sehr wohl aber mit unterschiedlichen Laufzeiten wegen eines nicht artgerecht einsynchronisierten Eingangs. Und ich hätte sehr gute Chancen auf einen Gewinn... ;-) Kurz: ob ein asynchroner Reset beschrieben werden darf oder sogar sollte, hängt von der Zielarchitektur ab. Siehe auch den Beitrag "Xilinx und die Resets" Konstantin L. schrieb: > Reset würde von den Tools intern über ein reset Netz verteilt. Es gibt ein globales Resetnetzwerk, an das alle FFs angeschlossen sind. Aber weil in deinem Design garantiert (!) nicht für alle Elemente ein Reset beschreiben ist, kann dieses Netz nicht verwendet werden. Fazit: Der Reset wird händisch gereoutet... Nicht mehr... > Und einen noch so kurzen Puls bekommen doch > trotzdem alle angeschlossenen FF irgendwann mit. Nein. Das gibt dann auch lustige Fehler, wenn dir das halbe Design zurückgesetzt wird. Und jedesmal eine andere Hälfte... :-o > Bei Herrn Miller ist ja eine Schaltung vorgestellt, > die einen (nahezu) beliebig kurzen Puls auf Taktlänge bringt. Das schnelle Reagieren macht für einen Reset keinen Sinn. Ich gehe (wenn ich mal unbedingt muß) eher den anderen Weg: das externe Resetsignal muß mindestens 100 Taktzyklen stabil anliegen, sonst wars evtl. nur ein EMV-Spike...
Die Frage ist doch eigentlich, wofür der Reset gut sein soll. Und genau daraus ergeben sich dann die Dos bzw. Donts. FPGA oder ASIC? Muss der Chip wirklich im Betrieb von aussen zurückgesetzt werden können? Und wenn ja, wirklich alles oder nur ein paar Statemachines/Register? Geht es um sinnvolle Startupwerte nach dem Laden des FPGAs? Geht es nur um einen vernünftigen Start der Simulation, damit man nicht die U->X-Rotpest auslöst? Von daher sind IMO Generalisierungen ala "async Reset ist des Teufels" oder "Ohne Resetpin ist die Spec unvollständig" wenig hilfreich.
Lothar Miller schrieb: >> Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber >> noch lange nicht, dass der Reset alle Register zeitgleich erreicht. > Genau das muss ein Taktnetz aber garantieren. Das Taktnetz erlaubt es ein Signal verzögerungsärmer zu verteilen. Verletzungen der Removal time kann es aber nicht verhindern. Bei einer Removal Time Violation des Resets startet ein Register früher als ein anderes. > Ich würde wetten, du hast bei Taktfrequenzen kleiner 200MHz bei > aktuellen FPGAs noch nie ein Problem mit einem metastabilen FF gehabt. > Sehr wohl aber mit unterschiedlichen Laufzeiten wegen eines nicht > artgerecht einsynchronisierten Eingangs. > Und ich hätte sehr gute Chancen auf einen Gewinn... ;-) Wenn du 2x einsynchronisieren als ordnungsgemäß betrachtet, dann hast du verloren. Manchmal bringt tatsächlich eine 1-2 weitere Stufen die erhoffte Stabilität. >> Und einen noch so kurzen Puls bekommen doch >> trotzdem alle angeschlossenen FF irgendwann mit. > Nein. > Das gibt dann auch lustige Fehler, wenn dir das halbe Design > zurückgesetzt wird. Und jedesmal eine andere Hälfte... :-o Richtig. Ein Puls muss nicht vom allen FFs gesehen werden. >> Bei Herrn Miller ist ja eine Schaltung vorgestellt, >> die einen (nahezu) beliebig kurzen Puls auf Taktlänge bringt. > Das schnelle Reagieren macht für einen Reset keinen Sinn. > Ich gehe (wenn ich mal unbedingt muß) eher den anderen Weg: das externe > Resetsignal muß mindestens 100 Taktzyklen stabil anliegen, sonst wars > evtl. nur ein EMV-Spike... Zeit hat man. Den asynchronen Reset sollte man in die gewünschte Taktdomain reintakten. Allerdings darf man das Resetsignal nicht knapp nach der Taktflanke der FFs zurücksetzen, weil man sonst die Removal Time verletzt. Ein möglicher Weg ist es daher, das Reset auf die andere Flanke zurückzusetzen. (d.h. FFs auf rising edge, reset wird bei falling edge deaktiviert).
Sym schrieb: > Allerdings darf man das Resetsignal nicht knapp nach der Taktflanke der > FFs zurücksetzen, weil man sonst die Removal Time verletzt. Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine Setup-Zeit zu beachten. > Ein möglicher Weg ist es daher, das Reset auf die andere Flanke > zurückzusetzen. (d.h. FFs auf rising edge, reset wird bei falling > edge deaktiviert). Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird... Sym schrieb: > Wenn du 2x einsynchronisieren als ordnungsgemäß betrachtet, dann hast du > verloren. Manchmal bringt tatsächlich eine 1-2 weitere Stufen die > erhoffte Stabilität. Dann hast du ein anderes Problem. Bei Taktfrequenzen kleiner 200MHz ist Metastabilität auf jeden Fall kein Thema. Siehe dazu den Beitrag "Detailbetrachtungen zur Metastabilität"
Lothar Miller schrieb: > Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine > Setup-Zeit zu beachten. Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle?
Mathi schrieb: > Lothar Miller schrieb: >> Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine >> Setup-Zeit zu beachten. > > Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle? Schau ins FPGA Datenblatt
D. I. schrieb: > Schau ins FPGA Datenblatt ins = in das Hat sich der Markt in den letzten Minuten so verdichtet das es nur noch ein FPGA gibt? ;) Im Datenblatt des ECP3 sind 15ps angegeben. Und auch im Virtex5 Datenblatt finde ich keine 0ns.
Lothar Miller schrieb: > Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten > Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit > für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird... Das verstehe ich nicht. Wenn ich im Resetzustand bin, dann sollte die Schaltung (auch alle Flip Flops) irgendwann einen stabilen Reset-Zustand eingenommen haben. Den sollte sie erst bei der ersten Taktflanke nach dem Reset verlassen (da ja die FFs erst zu diesem Zeitpunkt neue Werte annehmen können). Das Wegnehmen des Resets zur fallenden Flanke sollte daher also nicht die Eingänge irgendwelcher Flip-Flops verändern können. Daher kann dann auch keine Setup-Zeit-Verletzung auftreten. Höchstens eine Verletzung einer einzuhaltenden Zeit zwischen Reset und erster Taktflanke (falls es die gibt. Hab ich mich aber noch nie drum gekümmert). Und ich kann mich erinnern, daß mir der Xilinx Timing Report irgendwann auch mal Hold-Time Violations vorgeworfen hat. War aber auch ein freakiges ASIC-Design.
Ich danke euch für die Diskussion. Der kann ich zwar nicht ganz folgen, aber macht ruhig weiter - solche Diskussionen können ja auch einen 'Klick' Effekt haben. schönen Sonntag
Hans schrieb: >> Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten >> Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit >> für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird... > Das verstehe ich nicht. Wenn ich im Resetzustand bin, dann sollte die > Schaltung (auch alle Flip Flops) irgendwann einen stabilen Reset-Zustand > eingenommen haben. Richtig: Alle Flipflops!!! Aber wenn du einen kombinatiroschen Pfad (evtl. auch irrtümlicherweise) mit einem Reset versiehst, dann kommt mit oder ohne Reset was anderes raus. Und um diese Änderung zu berechnen hast du nur die halbe SetupZeit zur Verfügung. Nimm nur mal das:
1 | :
|
2 | :
|
3 | mux_select <= externer_select when reset='0' else "111"; --- von hier |
4 | |
5 | process (reset, clk) begin |
6 | if reset='1' then |
7 | a <= "00"; |
8 | elsif rising_edge(clk) then |
9 | if mux_select = "110" then --- bis hier nur halbe Setuptzeit |
10 | a <= "01"; --- wenn Reset mit fallender Flanke inaktiv wird |
11 | elsif mux_select = "010" then |
12 | a <= b; |
13 | :
|
14 | :
|
15 | end if; |
16 | end if; |
17 | end process; |
Mathi schrieb: > Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle? Hier ein Spartan 3 (ds099):
1 | Hold Times |
2 | TAH Time from the active transition at the CLK input |
3 | to the point where data is last held at the F or G input 0 ns |
Beim Virtex 5 ist es wegen der vielfältigen Möglichkeiten ein wenig schwieriger, aber dort finden sich sogar negative Hold-Zeiten :-o Und dazu passend der Kommentar:
1 | A Zero “0” Hold Time listing indicates no hold time or a negative hold |
2 | time. Negative values cannot be guaranteed “best-case”, but if a “0” is |
3 | listed, there is no positive hold time. |
Es ist mir übrigens schon klar, dass es ein FF ohne oder sogar mit negativer Hold-Zeit nicht gibt. Solche Zeiten lassen sich mit Laufzeitunterschieden von den angegebenen Messpunkten bis zum eigentlichen Flipflop erklären. Wenn der Datenpfad länger ist, verschiebt sich das Validierungsfenster immer mehr in Richtung vor dem Takt.
Lothar Miller schrieb: > Hier ein Spartan 3 (ds099):Hold Times > TAH Time from the active transition at the CLK input > to the point where data is last held at the F or G input 0 ns > Danke schön!
Hallo Konstantin, wenn Du schon einige Threds gelesen hast, dann hast Du sicher auch gemerkt, dass es in vielen Fällen die "one and only"-Lösung nicht gibt. So wohl auch bei der Frage nach dem Reset. Zunächst möchte ich Dir aber gerne, mit Verlaub, widersprechen: Konstantin L. schrieb: > Wie gesagt, ich habe riesige Verständnislücken das ist mir bewusst. Das seh ich nicht so. Alleine die Formulierung deiner Frage zeigt, dass Dir vielleicht Erfahrung fehlt, aber nicht das nötige Verständnis. Und die Problematik des Reset wird nunmal von einigen Leuten unterschiedlich bewertet. Ich stimme Dir jedenfalls zu, wenn du meinst: Konstantin L. schrieb: > Dann wäre nach einem Reset alles im fpga wenigstens auf default > Werten was für mein Gefühl irgendwie wünschenswert ist. Ich denke an > Automaten, default Registerwerte usw. die doch zum Rest des > zurückgesetzten Systems passen müssen. Die Bedenken der meisten Antwortschreiber gehen in die gleich Richtung: Es darf nicht sein, dass durch ein irgendwie geartetes Signal an einem Reset-PIN des FPGAs dieses aus dem Tritt kommt. Und was ein prellender Taster für ein Signal abgibt, oder ein RC-Glied beim langsamen Durchlaufen der Schaltschwelle, das sieht oftmals gräulich aus. Ich habe mir daher meistens Filter in das Reset-Signal eingebaut. Etwa in der Art: Das Signal vom Reset-Taster (oder sonstwo her) muss mindestens n Takte lange aktiv sein, bevor es an die interne Logik gegeben wird. Gleiches für das Ende von Reset. Und das dann Ganze immer synchron. Zuletzt noch meine Einschätzung zu deinem konkreten Fragen: Reset würde von den Tools intern über ein reset Netz verteilt. ist das richtig? Die Tools denken inzwischen mit und verteilen Clocks, Resets, und weitere Signale mit hohem fan-out (= viele Benutzer) über spezielle Routing-Ressourcen. Wenn das so ist sollte doch das Problem, daß die FF reset zeitlich extrem versetzt bekommen entschärft sein? Entschärft ja, weg nein. Und einen noch so kurzen Puls bekommen doch trotzdem alle angeschlossenen FF irgendwann mit. Nee, leider nicht. Innerhalb des FPGA könnten tatsächlich einige Flipflops einen kurzen Reset übersehen. Die Welt ist leider nicht digital. Wenn nach einem reset eine gewisse Zeit kein clk anliegt, gibt es dann Probleme mit nicht zurückgesetzten FF? Ein extrem kurzer Reset könnte eine Statemachine in einen Zustand bringen, aus dem es keinen Ausweg gibt. Als gefährlich war ja auch das Szenario beschrieben wenn reset eben unmittelbar vor clk eintritt. Stoppt der reset Knopf den Takt - keine Probleme? Bis auf eben den Fall dass nicht alle Flipflops den Reset gesehen haben. Sollte man dann ein reset Signal eintakten und im ganzen Design taktsynchron verwenden? Klares Ja. Grüße, und viel Erfolg Harald
Harald Flügel schrieb: > Sollte man dann ein reset Signal eintakten und im ganzen Design > taktsynchron verwenden? Klares Ja. Ein klares ja deshalb, weil jedes asynchrone Signal irgendeine Einsynchronisierung (oder Validierung) braucht. Und der Reset ist ja wohl das asynchronste Signal schlechthin. > Als gefährlich war ja auch das Szenario beschrieben wenn reset eben > unmittelbar vor clk eintritt. Dieser Fall ist eigentlich ziemlich unkritisch. Wenn der lang genug anliegt, werden früher oder später alle FF den Reset gesehen haben (und bestenfalls währen der paar ps eine FSM den falschen Zustand dargestellen). Kritischer ist das Verlassen des Reset-Zustandes. Denn wenn hier ein paar FFs einer FSM schon mit den von aussen anliegenden Signalen arbeiten, und andere noch für einen Takt im Reset-Zustand sind, dann läuft das Design nicht richtig an... Das hört man dann auch immer wieder: "Mein Design startet manchmal nicht richtig. Aber wenn es läuft, dann tagelang problemlos." :-o
Lothar Miller schrieb: > Aber wenn du einen kombinatiroschen Pfad (evtl. auch irrtümlicherweise) > mit einem Reset versiehst, dann kommt mit oder ohne Reset was anderes > raus. Und um diese Änderung zu berechnen hast du nur die halbe SetupZeit > zur Verfügung. Das ist aber nun allerschlechteste Designpraxis. Wer ein asynchrones Signal in dem kombinatorischen Signalpfad abfragt gehört geschlagen. Aber es heißt ja auch Reset (also für Flip Flops) und nicht MUX-Select o.ä. Das asynchrone Reset-Signal hat also nur etwas an Flip Flops verloren. Und da funktioniert es einwandfrei (wenn entsprechend einsynchronisiert).
Hans schrieb: > Lothar Miller schrieb: >> Aber wenn du einen kombinatorischen Pfad (evtl. auch irrtümlicherweise) >> mit einem Reset versiehst > Das ist aber nun allerschlechteste Designpraxis. Wer ein asynchrones > Signal in dem kombinatorischen Signalpfad abfragt gehört geschlagen. Richtig, ich schrieb: irrtümlicherweise. Das kann auch so entstehen, dass da mal ein registriertes Signal war, das aber nach Umschreiben irgendeiner Zeile auf einmal nur noch kombinatorisch ist. Ge- und erschlagen wird er dann von der Realität... ;-)
Mathi schrieb >ins = in das > >Hat sich der Markt in den letzten Minuten so verdichtet das es nur noch >ein FPGA gibt? ;) Immer schön Korinthenkacker spielen, aber nicht mal in der Lage sein, einen deutschen Nebensatz richtig einzuleiten. (Hinweis: ,dass) ;)
NeunmalKlug schrieb: > (Hinweis: ,dass) Das müsste eher ", dass" heißen, denn sonst gehts Richtung Plenken... ;-)
NeunmalKlug schrieb: > Immer schön Korinthenkacker spielen, aber nicht mal in der Lage sein, > einen > deutschen Nebensatz richtig einzuleiten. (Hinweis: ,dass) > > ;) Wie ich sehe können wir beide das gut :-D
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.