Hallo Leute! Ich suche einen Weg, eine beliebige Frequenz zwischen 0.1 MHz und 100 MHz (die einstellbar und bekannt ist) durch 1000 (nicht 1024) zu teilen. Optional wären auch mehrere Teilungen z.B. durch 10 hintereinander möglich. Wichtig ist mir jedoch dabei, dass kein Jitter entsteht. Verzögerung zw. Eingang und Ausgang darf entstehen. Ist sowas mit FPGA/CPLD machbar, oder gibt es gar spezielle ICs bzw. muss ich da etwas im Analogbereich suchen? Danke im Voraus! Grüße Anguel
Anguel S. schrieb: > Optional wären auch mehrere Teilungen z.B. durch 10 hintereinander > möglich. Wichtig ist mir jedoch dabei, dass kein Jitter entsteht. 74ac390 2x :10 Teiler schafft 160MHz, es wrid erst durch 5 und dann noch mal durch 2 geteilt. Genau so würde ich es in einem CPLD z.B. XC9536XL machen.
Jedes aktuelle CPLD kann diese Aufgabe erledigen. Aber "kein Jitter" gibt es nicht! Mit keiner heute verfügbaren Technologie wird ein Jitter von 0 fs oder gar 0 as erreicht. Hier muss ein verbindlicher Wert z.B. in ps her.
Ihr seid echt super! Vielen Dank für die Tipps - ich werde mir beide Möglichkeiten genauer ansehen. Ich werde auch nochmal nachschauen, wieviele ps Jitter noch akzeptabel sind. P.S: Ich war schon länger nicht mehr hier im Forum, bin aber sehr positiv überrascht, dass genauso wie früher so schnell so kompetente Antworten kommen. Danke!
Also die 74ac390 scheinen abgekündigt zu sein und ich denke, dass eine CPLD-Lösung sowieso flexibler wäre, wenn sie einmal funktioniert. Gibt es eigentlich einen technischen Vorteil, dass ich ein CPLD verwenden soll und keinen FPGA, oder ist FPGA in diesem Fall einfach Overkill? Zum Jitter: So bis 10 ps Jitter wären noch akzeptabel, aber je kleiner desto besser. Ich habe mal die Datasheets zum XC9536 angeschaut, habe aber keine Angaben zum Thema Jitter gesehen :-( In welchem Bereich liegt er? Ich würde dann so vorgehen, dass ich das CPLD mit der Eingangsfrequenz takte und dann einen Zähler in VHDL implementiere. Muss ich etwas Spezielles bei Wechsel der Taktfrequenz beachten? Wahrscheinlich wäre ein Reset vor Frequenzwechsel sinnvoll. Muss ich beim Routing noch etwas beachten? Habe bis jetzt nur mit FPGAs gearbeitet und weiß leider nicht, ob es bei CPLDs spezielle Tricks gibt... Danke nochmals für die Hilfe!
Anguel S. schrieb: > oder ist FPGA in diesem Fall einfach Overkill? Ja. > So bis 10 ps Jitter wären noch akzeptabel Und 10ps sind schon recht sportlich. Was für einen Takt hast du da? Bekommst du die 10ps auf der Platine überhaupt ans Ziel? Ich könnte mir auch vorstellen, dass du das Teilen und das Synchronisisieren zwei verschiedenen Bausteinen überlässt: Teilen tut das CPLD, für den geringen Jitter sorgt ein nachgeschaltetes diskretes Flipflop. Dann ist "nur" das letzte Flipflop für den eigentlichen Jitter verantwortlich... > Wahrscheinlich wäre ein Reset vor Frequenzwechsel sinnvoll. Jeden unnötigen Schmarrn solltest du weglassen. Wenn die Schaltung drumrum mit dem Frequenzwechsel klarkommt dann schafft es auch das CPLD. > Muss ich beim Routing noch etwas beachten? Eher beim Layout. Die Versorgung nicht richtig entkoppelt und schon klemmt der Laden und jittert wie blöd...
Wenn du ein CPLD nimmst, kannst du das ja direkt mit der Eingangsfrequenz takten, dann einen synchronen Zähler, der bis 499 zählt und beim Überlauf den Ausgang toggelt. Dafür brauchts keinen Reset, weil keine PLL oder DCM beteiligt ist. Allerdings bekommst du dann zwangläufig Jitter rein, mit 10ps ist bei normalen CPLD/FPGA schon haarig.
Als Leistungselektroniker der sich sonst im 2 stelligen kHz Bereich bewegt: Kann mir jemand sagen warum bei fmax 100MHz also 10ns kürzester Periodendauer 10ps Jitter benötigt werden? Das ist ein Phasenfehler <0.1% grüssle Hauspapa
Lothar Miller schrieb: > Bekommst du die 10ps auf der Platine überhaupt ans Ziel? Die Endstufe hat ca. 10 - 30 ps Jitter, deshalb wollen wir, dass die Stufen vorher so wenig Jitter wie möglich haben. > Ich könnte mir auch vorstellen, dass du das Teilen und das > Synchronisisieren zwei verschiedenen Bausteinen überlässt: Teilen tut > das CPLD, für den geringen Jitter sorgt ein nachgeschaltetes diskretes > Flipflop. Dann ist "nur" das letzte Flipflop für den eigentlichen Jitter > verantwortlich... Das ist eine sehr gute Idee. Verstehe ich das richtig, dass das CPLD dann eine Art Enable-Signal für das externe FF liefern soll? @Christian: Danke für die Tipps. So wollte ich das machen und dazu das von Lothar vorgeschlagene externe FF. @Haupapa: Bei Lasern sind 10 ps Jitter schon extrem viel :-)
Anguel S. schrieb: > Verstehe ich das richtig, dass das CPLD > dann eine Art Enable-Signal für das externe FF liefern soll? Nein, das CPLD macht aus dem Eingangstakt einen "verjitterten" Takt, der dann mit dem zusätzlichen Flipflop über den "jitterfreien" Eingangstakt synchronisiert wird.
Lothar Miller schrieb: > Nein, das CPLD macht aus dem Eingangstakt einen "verjitterten" Takt, der > dann mit dem zusätzlichen Flipflop über den "jitterfreien" Eingangstakt > synchronisiert wird. Das heißt, dass ich dann den Takt, der aus dem CPLD kommt mit dem Dateneingang am FF verbinde, und das FF direkt aus dem Quelltakt takte? Komme ich dann mit den Setup- und Hold-Zeiten hin?
Anguel S. schrieb: > Komme ich dann mit den Setup- und Hold-Zeiten hin? Probiers einfach aus. Du kannst das CPLD bei Bedarf auch mit der negativen Flanke und das folgende Flipflop mit der steigenden Falnke takten, falls die Hold-Zeit nicht reicht. Dafür ist keine Layoutänderung nötig, denn dieses "Taktinvertieren" spielt sich ja im CPLD ab...
Lothar Miller schrieb: > Du kannst das CPLD bei Bedarf auch mit der negativen Flanke und das > folgende Flipflop mit der steigenden Falnke takten, falls die Hold-Zeit > nicht reicht. Besser nicht! Bei gleichen Flanken hat das Signal eine volle Taktperiode, um 'durchzuripplen' ;-)
Lothar Miller schrieb: > Anguel S. schrieb: > >> Verstehe ich das richtig, dass das CPLD > >> dann eine Art Enable-Signal für das externe FF liefern soll? > > Nein, das CPLD macht aus dem Eingangstakt einen "verjitterten" Takt, der > > dann mit dem zusätzlichen Flipflop über den "jitterfreien" Eingangstakt > > synchronisiert wird. So einfach geht das nicht. Der Takt ist aussen schneller und schaltet das FF durch, während das Hi noch nicht durch den PLD ist. Damit bekommt man einseitigen Jitter. Der Takt innen muss noch passend verschoben werden, damit das äussere FF auch tatsächlich die Flanken anschneidet und dann hat man ein d.c. Problem.
Dodi schrieb: > So einfach geht das nicht. Der Takt ist aussen schneller und schaltet > das FF durch, während das Hi noch nicht durch den PLD ist. So etwas hatte ich auch befürchtet aufgrund der internen Laufzeiten. > Damit bekommt man einseitigen Jitter. Du meinst, dass z.B. bei 100 MHz Eingangstakt, der geteilte Takt 10 ns später vom diskreten FF ausgegeben wird? > Der Takt innen muss noch passend verschoben > werden, damit das äussere FF auch tatsächlich die Flanken anschneidet > und dann hat man ein d.c. Problem. Was meinst Du mit d.c. Problem?
Dodi schrieb: > Der Takt ist aussen schneller und schaltet > das FF durch, während das Hi noch nicht durch den PLD ist. Ja, wenn man jetzt schon wüsste, wie lang die Leitung "aussen rum" ist... ;-) Willi schrieb: > Bei gleichen Flanken hat das Signal eine volle > Taktperiode, um 'durchzuripplen' ;-) Richtig, in der Regel wird das wirklich kein Problem darstellen, weil der Counter "durch" das CPLD z.B. 2 ns braucht, während das Taktsignal "aussenrum" für 2cm nur etwa 100ps braucht. Da ist also genug Hold-Zeit-Reserve, und danach ausreichend Setup-Zeit...
Angehängte Dateien:
-
taktteiler.gif
15 KB
Anguel S. schrieb: > Was meinst Du mit d.c. Problem? duty cycle >2ns Der Takt der aus dem PLD kommt, muss so verschoben sein, dass sich die Flanken nicht sehen
Ich denke, man müsste dann durch 10 Teilen!
Ich danke euch allen nochmals für die Hilfe und die guten Tipps! Werde mir das ganze nochmal genau anschauen und überlegen, wie ich das Problem am besten löse.
Anguel S. schrieb: > Die Endstufe hat ca. 10 - 30 ps Jitter, deshalb wollen wir, dass die > Stufen vorher so wenig Jitter wie möglich haben. "So wenig wie möglich" ist so unnötig wie teuer - oder so ähnlich...
Eine fast Einchip-Lösung wäre die Propeller-CPU. Ist sicherlich für einen nicht FPGA-affinen einfacher zu verstehen als sich in VHDL einzuarbeiten, 1GByte SDK downzuloaden usw.
@ Abdul K. (ehydra) Benutzerseite
>Eine fast Einchip-Lösung wäre die Propeller-CPU.
Klar, um drei popelige /10 Teiler zu ersetzen. Deine Vorschläge waren
auch schon mal besser. Deutlich besser.
Er wollte einen programmierbaren Teiler. Einfach durch 10 geht also nicht. Biete sowas doch als fertiges CPLD/FPGA an. Du siehst, es existiert ein Markt.
@ Abdul K. (ehydra) Benutzerseite >Er wollte einen programmierbaren Teiler. Nö. Der Eingangstakt ist variabel, der Teilerfaktor fest. Beitrag "Beliebige Frequenz zw. 0.1 MHz und 100 MHz durch 1000 teilen" > Einfach durch 10 geht also nicht. Und ob. Sogar noch einfacher und mit überall billigst verfügbaren ICs. 1x74AHC74 oder was auch immer für eine schnelle Familien, teilt 2x durch 2, bleibt Faktor 250 und 25MHz übrig. Das macht dann ein 74HC40103, der teilt durch 125. Am Ende das viel beschworende, jitterarme End-FlipFlop, teilt nochmal durch 2, fertig. Drei popelige CMOS-ICs für nicht mal einen Euro, nix CPLD, nix programmieren, nix High Tec. Schade. >Biete sowas doch als fertiges CPLD/FPGA an. Du siehst, es existiert ein >Markt. [ ] Du hast Ahnung von BWL.
Falk Brunner schrieb: > @ Abdul K. (ehydra) Benutzerseite > >>Er wollte einen programmierbaren Teiler. > > Nö. Der Eingangstakt ist variabel, der Teilerfaktor fest. Stimmt. Mußte es nochmal langsam lesen. >> Einfach durch 10 geht also nicht. > > Und ob. Sogar noch einfacher und mit überall billigst verfügbaren ICs. > einen Euro, nix CPLD, nix programmieren, nix High Tec. Schade. Ich muß gestehen, daß ich dachte diese Chips gäbe es gar nicht mehr komplett. War einfach zu faul, jetzt jeden der Verdächtigen abzuklappern. Wozu High-Tec? Meinst du, ich verwende immer die tollsten Sachen? Deine diskrete Lösung wird sicherlich weniger rauschen als wenn es auf einem komplexen Chip mit draufhockt. > >>Biete sowas doch als fertiges CPLD/FPGA an. Du siehst, es existiert ein >>Markt. > > [ ] Du hast Ahnung von BWL. Hätte ich Ahnung von BWL, hätte ich keine von Elektronik. Und wäre auch ganz sicher nicht Entwickler geworden. Es gibt einfachere Wege an Geld zu kommen. Jedenfalls kommt ziemlich oft die Frage nach einem 1000er Teiler. Deine aggressive Tour erinnert mich an MaWin. Probleme?
@ Abdul K. (ehydra) Benutzerseite
>Deine aggressive Tour erinnert mich an MaWin. Probleme?
Nö, aber es nervt wenn Leute, die es eigentlich besser könnten, völlig
belanglose, fast schon schwachsinnige Beiträge liefern. Propeller-CPU
für 1000:1 Teiler, 1G SDK downloaden, MARKT für 1000:1 Teiler etc. 8-(
Lothar Miller schrieb: > Jedes aktuelle CPLD kann diese Aufgabe erledigen. Dann warst Du es wohl, der das Forum gewechselt hat. Das hier hat doch aber alles nichts mit programmierbarer Logik zu tun. Auch ich würde stinknormale Zähler+FFs nehmen.
Kann man so sehen. Abundzu möchte ich einfach mal was neues einwerfen. Neue Wege aufzeigen. Ich glaube, das kommt immer dann wenn ich in der Fragestellung keine nennenswerte Höhe sehe. Tut mir leid. Du kriegst ein Malzbier, wenn wir uns mal sehen.
Willi schrieb: > Dann warst Du es wohl, der das Forum gewechselt hat. Keine Ahnung, was du meinst. Aber im Zweifelsfall: >>>> John wars... <<<< > Auch ich würde stinknormale Zähler+FFs nehmen. Ich nicht. Da liegen so viele CPLDs in der Schublade rum...
Lothar Miller schrieb: >> Auch ich würde stinknormale Zähler+FFs nehmen. > Ich nicht. Da liegen so viele CPLDs in der Schublade rum... Hab auch eine grössere Anzahl von XC9536-7 da (ohne XL). Wenn ich mal etwas mache was 2 oder gar 3 IC brauchen würde, oder ich habe einen bestimmen IC nicht da, greife ich auch mal schnell in die Kiste. Allerdings schaffen die offiziell keine 100MHz :-(
@ Abdul K. (ehydra) Benutzerseite >Kann man so sehen. Abundzu möchte ich einfach mal was neues einwerfen. >Neue Wege aufzeigen. Holzwege? Highway to hell? Fragen über Fragen ;-) >Ich glaube, das kommt immer dann wenn ich in der >Fragestellung keine nennenswerte Höhe sehe. Wenn dir langweilig ist, mach was anderes. >Tut mir leid. Du kriegst ein Malzbier, wenn wir uns mal sehen. Wie soll ich das runter kriegen? Die Farbe stimmt, aber ein bisschen Drehzahl muss schon sein ;-)
Falk Brunner schrieb: > Und ob. Sogar noch einfacher und mit überall billigst verfügbaren ICs. > 1x74AHC74 oder was auch immer für eine schnelle Familien, teilt 2x durch > 2, bleibt Faktor 250 und 25MHz übrig. Das macht dann ein 74HC40103, der > teilt durch 125. Am Ende das viel beschworende, jitterarme End-FlipFlop, > teilt nochmal durch 2, fertig. Drei popelige CMOS-ICs für nicht mal > einen Euro, nix CPLD, nix programmieren, nix High Tec. Schade. Danke :-) Das ist doch eine interessante Lösung!
Falk Brunner schrieb: > @ Abdul K. (ehydra) Benutzerseite > >>Kann man so sehen. Abundzu möchte ich einfach mal was neues einwerfen. >>Neue Wege aufzeigen. > > Holzwege? Highway to hell? Die Fragestellung war schon komisch. Wozu genau durch 1K teilen? Kann nur ein Physiker sein, der Gleitkommazahlen scheut. > > Fragen über Fragen ;-) > Danke, mir gehts blendend <meistens>. Man kennt mich als offenen Typ, also frage einfach. >>Ich glaube, das kommt immer dann wenn ich in der >>Fragestellung keine nennenswerte Höhe sehe. > > Wenn dir langweilig ist, mach was anderes. Ich mache das nebenbei. > >>Tut mir leid. Du kriegst ein Malzbier, wenn wir uns mal sehen. > > Wie soll ich das runter kriegen? Die Farbe stimmt, aber ein bisschen > Drehzahl muss schon sein ;-) Daran solls nicht scheitern. Ich kann dir noch einiges an Chemie mitbringen. Einfach reinkippen.
Abdul K. schrieb: > Daran solls nicht scheitern. Ich kann dir noch einiges an Chemie > mitbringen. Einfach reinkippen. Somit ist auch das Klischee bedient ;-)
Anguel S. schrieb: > Gibt > es eigentlich einen technischen Vorteil, dass ich ein CPLD verwenden > soll und keinen FPGA, oder ist FPGA in diesem Fall einfach Overkill? Nachteil CPLD: Fuer komplexe Sachen schnell zu klein Nachteile FPGA: - benoetigt meist mehrere Spannungen - benoetigt meist ein Konfigurationsprom - benoetigt meist mehr Leistung - komplexeres Timingmodel - teuerer als kleine CPLDs
pegel schrieb: > Abdul K. schrieb: >> Daran solls nicht scheitern. Ich kann dir noch einiges an Chemie >> mitbringen. Einfach reinkippen. > > Somit ist auch das Klischee bedient ;-) Was meinst du wie die Farbe reinkommt? Ich habe mal eine ganze Reihe verschiedener Malzbiere auf einmal gekauft und dann mit den anderen zuhause einen Blindtest gemacht. Das teuerste war auch das am besten bewertete. Richtig toll schmeckte aber keins. Ist hauptsächlich Leitungswasser und Zuckerkulör. Produktionskosten vielleicht 2 Cent.
Man hat den Eindruck, die Welt besteht nur noch aus CPLDs, FPGAs und obskuren Randgruppenprozessoren. Wenn der Jitter schon niedrig sein soll und noch programmierbar, nehmt doch gleich den Teiler eines PLL-Chips, zB. National LMX*. Bei den meisten Chips kann man den runtergeteilten Takt doch auch auf einen Testpin geben. Dann noch ein paar Bytes per I2C/SPI hinschicken und gut ist.
Leutz, wie kompliziert! Ein Spartan 3A von der 50er Sorte für 2,80 das Stück und ihr habt a) euren Teiler b) euer Spezial-Anti-Jitter-FF! Man braucht weder eine PLL noch sonstwas, wobei die im S3A auch noch zur Verfügung steht. Die Programmierbarkeit lässt sich durch eine Register-Bank und ein simples Interface bauen. Das Entjitter-FF bitte in eine eigene Bank mit guter Versorgung in Analogqualität, dann passt das! Im Schlimssten Fall vor den Takteingang noch ein Schmitt-Trigger, damit der Eingangstakt schlecht sein kann. Georg A. schrieb: > Man hat den Eindruck, die Welt besteht nur noch aus CPLDs, FPGAs und > > obskuren Randgruppenprozessoren. ist ja auch so
Wenn Entwicklungszeit keine Rolle spielt nimmt man ein CPLD, FPGA oder ein Propellergedöns für diesen Popelkram. Ansonsten eine diskrete Lösung mit Standard ICs. Im Ergebnis wird man keinen Unterschied feststellen.
Old School schrieb: > Wenn Entwicklungszeit keine Rolle spielt Ich schreibe dir die Lösung in 10 Minuten hin. Inklusive Simulation. Diese Aufgabe hier ist schliesslich einfacher als die Uhr da im Beitrag "Re: kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)" ;-)
Im Jitter schon! Aber weil das Gemecker so schön ist und niemand daran denkt, daß vielleicht andere diesen Thread finden werden und vielleicht eine andere Ausgangsbasis haben und damit andere Lösungen bevorzugen, hier noch einer: Teiler in halbanaloger Technik "Staircase". Damit Falk mit seinem liebevollen Statement zu meinen Fähigkeiten recht behält: http://www.techlib.com/files/dividers.pdf Er verkauft auch fertige Module.
Der Ingenieur schrieb: > Ein Spartan 3A von der 50er Sorte für 2,80 das Stück und ihr habt Wo bekommst Du eine Spartan 3A zu fuer 2,80. Bei Digikey faengt der Preis bei 6,27 an...
> Das Entjitter-FF bitte in eine eigene Bank mit guter Versorgung in > Analogqualität, dann passt das! Was ist denn das für ein Blödsinn? > Wo bekommst Du eine Spartan 3A zu fuer 2,80. Bei Digikey faengt der > Preis bei 6,27 an... Naja, ab 1000 Stück schon...
Georg A. schrieb: >> Das Entjitter-FF bitte in eine eigene Bank mit guter Versorgung in >> Analogqualität, dann passt das! > Was ist denn das für ein Blödsinn? Der Jitter kommt u.A. davon, dass die Versorgung (und damit die Schaltschwelle des Takteingangs) dieses Flipflops zappelt. Und deshalb muss dieses Flipflop ganz liebevoll umhegt werden: es darf nicht mit anderen Flipflops an der Versorgung zusammenhängen, das Layout und die Entkopplung sollte sehr gepflegt aussehen, usw...
@ Georg A. (georga) >> Das Entjitter-FF bitte in eine eigene Bank mit guter Versorgung in >> Analogqualität, dann passt das! >Was ist denn das für ein Blödsinn? Das ist kein Blödsinn sondern prinzipiell erstmal richtig. Dadurch, dass das FlipFlop am Ende eine eigene Versorgungsspannung erhält, wirken die Störungen auf VCC, welche durch den Rest der Schaltung erzeugt werden, nicht auf dieses, was u.a. die Schaltschwelle des FlipFlops beeinflußt. Damit wird nur wenig zusätzlicher Jitter erzeugt.
Da stand *ENT*jitter-FF. FFs können keinen Jitter entfernen, höchstens identisch durchlassen. Wer meint, dass es an einer wackeligen Schaltschwelle liegt, kann genausogut einen Inverter oder Buffer nehmen.
@ Georg A. (georga) >Da stand *ENT*jitter-FF. FFs können keinen Jitter entfernen, Doch. Der Dateneingang vom Zähler kann jittern, der Datenausgang jittert nur soviel wie der Takt. >>identisch durchlassen. Wer meint, dass es an einer wackeligen >>Schaltschwelle liegt, kann genausogut einen Inverter oder Buffer nehmen. Nein, den dort wirt der Jitter vom Eingang 1:1 am Ausgang. Beim FlipFlop aber nicht, dort wirkt nur der Taktjitter!
Georg A. schrieb: > FFs können keinen Jitter entfernen Naja, ich denke die Jungs wollen den Jitter des runtergeteilten Clock-Signals entfernen, und das geht sehr wohl. Propagiert wird (idealerweise) nur der Jitter des (schnellen mit mutmasslich wenig Jitter behafteten) Clock-Inputs des gennannten FF's.
> Nein, den dort wirt der Jitter vom Eingang 1:1 am Ausgang. Beim FlipFlop > aber nicht, dort wirkt nur der Taktjitter! Wenn wir mal annehmen, dass eine steigende Flanke so jittrig wie die fallende Flanke ist, macht das keinen Unterschied. Wenn der Eingangstakt um +-100ps wackelt, wackelt jede Flanke des runtergeteilten Ausgangstakts genauso. Ok, relativ zur Frequenz ist das weniger, absolut aber gleich. Woher sollte das FF denn auch wissen, wo der Mittelwert des Jitters liegt? Jitter entfernen kann man nur mit einer (guten...) PLL.
Georg A. schrieb: > FFs können keinen Jitter entfernen, höchstens identisch durchlassen. Sie können aber auf einen jitterarmen Takt synchronisieren. Natürlich kann der Jitter nach dem Flipflop niemals besser sein, als der des ursprünglichen Taktsignals. Aber der Jitter des heruntergeteilten Taktes kann ja noch sehr viel schlechter sein...
Jitter komplett entfernen kann man gar nicht, wie schon weiter oben festgestellt. Es ist immer welcher vorhanden.
> Sie können aber auf einen jitterarmen Takt synchronisieren.
Jaja, aber was hat das mit der Aufgabenstellung zu tun? Wenn beim
Runterteilen noch ein zweiter Takt einbezogen wird, hat das Ergebnis ja
nur noch entfernt mit dem Signal zu tun. Wofür soll man dass dann noch
brauchen können?
Georg A. schrieb: > Wenn beim Runterteilen noch ein zweiter Takt einbezogen wird 1. Es gibt einen Basistakt mit einem Jitter << 10ps (ich kann ja nichts teilen und dadurch eine Besserung erwarten) 2. Dieser wird heruntergeteilt 3. Beim Teilen entsteht zusätzlicher Jitter 4. Dieser Jitter wird mit dem Takt aus (1.) wieder synchronisiert
> 3. Beim Teilen entsteht zusätzlicher Jitter Beim Hintereinanderschalten von Toggle-FFs (Ausgang->CLK) ja. Dann ist es aber ein ziemliches Russisch-Roulette, > 4. Dieser Jitter wird mit dem Takt aus (1.) wieder synchronisiert zu machen. Setup/Hold/Metastabilität&Co freuen sich sicher auf so ein Konstrukt. Wenn man Pech hat, ist der Jitter des geteilten Ausgangssignals dann genauso gross, wie die Taktperiode des Eingangstaktes+der Teil-Jitter. Klingt mir nicht so erstrebenswert.
Georg A. schrieb: > Wenn man Pech hat, ist der Jitter des geteilten Ausgangssignals dann > genauso gross, wie die Taktperiode des Eingangstaktes+der Teil-Jitter. Kannst du das mal aufzeichnen? >> 3. Beim Teilen entsteht zusätzlicher Jitter > Beim Hintereinanderschalten von Toggle-FFs (Ausgang->CLK) ja. Nein, der ehröhte Jitter entsteht auch bei idealer Schaltungauslegung allein dadurch, dass die Schalterei eines Flipflops die Versorgungsspannung des anderen Flipflops und damit dessen Schaltschwelle versaut. Oder warum haben z.B. PCIe Transceiver auf FPGA eigene Versorgungspins? Damit sie nichts von Groundbouncing und wasweißichauchimmer innerhalb des FPGAs abbekommen...
> Kannst du das mal aufzeichnen? Bin grad etwas faul bei der Hitze ;) Aber wenn bei der Hintereinanderschaltung der FFs die Gesamt-Clock-to-Output-Zeit wieder in den Bereich der Taktperiode kommt, wirds halt kritisch. Und das die Zeit so gross wird, ist wahrscheinlich, weil man sonst ja einen normalen synchronen Zähler machen würde ;) > Nein, der ehröhte Jitter entsteht auch bei idealer Schaltungauslegung > allein dadurch, dass die Schalterei eines Flipflops die > Versorgungsspannung des anderen Flipflops und damit dessen > Schaltschwelle versaut. Dem wiederspreche ich nicht. Allerdings sollte das bei synchronem Design alle FFs annähernd gleich beinflussen. D.h. ein "sauberer" Takt für das eine FF wäre im strengen Sinne eigentlich asynchron ;) > Oder warum haben z.B. PCIe Transceiver auf FPGA eigene Versorgungspins? > Damit sie nichts von Groundbouncing und wasweißichauchimmer innerhalb > des FPGAs abbekommen... Oder damit der hochfrequente Müll, denn sie aufgrund ihres Last*Slewrate-"Produkts" verursachen, nicht den Rest stört?
Georg A. schrieb: > Oder damit der hochfrequente Müll, denn sie aufgrund ihres > Last*Slewrate-"Produkts" verursachen, nicht den Rest stört? Jede Medaille hat 2 Seiten...
@ Georg A. (georga) >Hintereinanderschaltung der FFs die Gesamt-Clock-to-Output-Zeit wieder >in den Bereich der Taktperiode kommt, wirds halt kritisch. Das ist ein anderes Thema und hat mit Jitter wenig bis nichts zu tun. Weißt du überhaupt, was Jitter ist? >Dem wiederspreche ich nicht. Allerdings sollte das bei synchronem Design >alle FFs annähernd gleich beinflussen. Ob der Teiler synchron oder asynchron ist, ist zweitrangig. Aber die Eigenstörungen der FlipFlops erhöhen den Jitter des geteilten Ausgangssignals. Dashalb bekommt das letzte eine eigene Versorgung. Dass der Jitter nicht so groß werden darf, dass er die Setup- und Holdzeiten verletzt ist klar. Aber wir reden hier von Jitter deutlich unter 1ns. > D.h. ein "sauberer" Takt für das >eine FF wäre im strengen Sinne eigentlich asynchron ;) Nö. >Oder damit der hochfrequente Müll, denn sie aufgrund ihres >Last*Slewrate-"Produkts" verursachen, nicht den Rest stört? Kaum, das Zeug ist differentiell, das ist relativ ruhig. Und was ist wahrscheinlicher? Ein Dutzend PCIe Tranceiver, die 100k Logikzellen stören oder umgekehrt?
> Das ist ein anderes Thema und hat mit Jitter wenig bis nichts zu tun. > Weißt du überhaupt, was Jitter ist? Nase. Wenn wir in den Bereich kommen, kommt das Ausgangssignal um einen schnellen Takt zu früh oder zu spät. Bei 1GHz also ab und zu +-1ns. Wenn das kein Jitter sein soll, weiss ich auch nicht. Ist halt nicht normalverteilt, aber das ist AFAIR da auch nicht gefordert... Ist aber alles wurscht. FPGA/CPLD mit hochglanzpoliertem Einzel-FF dahinter ist doch für die Anwendung auch witzlos. Es gibt Teilerchips, die genau für solche Anwendungen und Anforderungen gedacht sind. Entweder hat der Threadersteller wirklich ein reales Bedürfnis nach low-Jitter, dann soll er sowas nehmen. Wenn er das nicht hat (und die schwammige Aufgabenstellung bzw. die Art der Frage überhaupt deutet IMO darauf hin, dass er das nicht so recht hat), dann kann er einfach ein FPGA/CPLD/TTL/ECL-Dingens nehmen.
Es gibt in diesem Bereich nicht sonderlich viele beschaffbare ICs, die irgendwie dezimalmäßig teilen. Eine Möglichkeit wäre noch einer der Taktregeneratoren, wie sie silabs für Telekom anbietet. Beim Frequenzbereich könnte es vermutlich eng werden. Der Trick mit dem Testmode der PLL wurde ja schon genannt. Den wollte ich nicht verraten ;-) Generell muß man nach Instabilitäten an den Frequenzgrenzen schauen. Und dann die Frage wie wenig Jitter nun genug ist? Dazu möge sich der Threadersteller doch einfach äußern. Die time-nuts haben wohl die höchsten Ansprüche. Da fällt ständig das Stichwort adev. Regenerative Mixer stellen die Meßlatte.
Abdul K. schrieb: > Und dann die Frage wie wenig Jitter nun genug ist? Anguel S. schrieb: >>> Zum Jitter: So bis 10 ps Jitter wären noch akzeptabel Aber es fehlt noch die Angabe, welchen Jitter die Taktquelle hat. Die ganze Geschichte hier funktioniert nämlich nur, wenn deren Jitter kleiner ist als 10ps...
Nö. Der Ausgangsjitter ist näherungsmäßig nach phytagoras, wobei alle Komponenten vorher normiert auf die gleiche Frequenz werden. Scheiß Satz, aber ich stehe dazu.
da gibts evt was von Analog z.b. http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/ad9512/products/product.html oder mehr http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/products/index.html um den Teilerfaktor von 1000 zu erreichen müsste noch ein externer Teiler davor würde aber trotzdem zuerst die konventionelle Teilervariante testen, es gibt ja Logigfamilien die noch produziert werden und passen könnten
Hier eine bessere Quelle als was ich sagte ;-) http://www.wolaver.org/teaching/232.jpg aus http://www.wolaver.org/teaching/PLL.htm
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.