Hallo zusammen! Da ich schon seit einiger Zeit auf der Stelle trete, würde ich mir hier gerne ein paar Experten-Meinungen einholen. Ich habe einen LFSR-Prozess, der mit zehn verschiedenen Geschwindigkeiten (vom Benutzer selektierbar) getaktet werden soll. Dazu hängt ein 150MHz Oszillator an der PLL des FPGAs. Diese PLL erzeugt fünf unterschiedliche Grundtakte. Dahinter liegen Teiler, die aus den Grundtakten die 10 Nutztakte erzeugen. Jetzt zum Problem: Mir ist klar, dass es bezogen auf Clock-Skrewing und entstehenden Glitches nicht gerne gesehen wird, wenn man Takte durch einen einfachen MUX multiplext. Da es aber nicht auf sauberes Umschaltverhalten ankommt und nur ein einziger Prozess getaktet wird wozu nichts anderes synchron laufen muss, könnte man dann nicht einen konventionellen MUX nehmen, oder muss ich da auf ein anderes Verfahren ausweichen? Besten Dank schon mal im Voraus!
>Da ich schon seit einiger Zeit auf der Stelle trete
Wie äußert sich das?
Daniel G. schrieb: > ein 150MHz Oszillator ... 10 Nutztakte Welche denn? Kannst du nicht einfach mit Clock-Enables arbeiten?
Daniel G. schrieb: > Dahinter liegen Teiler, die aus den > Grundtakten die 10 Nutztakte erzeugen. Wie sind diese Teiler aufgebaut? Erzeugst Du da eventuell schon Gated Clocks?
Die Teiler sind bisher als Schieberegister aufgebaut und laufen immer - auch wenn der "erzeugte" Takt nicht verwendet werden. Also wäre die einfachste Möglichkeit die zehn Eingänge der Teiler zu "gaten", oder? Ich bin für jeden Verbesserungsvorschlag zu haben, denn das Thema Timing scheint mir echt eine Wissenschaft für sich zu sein :) Und mit "auf der Stelle treten" meine ich - nach hunderten Seiten Datenblätter lesen und sonstiger Recherche, immer noch keine gute Lösung gefunden zu haben, die das Thema Takt nicht komplexer macht als sie wahrscheinlich ist.
Daniel G. schrieb: > Also wäre die > einfachste Möglichkeit die zehn Eingänge der Teiler zu "gaten", oder? Nein, genau das ist nicht gemeint. Lies mal den Artikel den Falk verlinkt hat ganz genau durch.
Am einfachsten ist es, mit genau 1 Takt auszukommen. Das gelingt in sehr vielen Fällen und dieses Vorgehen ist besonders Anfängern zu empfehlen. Was soll denn mit dem letztlich aus dem 150MHz erzeugten "Takt" passieren? Wo und wofür wird der verwendet?
Schon mal Danke für die Antworten! Lothar Miller schrieb: > Was soll denn mit dem letztlich aus dem 150MHz erzeugten "Takt" > passieren? Wo und wofür wird der verwendet? Der soll ein LFSR takten, welches dann mit einer der zehn Bitraten (Taktraten) eine pseudo-Zufallszahl rausgibt. Und das ist auch der einzige Prozess, der damit versorgt wird. Ich hab den Artikel Taktung FPGA/CPLD schon einige Male gelesen. Aber scheinbar überles ich da was wichtiges.
Lothar Miller schrieb: > Am einfachsten ist es, mit genau 1 Takt auszukommen. Das gelingt in > sehr vielen Fällen und dieses Vorgehen ist besonders Anfängern zu > empfehlen. Ich gebe gerade dem kleinen Bruder eines Freundes etwas Nachhilfe in VHDL. Er hat sich an mich gewandt da seine Schaltung (die algorithmisch/simulativ gesehen ok war) nicht in Hardware funktioniert hat. Das Skriptum (insbesondere Versuch 4) lässt einen schon die Fußnägel hochrollen. Ach ja, Timing constraints? Nie gehört! Aber zum Bestehen des Scheins muss hinterher alles in Hardware laufen, ... bei den Practices eher Glückssache :)
Daniel G. schrieb: > Ich hab den Artikel Taktung FPGA/CPLD schon einige Male gelesen. Aber > scheinbar überles ich da was wichtiges. Es macht einen Unterschied, ob man das macht:
1 | process (Clock1) begin |
2 | if rising_edge(Clock1) then |
3 | Clock2 <= ... |
4 | |
5 | process (Clock2) |
6 | if rising_edge(Clock2) then |
7 | ...
|
oder das
1 | process (Clock1) begin |
2 | if rising_edge(Clock1) then |
3 | Enable2 <= ... |
4 | |
5 | process (Clock1) |
6 | if rising_edge(Clock1) then |
7 | if (Enable2) then |
8 | ...
|
Der erste Fall ist "Gated Clock" und problematisch, weil Clock1 und Clock2 eine Phasenverschiebung haben. Der zweite Fall ist "Clock Enable" und unproblematisch, weil beide Prozesse mit Clock1 laufen und daher immer perfekt synchron sind.
Daniel G. schrieb: > Ich hab den Artikel Taktung FPGA/CPLD schon einige Male gelesen. Aber > scheinbar überles ich da was wichtiges. Offensichtlich Das LFSR bekommt einen festen Takt. Ein zusätzlicher Clock Enable Input bestimmt wann das LFSR weitergeschaltet wird. Das Clock Enable ist nur bei jedem n.ten Takt aktiv, wobei "n" dann den "Takt" des LFSR bestimmt. Dann kann der Synthesier das bei jedem einzelenen FF im FPGA vorhandene CE verwenden. Vorteil: EIN Takt, und als Folge einfache Constraints.
Also um das nochmal schnell mit meinen eigenen Worten zu sagen (mal sehen ob ich's jetzt hab): Ich führe den Oszillator-Takt direkt in den LFSR-Prozess. Und dann bestimme ich durch einen CE, nach jeweils wievielen Taktflanken das LFSR reagieren soll. Also wenn ich mit 150MHz arbeite und bspw. 1MHz LFSR-Taktung haben will, dann lasse ich einen Zähler bis 150MHz laufen und CE aktivieren, oder? Wie würde das denn funktionieren, wenn auch "ungerade" Takte dabei wären? z.B. 8,192MHz? Es gibt ja nun zehn verschiedene CE-Werte. Wie selektiere ich die am geschicktesten von außerhalb des Prozesses? Einfach die zehn Werte in 4 Bit coieren und durch "case" abfragen? Nochmals vielen Dank an euch!
Daniel G. schrieb: > Also wenn ich mit 150MHz arbeite und bspw. 1MHz LFSR-Taktung haben will, > dann lasse ich einen Zähler bis 150MHz laufen und CE aktivieren, oder? Ja > Wie würde das denn funktionieren, wenn auch "ungerade" Takte dabei > wären? z.B. 8,192MHz? Garnicht.
D. I. schrieb: >> Wie würde das denn funktionieren, wenn auch "ungerade" Takte dabei >> wären? z.B. 8,192MHz? > > Garnicht. Hm.. verdammt. Wieso muss alles einen Haken haben? :P Also müsste man für diesen Fall dann doch noch einen separaten PLL-Ausgang legen?
Daniel G. schrieb: > Hm.. verdammt. Wieso muss alles einen Haken haben? :P > Also müsste man für diesen Fall dann doch noch einen separaten > PLL-Ausgang legen? Und welches Teilerverhältnis willst du bei der PLL einstellen um von 150 MHz auf 8,192 MHz zu kommen?
Daniel G. schrieb: > Also wenn ich mit 150MHz arbeite und bspw. 1MHz LFSR-Taktung haben will, > dann lasse ich einen Zähler bis 150MHz laufen und CE aktivieren, oder? Ja > Wie würde das denn funktionieren, wenn auch "ungerade" Takte dabei > wären? z.B. 8,192MHz? Am einfachsten den Grundtakt als kleinstes gemeinsames Vielfaches aller Wunschtakte wählen. Wenn das nicht geht und 7 nsec Jitter (bei 150MHz Grundtakt) kein Problem sind, sich eine Scheibe bei DDC abschneiden. > > Es gibt ja nun zehn verschiedene CE-Werte. Wie selektiere ich die am > geschicktesten von außerhalb des Prozesses? Einfach die zehn Werte in 4 > Bit coieren und durch "case" abfragen? Ich würde den Teiler rückwerts zählen lassen, und den Ausgangswert des Zählers über case auswählen. Hat auch den Vorteil dass glitchfreies Umschalten möglich ist.
Lattice User schrieb: > Am einfachsten den Grundtakt als kleinstes gemeinsames Vielfaches aller > Wunschtakte wählen. Ich glaub, das gestaltet sich schwierig bei 150,100,50,25,...,8.192 und 32.768 Mb/s. Da werd ich mich wohl mal in DDC einlesen. Wie schon erwähnt, was beim Umschalten passiert ist egal. Glitches, Phasenverschiebung und co. werden ignoriert und erst nach ca. einer Sekunde die PRBS-Daten ausgegeben.
D. I. schrieb: > Und welches Teilerverhältnis willst du bei der PLL einstellen um von 150 > MHz auf 8,192 MHz zu kommen? Da es nicht auf ITU-Konformität ankommt kann die dritte Nachkommastelle auch wegfallen bzw. etwas variieren. Mit z.B. M=15und N=275 käme man auf 8.18, was völlig ausreicht.
Jetzt muß ich aber doch noch mal nachhaken. Daniel G. schrieb: > Da es aber nicht auf sauberes > Umschaltverhalten ankommt und nur ein einziger Prozess getaktet wird > wozu nichts anderes synchron laufen muss Wenn das korrekt ist und dabei auch wirklich nichts übersehen wurde, dann kann er doch den Takt machen, wie er will? Also auch ge-mux-ed und ge-gated usw.?
Bronco schrieb: > Wenn das korrekt ist und dabei auch wirklich nichts übersehen wurde, > dann kann er doch den Takt machen, wie er will? Letztendlich sollte ein Takt, der großflächiger verwendet wird, aber wieder einen Weg ins Taktnetz finden, dann sonst wird der quer durchs FPGA irgendwie verdrahtet und hat dementsprechende Laufzeitverschiebungen (Skew). Lattice User schrieb: > sich eine Scheibe bei DDC abschneiden. Ist das das, was ich als DDFS kenne? Das hätte ich nämlich auch vorgeschlagen. Und dann weiter mit Clock-Enables arbeiten. Denn auf dem FPGA ist doch sicher noch irgendwas anderes auch, das mit 150MHz läuft...
Lothar Miller schrieb: > Letztendlich sollte ein Takt, der großflächiger verwendet wird, aber > wieder einen Weg ins Taktnetz finden. Wenn ich diesen Takt über einen BUFG führe, wäre das aber gegeben, oder?
> Das Skriptum (insbesondere Versuch 4) lässt einen schon die Fußnägel > hochrollen. > Ach ja, Timing constraints? Nie gehört! Ja, dem Professor sollte man mal etwas ueber gated clock und Takteilung erzaehlen, kein Wunder das es hier immer wieder falsch gemacht wird, es wird ja so gelehrt... hoppel
Bronco schrieb: > Wenn ich diesen Takt über einen BUFG führe, wäre das aber gegeben, oder? Ob mit oder ohne BUFG: sowas ist bestenfalls der allerletzte Notnagel, an dem ich mich aufhängen kann...
Lothar Miller schrieb: > dann sonst wird der quer durchs > FPGA irgendwie verdrahtet und hat dementsprechende > Laufzeitverschiebungen (Skew). Die Laufzeitverschiebung macht aber wirklich nichts aus in meinem Fall. Hinter dem LFSR kommt nichts mehr und es gibt auch keinen anderen Prozess, der die 150MHz verwendet. Es soll ein ganz kleines, simples Design werden. Das FPGA wird in diesem Projekt einzig und allein für die PRBS-Generierung und deren Takterzeugung verwendet. Quasi so: Oszillator -> PLL -> c0 (150MHz)---------------> MUX0 -> LFSR Prozess ^ -> c1 (100MHz)---------------> | |-------> Teiler0 --> | |-------> Teiler1 --> | |-------> Teiler2 --> | |-------> Teiler3 --> | |-------> Teiler4 --> | | -> c2 (8.192MHz)-------------> | |-------> Teiler5 --> | | -> c3 (32.768MHz)------------> | | | --- sel(4bit) Die Frage: kann man das in meinem Fall so machen? Mir ist bewusst, dass das bei großen Designes strunz ist und man viele Probleme bekommt. Aber mein Design (oder die Anforderung an das Design) ist vergleichsweise ja eher primitiv.
Zwei Fragen: 1. Ist der FPGA schon ausgewählt, bzw angedacht? 2. Wenn ja, was ist das für ein FPGA? Ich hatte bei einen Lattice ECP3 schon mal die Feedbackteiler einer PLL in Logik implementiert und programmierbar gemacht. Ein Lattice MachXO2 hat eine fractional-N PLL, die man über ein Wishbone Port programmieren kann.
Angehängte Dateien:
-
Timing_Block.PNG
10 KB
Ich hab mich noch nicht komplett festgelegt, würde aber gerne mit dem ALTERA CycloneIII arbeiten weil ich den von der UNI schon kenne. Mein momentanes Timing-Design hängt an. Die Funktionalität ist schon mal gegeben. Aber das hat ja noch nicht viel zu sagen...
Warum nicht so?
-> c0 (150MHz)---------------> -> LFSR Prozess -> Mux 0 \
| \
-> c1 (100MHz)---------------> -> LFSR Prozess -> Mux 0 \
|-------> Teiler0 --> -> LFSR Prozess -> Mux 0 \
|-------> Teiler1 --> -> LFSR Prozess -> Mux 0 \
|-------> Teiler2 --> -> LFSR Prozess -> Mux 0 \
|-------> Teiler3 --> -> LFSR Prozess -> Mux 0 / Out
|-------> Teiler4 --> -> LFSR Prozess -> Mux 0 /
| /
-> c2 (8.192MHz)-------------> -> LFSR Prozess -> Mux 0 /
|-------> Teiler5 --> -> LFSR Prozess -> Mux 0 /
| /
-> c3 (32.768MHz)------------> -> LFSR Prozess -> Mux 0/
|
Sel(3..0)
Da ein LFSR wohl nahezu Null HW Ressourcen frisst kannst du es auch
einfach maherfach ausführen.
Das Mux hinterher ist komplett ungetaktet, was aber höchstens zum
Umschaltzeitpunkt kurz Probleme macht.
Mux Mäuschen still schrieb: > Warum nicht so? Gute Idee. Braucht halt relativ viele Clocktrees. Ich würde eine kleine Modifikation vorschlagen: 4 LFSR Prozesse, je einer für c1,c2,c3,c4 Die LFSR Prozesse für c2 und c3 bekommen ein vom jeweiligen Teiler generiertes Clock Enable.
Hey Danke! Das sieht mal nach einer geschickten Lösung aus. Ich werd's mal so aufbauen. Vielen Dank schonmal an alle Beteiligten!
Bei Xilinx gibt es extra "clock mux" Primitive: http://www.xilinx.com/support/answers/19947.htm wenn man diese hernimmt (statt Mux0), sollte der Takt glitchfrei und sicher umschaltbar sein, und auf ein Taktnetzwerk gehen - es sollte doch bei Altera auch solche clock muxes geben oder? >Oszillator -> PLL -> c0 (150MHz)---------------> MUX0 -> LFSR Prozess > ^ > -> c1 (100MHz)---------------> | > |-------> Teiler0 --> | > |-------> Teiler1 --> | > |-------> Teiler2 --> | > |-------> Teiler3 --> | > |-------> Teiler4 --> | > | > -> c2 (8.192MHz)-------------> | > |-------> Teiler5 --> | > | > -> c3 (32.768MHz)------------> | > | > | > --- sel(4bit)
bko schrieb: > Bei Xilinx gibt es extra "clock mux" Primitive: > http://www.xilinx.com/support/answers/19947.htm > wenn man diese hernimmt (statt Mux0), sollte der Takt > glitchfrei und sicher umschaltbar sein Die CLKMUX bei Xilinx haben nur zwei Eingänge. Bei zehn Takten wird es mit dem Routing im CLK-Tree schon etwas komplexer. Duke
Thread beobachten
Seitenaufteilung abschaltenBitte 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.