Hallo! Ich habe hier ein Design vor mir, welches mehrere Taktbereiche enthält. Leider produziert das einige Timingwarnungen (zu Recht), welche ich gerade versuche zu beheben. Ein Problem dabei ist folgendes: Ein kurzer Puls aus dem 40MHz-Bereich soll in den 4MHz-Bereich gebracht werden. Auf beiden Taktbereichen soll der Puls genau eine Taktperiode lang sein. Wichtig dabei ist, das kein Puls verloren gehen darf (ausreichender Abstand zwischen den Pulsen ist vorhanden). Meine Lösung sieht nun so, wie im Anhang zu sehen, aus. Auch wenn man eigentlich keine normalen Signale auf einen Takteingang legt, schien es hier eine brauchbare Lösung zu sein. Meine Frage: ist das nun eine wasserdichte Lösung für das Problem? Leider produziert das immernoch eine Timingwarnung.
Klaus schrieb: > ist das nun eine wasserdichte Lösung für das Problem? Nein, auf das letzte FF muss nochmals ein FF folgen, welches dann das 2. und 3. FF zurücksetzt.
Wenn ich das richtig verstanden habe, hast du einen 40 MHZ Takt -Puls-. Du willst einen Puls aus dem 40 MHZ Takt in den 4 MHZ Takt synchron einbringen. Meine Idee dazu wäre, die 40 MHZ per Zähler-IC in den 4 MHZ Bereich bringen. Beide Signale phasenrichtig per UND-Glied verknüpfen. Dürfte mit zwei entsprechenden IC's kein Problem sein.
> Beide Signale phasenrichtig per UND-Glied verknüpfen....
nene, keine Kombinatorik im CLK-Pfad!
Klaus Falser schrieb: > Nein, auf das letzte FF muss nochmals ein FF folgen, welches dann das 2. > und 3. FF zurücksetzt. Wieso das? Das zweite FF wird doch zurück gesetzt, sobald das nachfolgende den Puls übernommen hat. Und da das zweite FF nun wieder 0 ist, wird mit der nächste Taktflanke (des 4MHz Taktes) auch das dritte FF wieder zurück gesetzt. Das ganze ist übrigens in AHDL geschrieben. Das Bild hab ich nur zur Veranschaulichung gemalt, da hier nicht jeder AHDL kann (ich lerns auch gerade erst ;-) .
Klaus Falser schrieb: > auf das letzte FF muss nochmals ein FF folgen, welches dann das 2. > und 3. FF zurücksetzt. ansatzweise also so: http://www.lothar-miller.de/s9y/categories/19-SpikePuls
John W. schrieb: > http://www.fpga4fun.com/CrossClockDomain1.html Ja, das ist die normale Vorgehensweise, aber die funktioniert hier nicht. Denn das Eingangssignal wird ja mit dem Zieltakt abgetastet. Und das führt dazu, dass kurze Pulse eines schnelleren Eingangstaktes verloren gehen können.
Lothar Miller schrieb: > ansatzweise also so: > http://www.lothar-miller.de/s9y/categories/19-SpikePuls ok, bis auf das zweite Sync-FF genau wie meine Lösung. Ist das zweite FF wirklich notwendig, oder eher eine Vorsichtsmaßnahme? Selbst wenn im ungünstigsten Fall ein metastabiler Zustand auftritt, müsste doch in jedem Fall ein 1-Takt langer Puls am Ende heraus kommen. Oder nicht? Und dann ist die Frage, kann ich die Timing-Warnung nun ignorieren (die ja auch bei 2 sync-FFs auftritt)?
Klaus schrieb: > Klaus Falser schrieb: >> Nein, auf das letzte FF muss nochmals ein FF folgen, welches dann das 2. >> und 3. FF zurücksetzt. > > Wieso das? Das zweite FF wird doch zurück gesetzt, sobald das > nachfolgende den Puls übernommen hat. Das 3. FF kann metastabil werden, d.h. am Ausgang hast Du noch kein sauberes Signal. Erst durch ein 4. FF wird der Ausgang vom 3. FF nach Abklingen der Metastabilität (jedenfalls mit sehr großer Wahrscheinlichkeit) sauber übernommen und für einen Takt auf 1 gesetzt. Dieser Puls ist sauber und kann dir das 2. und 3. FF sauber zurücksetzen. > > Das ganze ist übrigens in AHDL geschrieben. Das Bild hab ich nur zur > Veranschaulichung gemalt, da hier nicht jeder AHDL kann (ich lerns auch > gerade erst ;-) . Solltest Du besser nicht. Lerne liebe gleich VHDL oder Verilog.
Klaus Falser schrieb: > Das 3. FF kann metastabil werden, d.h. am Ausgang hast Du noch kein > sauberes Signal. Erst durch ein 4. FF wird der Ausgang vom 3. FF nach > Abklingen der Metastabilität (jedenfalls mit sehr großer > Wahrscheinlichkeit) sauber übernommen und für einen Takt auf 1 gesetzt. > Dieser Puls ist sauber und kann dir das 2. und 3. FF sauber > zurücksetzen. Ok, danke, jetzt hab ich es verstanden! Klaus Falser schrieb: > Das ganze ist übrigens in AHDL geschrieben. Das Bild hab ich nur zur >> Veranschaulichung gemalt, da hier nicht jeder AHDL kann (ich lerns auch >> gerade erst ;-) . >> Solltest Du besser nicht. Lerne liebe gleich VHDL oder Verilog. Nun leider habe ich nicht die Wahl. VHDL ist bei uns in der Firma zwar mittlerweile Standard aber ein paar alte Designmodule in AHDL (und sogar große grafische Module) existieren leider noch.
Einfach den 4er durch den 40er eintakten und dann jeweils einen einizgen 40MHz-langen Impuls senden. Der wird vom 4er garantiert genau 1x erkannt.
vertippt: Ich meinte auf der 40er Seite den 4er-Takt einsynchroniseren und dann dort einen 4MHz-langen impuls senden. Da das Einlesen 2 oder 3 samples dauert und das Senden noch mal 1 verzögert ist, sollte nach 4 40er Takten der Ausgang für 250 us hoch gehen. Das wäre genau in der Mitte des 4ers. Dort muss dann nicht mehr synchronisiert werden und die Latenz ist minimal bei einem halben Takt.
Klaus Falser schrieb: > Erst durch ein 4. FF wird der Ausgang vom 3. FF nach > Abklingen der Metastabilität (jedenfalls mit sehr großer > Wahrscheinlichkeit) sauber übernommen und für einen Takt auf 1 gesetzt. In aktuellen FPGAs ist bei den angesprochenen Taktfrequenzen Metastabilität absolut kein Thema! Das 3. FF hat sich garantiert schon ewig beruhigt, bis der nächste Takt kommt. http://www.lothar-miller.de/s9y/archives/62-Testaufbau-Metastabilitaet.html Ich habe Langzeitversuche (ca. 2 Monate) gemacht, und da ist bei 100MHz Metastabilität nicht ein einziges Mal so aufgetreten, dass die nächsten FFs was davon bemerkt hätten. Und das waren dann immerhin 5*10^14 Taktflanken, wo etwas hätte schiefgehen können... Schlimmer ist eine FSM mit asynchronem Eingang. Die wird auch bei noch so niedriger Taktfrequenz (wo Metastabilität sicher keine rolle mehr spielen kann) einfach durch die Verletzung der Setup-Zeiten und unterschiedliche Routings ins Schleudern gebracht: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
http://www.doulos.com/knowhow/fpga/fastcounter/ Google gibt unter dem Begriff "flancter" noch viele weitere Ergebnisse aus. Schönes Wochenende Marcus
Lothar Miller schrieb: > In aktuellen FPGAs ist bei den angesprochenen Taktfrequenzen > Metastabilität absolut kein Thema! Das 3. FF hat sich garantiert schon > ewig beruhigt, bis der nächste Takt kommt. Metastabilität mag stimmen. Aber Du vergisst, dass die anderen FF asynchron zurückgesetzt werden. Was passiert, wenn das Synchronisation-FF zuerst nur einen Glitch am Ausgang produziert, dieser setzt die anderen FFs zurück, aber der Ausgang des Sync-FF fällt zurück auf 0. Dann verliertst Du einen Puls. Dass der metastabile Zustand abklingt, heist ja ja nur dass der Ausgang stabil wird, aber nicht auf welchem Pegel. Also ich würde das weitere FF opfern und wäre dann beruhigt.
Anbei eine Beispiellösung aus unserem Vorlesung "Digitale Systeme". Gruss, Valentin
> Metastabilität mag stimmen. Aber Du vergisst, dass die anderen FF > asynchron zurückgesetzt werden. Was genau das Grundübel in synchronen Schaltungen ist. Wann hört das endlich mal auf, dass ständig asnychron gearbeitet werden muss? Es gibt bei modernen FPGAs mit INIT-Werte und hohen Tatkfrequenzen keinen Grund mehr dafür. Glue-Logic gehört in PLDs oder eigene Pfade.
Klaus Falser schrieb: > Aber Du vergisst, dass die anderen FF asynchron zurückgesetzt werden. Sieh dir das nochmal an: nur das allererste (asynchron gesetzte) FF wird asynchron zurückgesetzt. Die anderen beiden Eintakt-FFs sind synchron. Robert schrieb: > Wann hört das endlich mal auf, dass ständig asnychron gearbeitet > werden muss? Nie. Jeder Schalter ist asynchron... ;-) Aber man sollte echt mal die Templates abschaffen, die immer mit "if reset" beginnen... Valko S. schrieb: > Anbei eine Beispiellösung aus unserem Vorlesung "Digitale Systeme". Das ist die schlechte Variante von meiner Lösung. Für diese Variabte gilt der Einwurf von Klaus uneingeschränkt. Das erste FF wird irgendwann gesetzt und verletzt dabie die Setup-Zeit des 2. FFs. Das produziert z.B. einen 127ps langen Spike, der ausreicht, das erste FF zurückzusetzten, und fällt dann auf '0' zurück. Beim nächsten Takt sieht es aus, als ob nie ein Puls am ersten FF dagewesen wäre... Diesen Flancter muß ich mir mal ansehen... ;-)
Lothar Miller schrieb: > Klaus Falser schrieb: >> Aber Du vergisst, dass die anderen FF asynchron zurückgesetzt werden. > Sieh dir das nochmal an: nur das allererste (asynchron gesetzte) FF wird > asynchron zurückgesetzt. Ja, aber wenn das passiert ist der Takt Puls verloren ... Aber ich denke, wir reden eh vom selben. Die Original-Schaltung vom TO ist auf Metastabilität empindlich, und die Schaltung von Valko ist sogar falsch, weil das erste FF synchron, statt asynchron zurückgesetzt wird (Jedenfalls wenn man R-Eingänge als synchrone und CLR-Eingänge als asynchrone Resets interpretiert. Naja, die Universitäten von heute ... ). Richtig ist Deine Schaltung 19-SpikePuls, wobei man man als Variante den Reset am 2. FF asynchron ausführen und den am 3. FF weglassen könnte.
Klaus Falser schrieb: >> Aber ich denke, wir reden eh vom selben. Das sieht ganz so aus ;-) Ich hatte die falsche Schaltung vom TO schon verdrängt, und die von dir erwähnten Schwachstellen in meiner Schaltung gesucht... Klaus Falser schrieb: > Jedenfalls wenn man R-Eingänge als synchrone und CLR-Eingänge als > asynchrone Resets interpretiert. Bei Xilinx ist das so, aber Valkos RTL-Schematic ist von einem anderen Synthesetool... Mich würde der Quelltext interessieren. Marcus Harnisch schrieb: > unter dem Begriff "flancter" Die Sache mit dem flancter muß ich mir bei Gelegenheit auch mal genau anschauen. Ich bin mir noch ein wenig unschlüssig, was dabei die Vorteile sind... :-/
Lothar Miller schrieb: > Marcus Harnisch schrieb: >> unter dem Begriff "flancter" > Die Sache mit dem flancter muß ich mir bei Gelegenheit auch mal genau > anschauen. Ich bin mir noch ein wenig unschlüssig, was dabei die > Vorteile sind... :-/ Also so wie ich das verstanden hab, kann man damit ohne Timingprobleme ein Flag aus 2 verschiedenen Takt bereichen einmal setzen und einmal löschen. Das Problem dabei ist: Das Auslesen des Flags ist nicht timingsicher, da ja die steigende, bzw. fallende Flanke des Flags zu jeweils einem Taktbereich asynchron ist.
Klaus schrieb: > Das Problem dabei ist: > Das Auslesen des Flags ist nicht timingsicher Ja, denn das Ding ist zu jeder der beiden Taktdomänen asynchron...
Noch ein Variante: Wenn ein Puls auf den 40 MHz kommt -> temporäres Signal toggeln. Temporäres Signal auf 4 MHz einsynchronisieren und wenn es toggelt -> Puls auf 4 MHz erzeugen. Einsynchronisieren muß man natürlich nur, wenn die 40 MHz und die 4 MHz von verschiedenen Taktquellen kommen. Duke
Duke Scarring schrieb: > Noch ein Variante: Da könnte ich mir aber gut vorstellen, dass mal Pulse verloren gehen:
1 | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
2 | 40MHz _| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |
3 | ___ ___ |
4 | Puls __________| 1.|___________| 2.|_____________________________ |
5 | _______________ |
6 | Toggle _____________| |______________________________ |
7 | _ ________________ |
8 | 4MHz |________________________________________| |
Eingangsmultiplexer und PLL+VCO - falls es noch nicht erwähnt wurde. Es gibt auch ne Menge Patente zu diesem Thema.
und die meisten davon sind abgelaufen, weil das ein uralter Hut ist. Die Problematik stellt sich Digitalelektrikern schon immer.
Bevor MaWin antwortet: Wa meinte da der Chefdesigner? Ist doch gut, wenn abgelaufen. Dann brauchste dir keine Gedanken machen.
Lothar Miller schrieb: > Da könnte ich mir aber gut vorstellen, dass mal Pulse verloren gehen: Im ersten Beitrag steht: Klaus schrieb: > (ausreichender > Abstand zwischen den Pulsen ist vorhanden) Das hätte ich jetzt so verstanden, daß der Pulsabstand nicht kleiner als 500 ns ist... Duke
Duke Scarring schrieb: > Das hätte ich jetzt so verstanden, daß der Pulsabstand nicht kleiner als > 500 ns ist... Na gut... ;-)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.