Hallo zusammen,
ist es erlaubt, ein asynchrones Signal "doppelt schnell" zu
synchronisieren, in dem man es mit rising- und falling-edge eintaktet?
Folgendes Konstrukt geht leider nicht:
1
Synchronize:process(CLK)
2
begin
3
ifrising_edge(CLK)or
4
falling_edge(CLK)then
5
Sig_synced<=Sig_shift;
6
Sig_shift<=Sig_in;
7
endif;
8
endprocess;
Gibt es einen anderen Weg, ohne gleich per DCM einen zweiten Takt zu
erzeugen?
Grüße
Steffen
D. I. schrieb:> Wie soll ordinäres Flipflop auf 2 Flanken triggern?
Man braucht dafür 2 Flipflops, einen Inverter und einen Multiplexer. Das
eine Flipflop geht auf die steigende Flanke, das andere hat einen
Inverter im Clock-Signal. Der Multiplexer schliesslich wählt jeweils
anhand der Taktphase den richtigen Output aus. So jedenfalls steht es in
meinem (sehr guten) Lehrbuch. Und da steht auch, dass die meisten
Synthesetools mit Dual-Edge-Triggered nicht klarkommen. Du solltest also
mal die Doku des Synthesetools konsultieren, ob das überhaupt geht.
D. I. schrieb:> Wie soll ordinäres Flipflop auf 2 Flanken triggern?
Es sind doch zwei FFs, eines für Sig_shift und eines für Sig_synced.
Würde denn das gehen?
Steffen Hausinger schrieb:> Es sind doch zwei FFs, eines für Sig_shift und eines für Sig_synced.
Im ersten Post sind die aber jeweils als sensitiv auf jede Flanke
beschrieben...
> Würde denn das gehen?
Ja.
> ist es erlaubt, ein asynchrones Signal "doppelt schnell" zu> synchronisieren, in dem man es mit rising- und falling-edge eintaktet?
Von welchen Frequenzen redest du?
Prinzipiell kannst du dir die Metastabilität (falls sie je ein Problem
werden könnte) auf diese Art nicht "wegdiskutieren" oder eine Lösung
"herbeireden".
Wenn du mit Frequenzen <100MHz arbeitest, dann wird sowieso 1 einziges
FF zum Einsynchronisieren ausreichen. Heutige FPGAs sind so schnell,
dass sich dann bis zum nächsten Takt der Zustand des Sync-FFs sicher
stabilisiert hat...
Siehe dazu die Xilinx XAPP094 und das dort:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Lothar Miller schrieb:> Prinzipiell kannst du dir die Metastabilität (falls sie je ein Problem> werden könnte) auf diese Art nicht "wegdiskutieren" oder eine Lösung> "herbeireden".
Du beziehst Dich hier auf das zweite FF, richtig? Mir ist klar, dass
auch mit beliebig vielen FFs Metastabilität auftreten kann.
Lothar Miller schrieb:> Von welchen Frequenzen redest du?
Meine Systemfrequenz beträgt 50MHz.
Lothar Miller schrieb:> Wenn du mit Frequenzen <100MHz arbeitest, dann wird sowieso 1 einziges> FF zum Einsynchronisieren ausreichen.
Heißt das:
1
Synchronize:process(CLK)
2
begin
3
ifrising_edge(CLK)then
4
Sig_synced<=Sig_shift;
5
Sig_shift<=Sig_in;-- Sig_shift = 1 FF zum einsynchronisieren
6
endif;
7
endprocess;
Oder:
1
Synchronize:process(CLK)
2
begin
3
ifrising_edge(CLK)then
4
Sig_synced<=Sig_in;-- Sig_sync = 1 FF zum einsynchronisieren
Steffen Hausinger schrieb:> Meine Systemfrequenz beträgt 50MHz.
Dann reicht 1 einziges FF zum Einsynchronisieren. Die FFs im FPGAs sind
wie gesagt heutzutage so schnell, dass sich bei dieser Frequenz ein
metastabiler Zustand bis zum nächsten Takt sicher wieder stabilisiert
hat (wobei man die zusätzliche Durchlaufzeit durch eine nachfolgende
Logik nicht aus den augen verlieren darf...)
Also gilt die Lösung
> Oder:
Ich habe aktuell ein solches Problem wobei ich mal gleich vorausschicke,
dass ich sehr ungern mit falling_edge arbeite!
Leider brauche ich eine Flanke für einen FPGA-Ausgang für jeden
ankommenden Flankenwechsel des Taktsignals, weil dieses nicht permanent
50%:50% hat. Taktverdopplung per PLL gelang nicht wegen jitter. Leider
ist es aber zu schnell, um alles aynchron zu machen und es einfach
einzutakten.
Diese Lösung finde ich i.O.
lol schrieb:> D. I. schrieb:>> Wie soll ordinäres Flipflop auf 2 Flanken triggern?>> Man braucht dafür 2 Flipflops, einen Inverter und einen Multiplexer. Das> eine Flipflop geht auf die steigende Flanke, das andere hat einen> Inverter im Clock-Signal. Der Multiplexer schliesslich wählt jeweils> anhand der Taktphase den richtigen Output aus.
Von der Logik soweit ok, aber kann ich einfach den Takt negieren und ihn
auf ein FF geben? Damit verlasse ich doch das Clocknet, oder?
> So jedenfalls steht es in meinem (sehr guten) Lehrbuch.
Den Titel hätte ich gerne. Liest der Autor noch mit?
> Und da steht auch, dass die meisten> Synthesetools mit Dual-Edge-Triggered nicht klarkommen.
Könnte man nicht wie oben schreiben:
1. FF mit rising edge
2. FF mit falling edge
und deren Ausgänge dann muxen?
Wie und womit steure ich den Muxer ?
Ralf schrieb:> aber kann ich einfach den Takt negieren und ihn auf ein FF geben?
Ja.
> Damit verlasse ich doch das Clocknet, oder?
Nein. Jedes Flipflop hat sowieso ein XOR-Gatter vor dem Takteingang und
deshalb ist es einerlei, ob du rising_edge oder falling_edge verwendest.
> Leider brauche ich eine Flanke für einen FPGA-Ausgang für jeden> ankommenden Flankenwechsel des Taktsignals, weil dieses nicht permanent> 50%:50% hat.
Bei einem Verhältnis von z.B. 33/66 und Auswertung beider Flanken
verdreifachst du aber deine Anforderungen an das Timing.
> Wie und womit steure ich den Muxer ?
Das ist die Gretchenfrage: Welche Taktdomäne wird letztendlich
weiterverwendet? Oder willst du gar durchgängig mit rising_edge und
falling_edge weitermachen?
Lothar Miller schrieb:> Ralf schrieb:>> Damit verlasse ich doch das Clocknet, oder?> Nein. Jedes Flipflop hat sowieso ein XOR-Gatter vor dem Takteingang und> deshalb ist es einerlei, ob du rising_edge oder falling_edge verwendest.
Das finde ich interessant. Wo kann man sowas denn man im Detail
nachlesen?
>> Leider brauche ich eine Flanke für einen FPGA-Ausgang für jeden>> ankommenden Flankenwechsel des Taktsignals, weil dieses nicht permanent>> 50%:50% hat.> Bei einem Verhältnis von z.B. 33/66 und Auswertung beider Flanken> verdreifachst du aber deine Anforderungen an das Timing.
Das ist denke ich an der Stelle kein Problem, weil der Chip schnell
genug ist. Das Takten ist auch nur am Eingan kritisch.
>> Wie und womit steure ich den Muxer ?> Das ist die Gretchenfrage: Welche Taktdomäne wird letztendlich> weiterverwendet? Oder willst du gar durchgängig mit rising_edge und> falling_edge weitermachen?
Ich bin noch nicht sicher ob wir von derselben Sache reden. Ich hab das
gestern abend aufgebaut und da fiel mir auf, dass nichts wesentlich
anderes rauskommt, als ein DDR-FF. (?)
Was ich eigentlich brauche ist ein Signal, der zu jedem Flankenwechsel
eine steigende Flanke liefert. Also sowas:
1
Eingang _____------__________------______-------
2
Ausgang _____---___------____---___---___----___
Wie kriege ich sowas hin?
Ein Zeitversatz zwischen Ein- und Ausgang wäre zulässig, um mehrere
Wechsel auszuwerten.
@ Ralf (Gast)
>Was ich eigentlich brauche ist ein Signal, der zu jedem Flankenwechsel>eine steigende Flanke liefert. Also sowas:
Wenn dein Eingangstakt eine konstante Frequenz hat, kann das eine PLL.
Ralf schrieb:> Was ich eigentlich brauche ist ein Signal, der zu jedem Flankenwechsel> eine steigende Flanke liefert. Also sowas:
1
Eingang _____------__________------______-------
2
Ausgang _____---___------____---___---___----___
> Wie kriege ich sowas hin?
Wie schnell ist das und welche Taktfrequenz hast du in deinem Design?
BTW: das was da unter "Eingang" skizziert ist, ist kein Taktsignal im
Sinne eines FPGA-Taktes, denn es ist viel zu unregelmäßig...
Also es kommen so maximal 15MHz wobei die Verlängerung der Phasen auch
zu quasi 10MHz führen. Das Pulspausenverhältnis ist 40:60 bis 60:40
maximal, eher weniger. Am Liebsten wäre mir ein Takt, der letztlich bei
50% liegt und doppelt oder viermal grösser ist. Reichen würde es auch,
wenn die Flanken erkannt würden.
Das einzige, was mir bisher einfiel, war die Verzögerung des "Taktes"
mit einem Delay und dann ein XOR hintendran, um einen Puls zu bekommen.
Bautechnisch könnte ich das sogar analog machen, indem ich ein RC-Glied
nehme und noch einen extra Pin spendiere. Die Frage ist aber wie ich von
den unregelmässigen Pulsen dann zu einer halbwegs stabilen Frequenz
komme.
Die andere / neue Idee ist, das extrem hochfrequent abzutasten und dann
zu dezimieren.
@ Ralf (Gast)
>Die andere / neue Idee ist, das extrem hochfrequent abzutasten und dann>zu dezimieren.
Dann mach das. 150MHz sind ein Klacks in einem modernen FPGA, Faktor 10
reicht.
Ralf schrieb:> Die Frage ist aber wie ich von den unregelmässigen Pulsen dann zu einer> halbwegs stabilen Frequenz komme.
Woher kommen die?
Wofür brauchst du die?
Warum muss ich hier immer an ein Salamibrot denken?
http://de.m.wikipedia.org/wiki/Salamitaktik
Bei "Hardwareprojekte" gilt es...
ok, ok , also ich muss 2 Dinge tun: 1. die gemittelte Frequenz
herausfinden und zweitens die Periodenlänge beobachten. Wenn ich das
absanple wird es zu ungenau, fürchte ich.
Ralf schrieb:> ok, ok , also ich muss 2 Dinge tun: 1. die gemittelte Frequenz> herausfinden und zweitens die Periodenlänge beobachten. Wenn ich das> absanple wird es zu ungenau, fürchte ich.
Wie willst du die Periodenlänge denn ohne Abtastung ermitteln?
Und was ist "genau"?
> 1. die gemittelte Frequenz herausfinden
Mittelwert über welche Zeit?
> zweitens die Periodenlänge beobachten.
Beobachten ... und dann nicht tun?
Oder was soll mit der beobachteten Periode dann passieren?
Ich kann das hier nicht so genau darstellen. Hauptsächlich brauche ich
die gemittelte Frequenz, möglichst stabil. Ich bin mir bewusst, dass es
da Grenzen gibt.
Solange die eigentliche Funktion der Schaltung nicht beschrieben ist,
wird hier niemand die richtige Lösung ziehen können. Wenn es "nur" darum
geht, den Takt zu bereinigen, also einen im Durchschnitt weniger
jitternden Takt zu erzeugen, muss eine Art von PLL her, gfs eine
digitale, die manuell aufgebaut ist und die geforderte Toleranzaufweist.
Den ungleichförmigen duty cycle bekommt man weg, indem nur jeweils
dieselbe Flanke benutzt wird, womit das Thema:
> Synchronisieren auf rising- und falling-edge
schon mal infrage gestellt wäre. Soll der andererseits doch gemessen
werden, geht es entweder von edge-to-edge oder eben per Dezimation über
eine Anzahl von Takten. Ich würde den eingehenden Takt runterteilen und
dann niederfrequent einen ebenfalls heruntergeteilten Takt aus dem FPGA
drauf justieren. Jenachdem, wie weit zu teilst, gehen dann beide
Forderungen in dieselbe Lösung über: Ein Kompromiss aus gemitteltem Takt
und vermessener Periode.