Ich habe ein 8-Bit Register REG1 getaktet von Takt CLK1 und ein 8-Bit Register REG2 getaktet von Takt CLK2. Ich möchte nun, dass REG2 die Werte von REG1 übernimmt. Problem ist dabei, dass CLK2 sich ändern kann, während die Bits in REG1 noch nicht stabil sind. Wie synchronisiert man mehrere Bit gkleichzeitig, so dass in REG2 nur Werte ankommen, die in REG1 tatsächlich gültig waren ? Dass, je nach Takt CLK1 und CLK2, manche Werte von REG1 fehlen oder doppelt vorkommen ist kein Problem.
Martin O. schrieb: > Wie synchronisiert man mehrere Bit gkleichzeitig, so dass in REG2 > nur Werte ankommen, die in REG1 tatsächlich gültig waren ? Man nimmt ein zusätzliches Signal, das anzeigt, dass die Werte im REG1 stabil sind, und synchronisiert das ein. So wie es z.B. bei SRAMs gemacht wird: beim Schreiben werden erst Adressen und Daten angelegt, dann wird mit einem einzigen Write-Signal gesagt, dass die parallelen Busse (A+D) jetzt stabil sind. > Dass, je nach Takt CLK1 und CLK2, manche Werte von REG1 fehlen > oder doppelt vorkommen ist kein Problem. Was ist die Quelle, was das Ziel? Und woher kommen die "Takte"?
da macht man ein handshaking: reg1 legt daten an reg1 sendet "data avail" 1 clk später reg2 holt daten wenn data avail==HIGH reg2 sendet "data fetched" reg1 löscht "data avail" reg2 löscht "data fetched"
Ich hab' das noch nirgends besser erklärt gefunden als hier: http://www.lothar-miller.de/s9y/archives/41-Einsynchronisieren-von-asynchronen-Signalen.html
Martin schrieb: > reg2 holt daten wenn data avail==HIGH Da muss man aber sehr aufpassen, dass dieses "data avail" Register nicht dupliziert wird. Das hatten wir vor kurzem im Beitrag "Re: Zeitkritisches Einsynchronisieren asynchroner Signale" Eigentlich muss dieses "data avail" einsynchronisiert werden...
Bezieht sich die Besorgnis dabei wirklich auf Metastabilität, wie im Beitrag beschrieben? Das sollte praktisch kein Problem sein, weil auch duplizierte FFs letztlich direkt an ihrem Vorgänger angeschlossen sind und die Delays niemals so gross werden, dass kein budget mehr für die handvoll ps an Meta bleibt. Das Problem ist hier ja auch nicht Metastabiltität, sondern der Taktübergang an sich den man mitunter inkonsistent reinbekommt. Je nach Taktfrequenz gibt es gfs gar kein stabiles data_valid, bzw nicht bei jeder Änderung. Da sollte man auf einen Wechselpuffer = asynchrones FIFO zurückgreifen, gfs unter geeigneter Dezimierung der Datenrate am Ausgang, dabit man nur jeden zweiten Datenwechsel erhaschen muss. So kann man z.B. auch problemlos 100 MHz Daten mit nur 60 MHz abtasten und verarbeiten.
Martin O. schrieb: > Ich habe ein 8-Bit Register REG1 getaktet von Takt CLK1 > und ein 8-Bit Register REG2 getaktet von Takt CLK2. > > Ich möchte nun, dass REG2 die Werte von REG1 übernimmt. > Problem ist dabei, dass CLK2 sich ändern kann, während die > Bits in REG1 noch nicht stabil sind. Wie synchronisiert man > mehrere Bit gkleichzeitig, so dass in REG2 nur Werte ankommen, > die in REG1 tatsächlich gültig waren ? > > Dass, je nach Takt CLK1 und CLK2, manche Werte von REG1 fehlen > oder doppelt vorkommen ist kein Problem. ueber was reden wir hier denn konkret? Geht es um CLK-Domains auf dem FPGA oder in Verbindung mit externen Chips? Falls auf dem FPGA: http://www.fpga4fun.com/CrossClockDomain.html oder die hier schon angesprochenen FIFOs. Falls off-chip: Beim schreiben ins FPGA ist das mit dem schon von Lothar angemerkten 'strobe' eigentlich kein Problem, man kann das ganze ja auch noch einen Takt pipelinen. Solange das effektive 'strobe'-Signal aus einem FF gebildet wird, ist das immer sauber. Falls es ums lesen vom FPGA geht, dann wird das ganze schon trickreicher und man muss halt evtl. das Lesetiming (bevorzugt auch wieder mit einem 'strobe') entsprechend anpassen (eventuell langsamer machen, z.B. die Leseadresse frueher anlegen). Also im Eingangspost fehlen wieder mal, wie leider oft ueblich, die Randbedingungen...
Jürgen Schuhmacher schrieb: > Bezieht sich die Besorgnis dabei wirklich auf Metastabilität, wie im > Beitrag beschrieben? Nein, ganz&gar nicht, Metastabilität ist selten ein/das Problem. Problematisch ist zu 99% ein unterschiedliches Routing-Delay. Siehe dort: http://www.lothar-miller.de/s9y/archives/62-Testaufbau-Metastabilitaet.html Der Witz ist ja, dass das "data avail" nicht nur an 1 Flipflop geht, sondern an alle die Datenregister... Jürgen Schuhmacher schrieb: > Das sollte praktisch kein Problem sein, weil auch duplizierte FFs > letztlich direkt an ihrem Vorgänger angeschlossen sind Aber genau das muss nicht so sein. Das duplizierte Flipflop kann irgendwo im FPGA platziert werden. > und die Delays niemals so gross werden, dass kein budget mehr für die > handvoll ps an Meta bleibt. Ein asynchrones Design hat keinerlei Budget. Das asynchrone Signal kommt&geht, wann es will. Und dieses Fehlerbild ist ein Fehler, der umso seltener auftritt, je weniger Unterschied in der Laufzeit ist. Bei ein paar ps kann das dann schon mal einen Monat dauern. Aber der Fehler ist prinzipiell im Design... :-o Martin O. schrieb: > Ich habe ein 8-Bit Register REG1 getaktet von Takt CLK1 > und ein 8-Bit Register REG2 getaktet von Takt CLK2. Welche Frequenzen haben CLK1 und CLK2? Welche Systemfrequenz hat dein FPGA?
Ich meinte Folgendes: Zwischen dem Ausgang des ersten FFs und dem nächsten, welches u.U. dupliziert wurde, liegt ein kompletter Takt und das daraus folgende budget im Bezug auf mögliche Routingverzögerungen. Mit einkalkuliert sind Jitter des Taktes und auch das Routing selber (timing driven placement). Da dort "grosszügig" gerechnet wird, ist das bischen "Meta" inklusive und macht kein Problem und zwar auch nicht theoretisch. Laut einem Xilinx FAE sind diese ps mit eingeplant. Du gehss aber wohl vom dem Fall aus, dass bereits das erste FF dupliziert wurde. Das darf natürlich nicht sein, richtig, denn dann haben wir ja genau den unsynchronen Fall eines überall hinlaufenden asynchronens Resets, den manche immer wieder bauen. Dies zu verhindern, ist normalerweise die Aufgabe des IO-FFs in der IO-Zelle. Das kann nicht dupliziert werden. Stellt sich nun die Frage, wie ich beim Design aktiv dafür sorgen könnte, dass ein internes FF nicht dupliziert wird. Eigentlich sollte es dafür dann keinen Anlass geben, wenn das valid-Signal in der ersten und der zweiten Domain jeweils noch über FF läuft, weil dann kein Fan-out- oder Timing-Problem besteht. Zudem müsste die Synthese "wissen" dass sie das nicht tun darf, z.B. beim register balancing. Da ich das nicht 100% sicherstellen kann, arbeite ich da bislang immer mit Wechselpuffer und bedarfsweise Gray-Countern.
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.