Mir ist klar, dass ich Signale aus unterschiedlichen Clockdomains mittels Register synchronisieren muss. Wo ich allerdings noch nach einer logischen Erklärung suche ist bei der Anzahl der Register. Es wird grundsätzlich geraten (z.B. Altera/Intel) eine Synchronisation-Chain aus 2 Registern zu bauen... worin besteht der Unterschied zu nur einem Register? Kann der Ausgang eines Registers immernoch Metastabil sein, wenn sein Eingang Metastabil ist? Dann könnte ich aber auch mit 2 seriellen Registern noch eine Metastabilität haben und habe einfach die Wahrscheinlichkeit dafür verringert indem ich 2 Register zur synchronisation verwendet habe?
Genau so ist es. Metastabilität lässt sich nicht komplett vermeiden, sondern die Wahrscheinlichkeit ihres Auftretens reduzieren. Bei modernen FPGAs hat man mit zwei bis drei Synchronisationsstufen die mittlere Zeit schon bis zum Sankt-Nimmerleins-Tag ausgedehnt. Bei früheren programmierbaren Logikbausteinen hielten sich metastabile Zustände wohl tatsächlich über lange Zeiträume, d.h etliche Nanosekunden, wohingegen heutige Bausteine dagegen wesentlich besser gewappnet sind. Allerdings ist Metastabilität nur ein Aspekt. Man kann auch einfach schlecht einsychronisieren, ohne das Metastabilität auftreten muss. Hierzu gibt es sehr viele Publikationen. Der auch hier anwesende Lothar Miller hat eine sehr einfach verständliche Einführung verfasst: http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
King Julian schrieb: > worin besteht der Unterschied zu nur einem Register? Prinzipiell reicht bei heutigen schnellen FPGAs eine Registerstufe aus. Allerdings kann es dann passieren, dass so Effekte wie Register Doubling mit rein spielen und deshalb ist man bei wenig zeitkritischen Signalen einfach nach Schema F mit zwei auf der sicheren Seite... Im Prinzip ist Metastabilität bei einem Anfängerdesign im Bereich unter 250MHz nie ein Problem. In >>99% der Fälle sind es simple nicht synchronisierte Eingänge und die im obigen Link beschriebenen Laufzeiten zu den beteiligten Flipflops. Weltbester FPGA-Pongo schrieb im Beitrag #5582437: > Andreas S. schrieb: >> die mittlere Zeit > welche "mittlere Zeit"? Bis zum nächsten Fehler durch Metastabilität mach dem 2. Register...
:
Bearbeitet durch Moderator
Zu diesem Thema und solchen Überlegungen habe ich mal ein super Paper gefunden mit gesammelten kaputten "synchronizern" und den Erklärungen dazu wieso sie kaputt sind: Fourteen Ways to Fool Your Synchronizer: http://webee.technion.ac.il/~ran/papers/Sync_Errors_Feb03.pdf
Vielen Dank für die Ausführungen, die Literatur werde ich mir mal zu Gemüte führen :)
Weltbester FPGA-Pongo schrieb im Beitrag #5582437: > Andreas S. schrieb: >>die mittlere Zeit > welche "mittlere Zeit"? Damit ist hier der mittlere zeitliche Abstand zwischen zwei metastabilen Ereignissen gemeint, auf neudeutsch auch MTBF (mean time between failures) genannt.
Christoph Z. schrieb: > und den Erklärungen dazu wieso sie kaputt sind Wobei man dabei beachten sollte, dass die meisten Referenzen darin gut 20 Jahre und z.T. deutlich älter sind und sich damals(tm) die Flipflops aus metastabilem Zustand deutlich langsamer erholt haben. Und zudem sind die Erkenntnisse, die den Referenzen zugrunde liegen vermutlich noch älter... ;-)
Ja, bei den Themen FPGA hat die Information über aktuelle Technologie eine enorme Latenz:-) Es ist aber schon lustig: Das Thema META ist seit locker einer Dekade keines mehr, trotzdem trifft man es bei fast jedem Kunden an. Xilinx und auch Altera haben schon vor Jahren Dokumente dazu heraus gegeben, die offenbaren, wie kurz diese Zeiten inzwischen geworden sind und dass das praktisch untergeht, bzw. in den Timinganalysen berücksichtigt ist. Das Thema META wurde auch hier im Forum schon mehrfach erörtert und untersucht: Metastabilität ist x-mal unwahrscheinlicher, als andere Einflüsse, wie Einstreuungen auf den Leitungen, die Signalübertragung funktionell unsicher machen können und dass dem so ist, ist auch gut so, denn das, was die Meisten gegen META unternehmen, nämlich FFs spendieren, verläuft Dank vergessener keep-constraints ohnehin im Sande, weil die munter verschoben werden und physisch gar nicht mehr existieren, bzw. nicht dort, wo sie sitzen müssten um ihre Wirkung zu tun. Wir hatten das bei der Reset-Problematik schon wenigstens 3mal an unterschiedlichen Stellen hier durchexerziert, wozu das führen kann. Siehe Lothars Kommentar oben. Richtig ist auch: Das, was Viele als "META-Problem" benennen, ist nach meiner Erfahrung nichts anderes, als das grundsätzliche Datenunsicherheitsproblem, weil man nicht sicher ist, zu welchem Zeitpunkt man ein Signal erwischt und welchen Wert es beim Flankenwechsel hat. Bei Bussen ergibt sich dann ein Inkonsistenzthema und wenn man dieses löst, ist das META - so überhaupt existent - gleich implizit mitgelöst. Aus der Erfahrung der Sichtung von sicher >100 designs in den letzten Jahren kann ich zudem die Aussage treffen, dass die allermeisten theoretisch existenten META-Probleme durch die designer künstlich hervorgerufen wurden, weil sie mit allenmöglichen händisch erzeugten Takten in den designs hantieren, welche sich dann gegenseitig Daten mit ähnlichen Flankenzeitpunkten übergeben, statt einfach einen einzigen Takt und enables zu nehmen. Wenn dann wirklich mal in der Praxis solche Datenprobleme beobachtbar waren, dann war auch genau so was immer der Grund. Ich kann mich an ein design von vor 7 Jahren erinnern, das war absolut legendär: Eine zweistellige Anzahl von Takten, wo 2-3 gereicht hätten und mehr, als 25 Domänenübergänge mit angeblich ansynchronen Fifos und Angst-FlipFlops dazwischen, die überhaupt erst dafür gesorgt haben, dass das design richtig zeitkritisch wurde und teilweise inkonsistente Daten eingetaktet wurden, statt sie abzufangen, während andere verloren gingen. Da gab es alles und sicher auch den einen oder anderen Meta-Übergang inklusive verschleppter Daten infolge mangelnder constraints mit Ergebnissen, die von der Temperatur und der synthetisierten Version abhängig waren. Nach der Entmystifizierung des designs blieben 3 domains und 3 synchrone Fifos über. Halb so groß, doppelt so schnell und vor allem weniger "Rauschen" auf den Daten :-)
Über das Thema kann man auf jeden Fall lange diskutieren: Beitrag "VHDL Grundlagen Pin Zustand lesen, Flankenerkennung"
Ausgerechnet deinen eigenen Beitrag dazu zu linken, ist aber jetzt nicht so zielführend, zumal du - wie dort zu lesen ist - 1) Flankenerkennung und Synchronisation vermischst 2) "Schwingen eines flankengetriggerten D-FlipFlops" annimmst. 3) metastabile Zustände zu angeblichem altern des Chips führen Dieser thread dort ist eher in der Rubrik "Freitagsbelustigung" angesiedelt!
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.