Hallo zusammen,
ich muss/möchte zwei komplett zueinander asynchrone Takte multiplexen,
die dann das gleiche Flip-Flop takten, welches das Steuersignal für den
Multiplexer bereitstellt.
Das Problem besteht und kann nicht wegdiskutiert werden, weil ich zwei
Modi mit zwei unterschiedlichen Oszis habe.
CLK_IN_1 liegt im Bereich 1MHz
CLK_IN_2 liegt im Bereich 2-8MHz
So wie ich es auf dem Bild dargestellt habe, kann ich nicht
sicherstellen, dass CLK_OUT irgendwelche Spikes enthält, weil auch zwei
Flanken direkt aufeinander folgen können genau in dem Moment, wenn
umgeschaltet wird. Die Zeit zwischen den Flanken kann beliebig kurz
sein, so dass ich nie und nimmer irgendein Timing einhalten kann.
Das MUX Signal schaltet auch gleichzeitig die Oszilatoren für die
jeweiligen Takte ab bzw. zu, so dass ich nicht den schnelleren Takt als
"Hilfstakt" zum kontrollierten Umschalten mit einem Delay hernehmen
kann.
Wenn ich beide Oszilator-Ausgänge einfach mit einem OR auf das FF führe,
habe ich beim Umschalten das gleiche Problem. Die einzige Idee die ich
dazu noch habe ist, dass evtl. die Shut-Down-Zeit beider Oszis um
Größenordnungen schneller ist als die Startup-Zeit. Dann hätte ich von
Haus aus ein natürliches Delay was verhindert, dass zwei Flanken kurz
hintereinander kommen. Das muss ich noch überprüfen.
Gibt es ansonsten irgendwelche Ansätze/Ideen, wie man in solchen
Situationen verfahren kann/soll?
Vielen Dank!
Marc
Die Schaltung ist irgendwie komisch, da nicht klar ist, warum der
Multiplexer getaktet sein muss. Wo ist denn die Quelle der Information?
Deinem FF fehlt zumindest schon einmal der Eingang und der könnte den
MUX auch direkt steuern.
Der Eingang des FF kommt aus einer wilden state machine die entscheidet,
wann und unter welchen Umständen zwischen beiden Modi/Clocks
umgeschaltet werden soll.
Bitwurschtler schrieb:> Nimm einen clock multiplexer bspw. in Xilinx-FPGA#s typischerweise einen> BUFGMUX> http://www.ue.pwr.wroc.pl/pld/pld_10.pdf S.33
Genau so etwas brauche ich, wie auf S. 34 dargestellt.
Wenn ich nicht auf diese fertigen Module zurückgreifen kann, weil die
Technologie noch nicht klar ist. Ist es möglich so etwas in VHDL zu
beschreiben, oder muss ich immer erst die Technologie klären und dann
spezifische Module des Herstellers verwenden?
Denn in VHDL ist mir aktuell unklar, wie die erste Flanke des neuen
Taktes unterdrückt werden kann. Das muss ja dann sicher auf asynchrone
Logik hinauslaufen.
Vielen Dank!
Marc M. schrieb:> Wenn ich nicht auf diese fertigen Module zurückgreifen kann, weil die> Technologie noch nicht klar ist. Ist es möglich so etwas in VHDL zu> beschreiben,
Nein, zumindest nicht synthetisierbar.
> oder muss ich immer erst die Technologie klären und dann> spezifische Module des Herstellers verwenden?
Ja.
Alternativ kannst du einen neuen hohen (mindestens 20 MHz Besser 100+)
System-Takt einführen und die niedrigen Takte/Daten darauf
einsynchronisiern und nachbilden.
Marc M. schrieb:> Lattice User schrieb:>> http://www.vlsi-world.com/content/view/64/47/1/1/>> Vielen Dank!> Das sieht gut aus, leider funktioniert das nur, wenn select nicht auch> einen der beiden Takte abschaltet :)
Statemachine drumrum basteln die dafür sorgt dass während des
Umschaltens beide Clocks aktiv sind.
Inaktiven Oscillator einschalten.
Warten bis stabil. (feste Verzögerung oder bei PLL auf Lock warten)
Mux Umschalten
paar Takte Verzögerung um sicherzustellen dass der Muc fertig ist.
bisherigen Oscillator abschalten.
Getaktet wird das genze mit dem Ausgang des Mux, kommt also ohne
Hilfsclock aus.
Marc M. schrieb:> Denn in VHDL ist mir aktuell unklar, wie die erste Flanke des neuen> Taktes unterdrückt werden kann. Das muss ja dann sicher auf asynchrone> Logik hinauslaufen.
Garnicht. Der Takt liegt an oder er liegt nicht an. Man kann ihn gaten,
sollte man aber nicht. Wenn eine Schaltung bei einem Takt nichts tun
soll, gibt es enables.
Würde mich wundern, wenn das Fehlerfrei geht.
Bedingt durch den Umschaltvorgang erzeugst Du - nach Murphy - Signale,
wo keine sind und unterdrückst Signale, die da sein sollten.
Irgendwie liegt das in der Natur der Asynchronität.
Übrigens ein einfaches 08/14-Beispiel.
Zustand auf den Signalleitungen: Nix los.
Signal 1: Ist gerade so richtig schön high.
Signal 2: Ist aber völlig duun.
Schaltest Du in dieser Situation um, so erzeugst Du, allein durch das
Umschalten low/high- bzw. high/low-Flanken...
Sebastian S. schrieb:> Würde mich wundern, wenn das Fehlerfrei geht.> Bedingt durch den Umschaltvorgang erzeugst Du - nach Murphy - Signale,> wo keine sind und unterdrückst Signale, die da sein sollten.> Irgendwie liegt das in der Natur der Asynchronität.
Die Buffer lösen das Problem nur scheinbar. So richtig kann man Takte
nur "offline" umschalten und muss danach die angehängten Schaltungen
(re)setten oder muss die Daten ignorieren.
Marc M. schrieb:> CLK_IN_1 liegt im Bereich 1MHz> CLK_IN_2 liegt im Bereich 2-8MHz
Sind das wirklich richtige, waschechte Takte?
Oder sind das nur simple asynchrone Signale, die zufällig "Clock" im
Namen tragen (wie z.B. SCLK beim SPI oder SCL beim I²C)?
Marc M. schrieb:> ich muss/möchte zwei komplett zueinander asynchrone Takte multiplexen
Auf welcher Plattform? FPGA? CPLD? Diskrete Logik?
Marc M. schrieb:> Ist es möglich so etwas in VHDL zu beschreiben
Nein.
Oder doch, ja, es ist durchaus möglich, das in VHDL zu beschreiben.
Allerdings wird das der Snthesizer nicht in Hardware abbilden könnnen,
weil er es nicht erkennt, dass es da eine fertige Hardwarekomponente
dafür gibt.
Du kannst z.B. auch einen kompletten Slice in VHDL beschreiben. Der wird
dann tun, was ein Slice so tut, aber er wird viele, viele Slices dafür
brauchen. Denn der Synthesizer erkennt nicht, dass die gesamte
Beschreibung in einen Slice hineinpassen würde...
Chriss X. schrieb:> z.B. 100MHz FPGA-CLK einführen...> Und Deine beiden Niederfrequenten :-) Clocks einfach als Signal> einsyncronisieren...
und damit kräftig Strom verbraten und ordnentlich Bandbreite machen.
Zudem zerstörst Du damit jede Phaseninformation und die wird mitunter
benötigt.
Sowas macht man nur, wenn es nicht anders geht.
Und oft geht es schon deshalb nicht, weil die Takte zu schnell sind.
8 MHz sind - Entschuldigung - keine Takte, sondern mäßig schnelle
enables.
