Forum: Mikrocontroller und Digitale Elektronik Frequenzumsetzer 1000 : 999


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Der Retter der Nation (Gast)


Lesenswert?

Wie baue ich digital einen Frequenzumsetzer von 1000 : 999 der für 60MHz 
funktioniert? Gibt es dafür Bauteile?

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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

von Troll Alarm (Gast)


Lesenswert?

Ein PLL der Sorte ADF4001 sollte das koennen, durch 999 teilen und mit 
1000 multiplizieren.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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.

von Der Retter (Gast)


Lesenswert?

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!

von Georg G. (df2au)


Lesenswert?

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

von :-) (Gast)


Lesenswert?

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...

von Falk B. (falk)


Lesenswert?

@ 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.

von Falk B. (falk)


Lesenswert?

@ (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.

von Quelle (Gast)


Lesenswert?

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.

von Troll Alarm (Gast)


Lesenswert?

>Das gibt aber mehr als 60MHz.

... Muahhhh ... dann eben anders herum. Als VCO zB einen ROS100 oder 
aehnlich

von Uwe (Gast)


Lesenswert?

Eigentlich will der TO ja zwei synchrone Takte aus zwei Quarzen 
generieren ...

von Falk B. (falk)


Lesenswert?

@ 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

von Uwe (Gast)


Lesenswert?

> 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.

von Sabine (Gast)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von Der Retter nochmal (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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
von Uwe (Gast)


Lesenswert?

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).

von Georg G. (df2au)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Der Retter der Nation (Gast)


Lesenswert?

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.

von Uwe (Gast)


Lesenswert?

> 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.

von Peter D. (peda)


Lesenswert?

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.

von Der Retter der Nation (Gast)


Lesenswert?

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,

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Der Retter der Nation (Gast)


Lesenswert?

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!!!

von Der Retter der Nation (Gast)


Lesenswert?

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 :-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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.

von Sabine (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

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 :-)

von Guest (Gast)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Der Retter der Nation (Gast)


Lesenswert?

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.

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
Noch kein Account? Hier anmelden.