Announcement: there is an English version of this forum on Wie baue ich digital einen Frequenzumsetzer von 1000 : 999 der für 60MHz funktioniert? Gibt es dafür Bauteile?
Schmalbandig oder breiter? Also aus 60 MHz sollen (60MHz-60kHz) werden, ohne dass auch die Summe (60MHz+60kHz) entsteht. Durch einfache Mischung der beiden Frequenzen, z.B. mit einem Diodenringmischer entsteht nämlich zu gleichen Teilen Summen- und Differenzfrequenz. Man kann das mittels "Einseitenbanderzeugung nach der Phasenmethode" erreichen. Dazu braucht man aber zwei 90Grad-Phasenschieber, und sowas ist auf einfache Art nur für eine Frequenz machbar. Eine Methode wäre natürlich auch, die 60 MHz zu ver-999-fachen und dann durch tausend zu teilen - das wird aber zwischendurch sehr hochfrequent. Einen PLL-Oszillator auf die Frequenz einzurasten wäre noch eine realistischere Methode.
Der Retter der Nation schrieb: > Wie baue ich digital einen Frequenzumsetzer von 1000 : 999 der für 60MHz > funktioniert? Kommt drauf an. Reicht es, wenn im Ausgangssignal einfach jeder 1000ste Impuls fehlt (an der Stelle ist dann halt eine längere Pause). Oder muß das Ausgangssignal entsprechend zeitlich gestreckt sein? Ist die Eingangsfrequenz fest oder variabel; und wenn variabel, dann in welchem Bereich? XL
Ein PLL der Sorte ADF4001 sollte das koennen, durch 999 teilen und mit 1000 multiplizieren.
Axel spricht von "binary rate multiplier", die machen das mit Impuls-verschlucken. TTL SN7497 hatte sowas, aber nur von 63:64 bis 1:64 und nur bis ca. 20 MHz oder noch weniger. Das kann man heute natürlich in einem CPLD einbauen.
Das mit dem Mischen verstehe ich nicht, bzw nur grob. Ich brauche jeweils exakt 0,99900000 der Eingangsfrequenz und die liegt bei ungefähr 60MHz, was der Quarz halt macht. Impulse verschlucken geht nicht wegen Jitter. >Ein PLL der Sorte ADF4001 sollte das koennen, durch 999 teilen und mit 1000 multiplizieren. Sehr gut, genau sowas suche ich. Ich mache das im FPGA und kann dort zwar runter auf 60MHz/999 aber nicht mehr hoch. Das sehe ich mir an, Danke!
Der Retter schrieb: > Das mit dem Mischen verstehe ich nicht 60MHz macht der Quarz. Den durch 1000 teilen. Macht 60kHz. Nun hast du zwei Möglichkeiten: 1.) Beide Frequenzen auf einen Ringmischer geben. Der erzeugt 60.060MHz und 59.940MHz. Die 60.060MHz kannst du mit einem Quarzfilter abtrennen. Bleibt deine gesuchte Frequenz. 2.) Beide Frequenzen um 90° in der Phase schieben. Mittels zweier Mischer (schnelle 4053 reichen aus, nichts hochtouriges notwendig) und einer Addition bekommst du die gewünschte Frequenz. Siehe auch https://de.wikipedia.org/wiki/Einseitenbandmodulation
Der Retter schrieb: > jeweils exakt 0,99900000 der Eingangsfrequenz und die liegt bei ungefähr > 60MHz, was der Quarz halt macht. Nimm nen Dre-C an den Quarz und zieh ihn...
@ Der Retter (Gast) >Das mit dem Mischen verstehe ich nicht, bzw nur grob. Ich brauche >jeweils exakt 0,99900000 der Eingangsfrequenz und die liegt bei ungefähr >60MHz, was der Quarz halt macht. Also baucht du knapp unter 60 MHz. >>Ein PLL der Sorte ADF4001 sollte das koennen, durch 999 teilen und mit >1000 multiplizieren. >Sehr gut, genau sowas suche ich. Ich mache das im FPGA und kann dort >zwar runter auf 60MHz/999 aber nicht mehr hoch. Wenn es jitterarm sein soll, kommt man um einen guten VCO bzw. VCXO nicht herum. Der Rest ist die PLL-Standardlösung.
@ (Gast) >> jeweils exakt 0,99900000 der Eingangsfrequenz und die liegt bei ungefähr >> 60MHz, was der Quarz halt macht. >Nimm nen Dre-C an den Quarz und zieh ihn... Dann musst du aber schon FESTE ziehen, um einen Quarz 1000ppm zu verstimmen. Normalerweise geht das nur bis +/-200ppm oder so.
Falk Brunner schrieb: > Also baucht du knapp unter 60 MHz. > >>>Ein PLL der Sorte ADF4001 sollte das koennen, durch 999 teilen und mit >>1000 multiplizieren. Das gibt aber mehr als 60MHz.
>Das gibt aber mehr als 60MHz.
... Muahhhh ... dann eben anders herum. Als VCO zB einen ROS100 oder
aehnlich
Eigentlich will der TO ja zwei synchrone Takte aus zwei Quarzen generieren ...
@ Uwe (Gast) >Eigentlich will der TO ja zwei synchrone Takte aus zwei Quarzen >generieren ... Mit einer PLL, und der zweite Quarz ist dann halt ein VCXO, voltage controlled crystal oscillator
> Mit einer PLL, und der zweite Quarz ist dann halt ein VCXO, voltage > controlled crystal oscillator Und der VCO wird von der PLL nachgeregelt, jupp sollte gehen.
Sowas habe ich ja auch schon vorgeschlagen, nur scheut sich der Thread-Starter anscheinend die beiden Geräte, die er synchron haben will, irgendwie zu koppeln. Aber auch mit einer 999:1000-Frequenzanpassung der Frequenz des einen Geräten an das andere wird er es ohne Kopplung doch nie ganz synchron bekommen, weil die beiden Quarze doch nie ganz gleich laufen werden, oder?
Sabine schrieb: > die beiden Geräte, die er synchron haben will Das sind Komponenten in einem FPGA: Beitrag "2 FPGA - Clocks gewaltsam synchronisieren" Ich weiß auch nicht, warum das hier so geheim ist...
Nein, es sind zwei Bauguppen! Ich kann halt nur entweder den Quarz der zweiten Baugruppe hinhinziehen oder gänzlich runternehmen und den Takt von Aussen zuführen. Es geht jetzt darum auf meiner Baugruppe einfach die Quarzfrequenz von 60,000 MHz mit 0,999 auszugeben. Dann rennt die anderen minimal zu langsam, abarbeitet meine Daten aber exakt korrekt.
Der Retter nochmal schrieb: > Es geht jetzt darum auf meiner Baugruppe einfach die Quarzfrequenz von > 60,000 MHz mit 0,999 auszugeben. Dann rennt die anderen minimal zu > langsam, abarbeitet meine Daten aber exakt korrekt. Wie bitte? Also, Wenn du zwei Takte hast, die sich marginal (um 1 Promille) in ihrer Frequenz unterscheiden, dann werden fast ALLE Signale, die synchron zum einen Takt sind, herzlich unsynchron zum anderen Takt sein. Wie willst du dann mit einem unsynchronen Takt deine Daten verarbeiten? Ich nehme mal an, du meinst etwas ganz, ganz anderes, nämlich, wie man es hinbekommt, daß die Phasen zweier gleichfrequenter Takte sich marginal unterscheiden, damit der zweite mit seiner Flanke dann kommt, wenn die Daten vom ersten nach der Flanke des ersten bereits eingeschwungen sind - oder? W.S.
Jetzt habe ich kapiert, was hier passieren soll! Wenn ich diesen Beitrag des TE lese, dann geht es eher darum, die andere Baugruppe wieder ins Lot zu rücken, weil bei der nämlich ganz offensichtlich mit der Frequenz getrickst wurde! Wenn dort wirklich, wie angegeben, 64kHz+ rauskommen, kann die logischerweise nicht synchron Daten verarbeiten, die vorne mit echten 64kHz produziert werden. Die Idee, das einfach zurückzudrehen, ist an sich genau richtig, ist aber an die Forderung gekoppelt, dass beide Baugruppen mit ein und demselben Quarz laufen müssen (und nicht etwa zweien!) und die Folgegruppe mit einem gefakten Takt gesteuert wird. Ich habe in dem dortigen thread einen Beitrag geschrieben, wie man das machen könnte und zwar direkt aus dem FPGA, ohne Zusatzbaustein. Beitrag "Re: FPGA - Clocks gewaltfrei synchronisieren" Mal davon ausgehend, dass die Zahlen stimmen (müsste sich im design ja ermitteln lassen) brauchst Du nur die dynamische Ausgangsverzögerung der FPGAs permanent in einer Art Vorwärtsrotation anzupassen, um die Frequenz um 1 Promille abzusenken. Hat Dein FPGA IO-Delay-Blöcke? W.S. schrieb: > daß die Phasen zweier gleichfrequenter Takte sich > marginal unterscheiden, damit der zweite mit seiner Flanke dann kommt, > wenn die Daten vom ersten nach der Flanke des ersten bereits Das wird nix werden, fürchte ich. Der Jitter bleibt und zwar der von zwei PLLs. Es braucht in jedem Fall ein asynchrones FIFO zur Datenübergabe, das aber liefe nun nicht mehr leer. Eigentlich ist die Aufgabe doch letztlich nichts anderes, als die zweite Baugruppe auf den Datentakt der ersten zu synchen und zwar unabhängig vom Quarz. Das Problem ist hier nur, dass die FPGA-PLLs eine Mindestfrequenz haben und sich nicht auf 60kHz synchronisieren können. Für den Fall hätte ich zwar auch eine autoadaptive Lösung, nur jittert die halt wieder mehr und ist nicht wirklich viel besser, als die synchrone LÖsung mit dem klassischen Eintakten.
:
Bearbeitet durch User
Also geht es tatsächlich nur darum das ein FIFO nicht leerläuft bzw. überläuft, also Datenrate. Und nicht um eine Synchrone Datenübertragung mit 2 Taktdomänen (was so nicht geht).
Nachtrag zur Erzeugung der 999/1000 per "SSB". Wenn du als Master Oszillator die vierfache Frequenz nimmst, kannst du voll digital arbeiten. Dann sind die 90° Phasendrehung simpel. Der Mischer ist ohnehin digital. Aber etas Aufwand ist es dennoch.
Uwe schrieb: > Also geht es tatsächlich nur darum das ein FIFO nicht leerläuft bzw. > überläuft, Aber genau eines davon muss passieren, wenn nicht zusätzlich noch irgendein Handshake mit eingebaut ist.
Um die Schnittstelle zwischen den Baugruppen mache ich mir keine Sorgen. Die ist bei dezentralen Geräten ohnehin asynchron. Die 64kHz werden dabei in einen kleinen Puffer geschrieben und optisch / galvanisch entkoppelt über ein Schiebregister übertragen. Es geht wirklich um die Datenrate und den geringen Jitter in dem Fall, dass die Baugrupppen direkt gekoppelt werden müssen, die zweite quasi als Sender / Receiver für die ersten läuft. Es wäre ein Risenproblem, wenn die eine langsam der anderen wegrennt, weil die zeitlich exakt gesendeten / Empfangenen Daten nicht zur den Erzeugten passen würden und automatisch irgendwo ein Riss wäre. Die Baugruppen müssen im grossen und Ganzen synchron arbeiten.
> Die ist bei dezentralen Geräten ohnehin asynchron.
Kann man da vieleicht nen Synch frame in bestimmten Abständen in den
Datenstrom reinpacken wenn die Übertragung eh Asynchron erfolgt.
Der Retter der Nation schrieb: > Die Baugruppen müssen im grossen und Ganzen synchron arbeiten. Na dann versorge doch beide mit dem selben Takt und der eine hat nen Teiler 1000:1 der beim Überlauf eine Taktperiode wegtort. Wenn beide einen eigenen Quarz haben, rennen sie trotzdem auseinander, dauert nur länger. Es muß das selbe Taktsignal für beide sein.
Das mit den Takten ist geklärt, daher der Umsetzer. Das muss kontinuierlich laufen. Mit Wegwerfen ist nichts, weil es nichts wegzuwerfen gibt. Ich müsste mit 64kHz alle 1000 Perioden zwei Daten erzeugen um den Sender permanent füttern zu können. Daher macht auch das Synchen keinen Sinn,
Der Retter der Nation schrieb: > Um die Schnittstelle zwischen den Baugruppen mache ich mir keine Sorgen. > Die ist bei dezentralen Geräten ohnehin asynchron. Aber dann muss irgendeine Art von Handshake her. Oder es müssen mehr Daten als benötigt angeliefert werden und die überzähligen verworfen werden dürfen... > Mit Wegwerfen ist nichts, weil es nichts wegzuwerfen gibt. Das kommt darauf an, welche der beiden Komponenten wie schnell läuft. Wo ist eigentlich das Problem, wenn beide gleich schnell laufen? Wenn du also in der einen Komponenete genau gleich viele Daten produzierst, wie du in der Anderen brauchst? Entweder machst du ein Problem wo keines ist, oder du weißt mehr als wir. Oder kommt es nur mir so vor, als ob sich die Diskussion im Kreis dreht?
Vielleicht solltest du dich mal mehr mit deinen Kollegen unterhalten, als hier alle Leute raten zu lassen ! Du schreibst es existiert schon eine Seite und du möchtest (darfst, kannst) daran nicht ändern also benutze die Schnittstelle die angeboten wird. Wenn du uns diese Schnittstelle beschreibst können wir dir vielleicht auch helfen.
Lothar Miller schrieb: > Der Retter der Nation schrieb: >> Mit Wegwerfen ist nichts, weil es nichts wegzuwerfen gibt. > Das kommt darauf an, welche der beiden Komponenten wie schnell läuft. Das hatte ich in dem anderen Beitragsstrang geschrieben, den Du zugemacht hast: Die zweite Baugruppe läuft im Mittel um 1 Promille zu schnell. > Wo ist eigentlich das Problem, wenn beide gleich schnell laufen? Gar keins :-) > Wenn du also in der einen Komponenete genau gleich viele Daten > produzierst wie du in der Anderen brauchst? das ist das Ziel!!!
Hans-Georg Lehnard schrieb: > Vielleicht solltest du dich mal mehr mit deinen Kollegen unterhalten, > als hier alle Leute raten zu lassen ! Ich hatte die Problematik ja bereits in dem anderen thread erörtert. Hier hatte ich lediglich nachgefragt, wie man den benötigten Umsetzer baut. Und jetzt gehe ich in die Kantine und frage die Kollegen, damit Du beruhigt bist :-)
Der Retter der Nation schrieb: > Das hatte ich in dem anderen Beitragsstrang geschrieben, den Du > zugemacht hast: Die zweite Baugruppe läuft im Mittel um 1 Promille zu > schnell. Dann mach sie langsamer. Ein Klimaschrank könnte dir dabei helfen... > Das hatte ich in dem anderen Beitragsstrang geschrieben, den Du > zugemacht hast Klar habe ich den zugemacht. Genau deshalb: > Ich hatte die Problematik ja bereits in dem anderen thread erörtert. Nicht jeder weiß, dass du die selbe Suppe in zwei Threads aufkochst.
Um Informationen aus dem anderen Thread hier mal zu notieren: Du hast zwei Baugruppen mit FPGAs drauf, die miteinander über einen Bus verbunden sind. Die eine Baugruppe ist schon fertig und sollte im besten Fall nicht mehr angegriffen werden. Beide Baugruppen laufen mit einem Takt von 60MHz. Der Bus überträgt Daten jedoch mit 60kHz. Was interessant wäre: Wie sieht der Bus aus? Ist dieser asynchron in dem Sinne, dass es kein SCLK-Signal gibt? Wenn ja, dann muss es ja irgendwelche Synchronisierungsmaßnahmen geben wie zB bei UART oder anderen asynchronen Bussystemen ala Start-Of-Frame(SOF). Wenn du von 60kHz sprichst, meinst du damit, dass wenn die Daten ein alternierendes Muster wären, dieses Rechtecksignal 60kHz hat? Hast du einen permanenten Datenstrom und keine Clock? Wenn es eine Clock gibt: Wer gibt diese vor? In welche Richtung läuft die Kommunikation? Mit diesen zusätzlichen Informationen könnte man dir leichter helfen.
Dein Teil bekommt die Daten von der anderen Schaltung? Dann mach es doch so wie die Bahnhofsuhren, mach dein Teil um 2 Promille schneller und lass dein Teil immer kurz warten.
Sabine schrieb: > Dann mach es doch so wie die Bahnhofsuhren, mach dein Teil um 2 Promille > schneller und lass dein Teil immer kurz warten. Wusst ichs doch: wir drehen uns im Kreis! Meine Rede von vor 4 Tagen: Beitrag "Re: 2 FPGA - Clocks gewaltsam synchronisieren" Ich bin gespannt, was die Kollegen beim Essen zum Thema zu sagen hatten... ;-)
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
pseudo-pll-in-fpga.gif
30 KB
Der Retter der Nation schrieb: > Die zweite Baugruppe läuft im Mittel um 1 Promille zu schnell Nicht ganz! Sie läuft Deinen Angaben zufolge um 1/0,999 zu schnell. Das sind 1,001001 pro Mille. Das Problem ist doch eigentlich längst geklärt, wobei ich Hans Georg zustimme, dass Du das etwas transparenter hättest erklären können. Ich mache mir in solchen Fällen ein Excel, in dem ich alle Taktdomänen und Frequenzen aufzeichne und die Daten aufs part per million berechnen lasse. Daraus kann man dann Struktur und Timing erkennen. Mathematisch formuliert passiert Folgendes: In Deinem Design: 60 MHz auf 64kHz und parallel dazu nochmal 60 MHz auf 0,999 x 60 MHz = 59,9 irgendwas. Im fremden Design: nominell 60 MHz auf 64,064064 kHz durch den falschen Takt aber jetzt: 64,064 * 0,999 = 64kHz Nun musst Du nur noch dafür sorgen, dass bei den Taktflanken nichts schief geht, denn die Taktdomänen passen ja nicht mehr zueinander auch wenn sie aus demselben Quarz kommen. Die ehemaligen 96MHz im zweiten Design sind jetzt irgendwas um die 95,9. Je nachdem, wann die Zähler mit denen händisch geteilt wird, um die 64kHzen zu erzeugen, auf Null gestellt wurden, stehen die 64kHz-"Flanken" in einem festen Phasenverhältnis zueinander, das irgendwie steht, sich aber nicht mehr ändert. Damit hast Du den Datentakt synchron. Die Clockflanken laufen aber jetzt permanent gegeneinander und treffen sich alle 999/1000 Taktzyklen +/- den jeweils aktuellen Jitter der Takte. Wie ich schon geschrieben habe, braucht es ein aynchrones FIFO. Da man in dem anderen Thema nicht mehr schreiben kann, noch diese Antwort: Der Retter der Nation schrieb: > Jürgen Schuhmacher schrieb: >> Die Frequenz digital zu modulieren > Ich habe mir Deine Seite angesehen, muss aber sagen, dass ich es nicht > zu 100% verstehe. Wie garantiere ich, dass dort ganz genau 1 Promille > (und ich meine ganz exakt 1 Promille) weniger Frequenz rauskommt? Indem Du diese gesamte Taktmimik mit einem Zähler antreibst, der von Deinem Quelltakt gespeist wird. Damit ist das erzwungenermaßen synchron. Die Geschichte ist doch die, dass Du mit jedem programmierten Zählerdurchlauf einen kompletten Takt springst. Dies wäre in Deinem Fall bei jedem 1000sten. Ohne weitere Aktionen hättest Du denselben Effekt, wie beim Einsynchronisieren: Einen springenden Datentakt bei dem irgendwann ein Datum weg ist oder nicht geliefert wird. Der Trick mit dem Multiplexer ist nun der, diesen Sprung auf dem Weg dorthin fein gestückelt ablaufen zu lassen. > Die Verzögerungen im FPGA, die sich durch Delays und lookup-Tabellen > machen lassen, sind doch niemals so genau zu timen. Richtig, aber sie dienen ja auch nur dazu, die Sprünge zu verteilen. Wenn es nicht gelingt, eine ideale Delaykonfiguration zu finden, wird es dazu führen, dass die Verschiebung etwas ungleichmässig wird. Der letzte Sprung ist dann schlechteste, denn der geht ja ins Leere, weil wieder auf Null gestellt wird und damit wieder die Originalflanke gilt. Die kommt halt dann nicht equidistant. Dadurch wird der grösste lokale Jitter erzeugt, den ich beschrieben hatte und den man berücksichtigen muss. Wenn Du das mildern willst, nimmst Du einfach mehrere kürzere Delays und taktest sie entsprechend schneller durch. Z.B. könntest Du manuell 32 Delays mit 31 Takten fahren, sodass 31 x D = 1/1000 T. Je feiner, desto besser. In Deinem Fall geht das sehr einfach, weil Du ein ganzzahliges Verhältnis hast. Wenn das nicht geht, musst Du die Verschiebung variabel regeln, wie ich das bei meiner analogen PLL mache. Erklärung und Beispiel hier: http://www.96khz.org/oldpages/analogpldsynthesizer.htm Jetzt müsste die Nation gerettet sein :-)
Blöde Frage aber wieso lockst du nicht einfach die PLL (DCM) in deinem FPGA auf die 60MHz? Dann laufen die beiden Module gleich schnell und alles funktioniert einfach?
Guest schrieb: > Blöde Frage aber wieso lockst du nicht einfach die PLL (DCM) in deinem > FPGA auf die 60MHz? Weil (das steht im anderen Thread) kein (richtiger) Zugriff auf diese Baugruppen besteht...
Guest schrieb: > Blöde Frage aber wieso lockst du nicht einfach die PLL (DCM) in deinem > FPGA auf die 60MHz? Dann laufen die beiden Module gleich schnell und > alles funktioniert einfach? Nee, eben nicht. Das ist ja des Problem an dem der TE rumeiert: Er hat gedacht, er kann die Baugruppen einfach zusammenhängen, weil die Taktfrequenzen der Quarze stimmen und auch die Takte seines niederfrequenten Ausgangs passen. Das tun sie aber nich, weil die andere Schaltung anders runterteilt und minmal was anderes rausbekommt. Also muss er an der PLL drehen, dummerweise eben sehr wenig. Viel drehen, wäre wahrscheinlich einfacher.
Jürgen S. schrieb: > Er hat gedacht, er kann die Baugruppen einfach zusammenhängen, weil die > Taktfrequenzen der Quarze stimmen und auch die Takte seines > niederfrequenten Ausgangs passen. Genau genommen, hat mein "Vorarbeiter" das sich so gedacht und jetzt das Problem, dass es wohl auf ein redesign hinausläuft, weil ein zusätzlicher Chip ins Spiel kommt. Das bedeutet mehr Platzbedarf, mehr Kosten und vor allem Überschreitung des Zieltermins. Wenigstens bin ich jetzt aus dem Schneider, weil es nicht an mir liegt ;. Ich hatte darauf hingewiesen, dass es eine Lösung nur mit FPGA gibt, aber auch die hätte einen Umbau bedeutet. Ist eben toll, wenn ganze Batterien von Systemen von Leuten geplant werden, die es nicht drauf haben. Der Planer ist übrigens weg und plant in einer anderen Firma.
Thread beobachten
Seitenaufteilung abschalten
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.