Hallo! Ich möchte gerne an mein Stratix Dev Kit einen ADC anschließen (12 Bit, 25MSps). Als ADC werde ich wohl ein Max1420 Dev Kit benutzen (wenn es denn irgendwann einmal ankommt). Der Quartz auf meinem Stratix Board hat 50 MHz. Jetzt habe ich mir gedacht, ich lasse die 50 MHz durch eine Stratix interne PLL halbieren, und Takte damit meinen ADC. In einem anderen Beitrag hier im Forum habe ich gelesen, dass man das PLL Signal nicht zum Takten des ADC benutzen soll. Ich habe aber leider die Begründung nicht verstanden, warum nicht. Auch habe ich die ganze PLL Problematik noch nicht durchschaut. Ich habe mir mit dem MegaWizard Plug-In Manager von Quartus mal eine Phase-locked loop Megafunction erstellt, und wollte dann dort "einfach" auf den Eingang mein 50 MHz clk Signal geben, und habe den Ausgang der Megafunction auf einen PIN vom FPGA gelegt. Ich hatte gehofft, dass ich dann dort mit dem Oszilloskop die 25MHz messen kann. Aber leider zuckt der PIN nicht. Hat jemand von euch mal ein funktionierendes PLL Beispiel in VHDL für einen Altera FPGA, an dem ich mich mal langhangeln kann. Bitte spart euch Antworten mit Hinweisen auf die Altera Dokus. Die lese ich natürlich schon die ganze Zeit, aber ich Blicke da halt nicht so richtig durch. Gruß Maik
@ Maik Ritter >Ich möchte gerne an mein Stratix Dev Kit einen ADC anschließen (12 Bit, >25MSps). Schon heftig das Teil. >gedacht, ich lasse die 50 MHz durch eine Stratix interne PLL halbieren, >und Takte damit meinen ADC. Zum teilen durch zwei würde ich keine PLL nutzen. Ein einfaches FlipFlop als Freqeunzteiler ist wesentlich einfacher und jitterärmer. >In einem anderen Beitrag hier im Forum habe ich gelesen, dass man das >PLL Signal nicht zum Takten des ADC benutzen soll. Ich habe aber leider >die Begründung nicht verstanden, warum nicht. Das Problem ist Jitter. Jitter ist die zeitliche Abweichung von Taktflanken vom idealen Zeitpunkt. Dein 25 MHz Takt hat eine ideale Periodendauer von 40ns. Idealerweise sollte genau nach 40,0000 ns die jeweils nächste Taktflanke einreffen. Real passiert es aber, dass die Flanke mal 100ps früher oder später stattfindet. Das nennt man dann Jitter. Er verursacht eine Verschlechterung der AD-Wandlung. Und bei 25 Msps und 12 Bit wird das schon relevant. >Bitte spart euch Antworten mit Hinweisen auf die Altera Dokus. Die lese >ich natürlich schon die ganze Zeit, aber ich Blicke da halt nicht so >richtig durch. Nimm ein FlipFlop. MfG Falk
Hallo Falk! >Das Problem ist Jitter. Jitter ist die zeitliche Abweichung von >Taktflanken vom idealen Zeitpunkt. Dein 25 MHz Takt hat eine ideale >Periodendauer von 40ns. Idealerweise sollte genau nach 40,0000 ns die >jeweils nächste Taktflanke einreffen. Real passiert es aber, dass die >Flanke mal 100ps früher oder später stattfindet. Das nennt man dann >Jitter. Er verursacht eine Verschlechterung der AD-Wandlung. Und bei 25 >Msps und 12 Bit wird das schon relevant. Das heißt also, dass weniger Jitter zu erwarten ist, wenn ich statt der PLL ein FlipFlop benutze? Ich habe immer gedacht, dass man mit einem PLL wesentlich genauer arbeiten kann . . . Na gut, dann Danke für die Antwort. Das erspart mir zunächst das weiterforschen am PLL Thema. Trotzdem würde ich mich über ein PLL Beispiel sehr freuen. Früher oder später holt es mich ja doch wieder ein . . . Gruß Maik
So, jetzt habe ich es mal so gemacht:
1 | library ieee; |
2 | use ieee.std_logic_1164.all; |
3 | |
4 | entity clk_devider is |
5 | port( clk_in : in std_logic; |
6 | clk_out : out std_logic); |
7 | end entity clk_devider; |
8 | |
9 | architecture arch of clk_devider is |
10 | signal merker : std_logic := '0'; |
11 | begin
|
12 | process (clk_in) is |
13 | begin
|
14 | if(clk_in'event and clk_in = '1') then |
15 | if(clk_out = '0') then |
16 | merker <= '1'; |
17 | clk_out <= '1'; |
18 | elsif (clk_out = '1') then |
19 | merker <= '0'; |
20 | clk_out <= '0'; |
21 | end if; |
22 | end if; |
23 | end process; |
24 | end architecture arch; |
Im Anhang ist das Simulationsergebnis, was erstaunlich gut mit meinem Oszillogramm übereinstimmt (was die Phasenverschiebung betrifft, nicht die Pulsform). Jetzt mal noch eine Frage: Die beiden Takte sind ja nun Phasenverschoben. Ist das nun ein Nachteil, wenn ich beide benutzen möchte? Beispiel: Ich kann mit dem 50 MHz Takt sozusagen die ADC starten und gleichzeitig mit ihm auch das Ergebnis der letzten ADC abholen, weil ja 9 ns Verzögerung ins Land ziehen, bis überhaupt der ADC Takt (die 25 MHz) am FPGA Pin erscheinen. D.h. ich habe 9 ns Zeit die Daten zu holen, und dann noch einen 50MHz Takt, mit dem ich Daten wie auch immer verarbeite, und dann geht das Spiel wieder von vorne los. Ist halt wieder eine Praxisfrage, aber ist es legitim diese 9ns Verzögerung auf diese Art und Weise auszunutzen? Gruß Maik
@ Maik Ritter >So, jetzt habe ich es mal so gemacht: Ein wenig aufwändig. Das geht einfacher. library ieee; use ieee.std_logic_1164.all; entity clk_devider is port( clk_in : in std_logic; clk_out : out std_logic); end entity clk_devider; architecture arch of clk_devider is signal merker : std_logic := '0'; begin process (clk_in) is begin if(clk_in'event and clk_in = '1') then merker <= not merker; end if; end process; clk_out <= merker; end architecture arch; >Die beiden Takte sind ja nun Phasenverschoben. Ist das nun ein Nachteil, >wenn ich beide benutzen möchte? JAIN. Am besten ist, wenn du für sämtlich FPGA Operationen den 50 MHz Takt nimmst und nur die 25 MHz an den ADC ausgibst. >MHz) am FPGA Pin erscheinen. D.h. ich habe 9 ns Zeit die Daten zu holen, Naja, eine etwas krude Formulierung. Das sollte man eher so formulieren. Du hast 9n mehr Hold-Zeit, als der ADC ohnehin schon hat (weil er seinen Takt 9n später bekommt). >und dann noch einen 50MHz Takt, mit dem ich Daten wie auch immer >verarbeite, und dann geht das Spiel wieder von vorne los. >Ist halt wieder eine Praxisfrage, aber ist es legitim diese 9ns >Verzögerung auf diese Art und Weise auszunutzen? JAIN. Hier geht es soweit. Aber in der anderen Richtung (Daten zum ADC schreiben, wenn das möglich und sinnvoll ist) kann man sich in Knie schiessen, wenn nämlich Daten un Takt in die gleich Richtung laufen. Dann sieht der ADC den Takt nämlich zu spät. MFG Falk
Hallo Falk! Mal wieder Danke für die guten Antworten! >Ein wenig aufwändig. Das geht einfacher. Okay, sehe ich ein. Naja, das "bessere" Design kommt dann wohl mit der Zeit. >JAIN. Am besten ist, wenn du für sämtlich FPGA Operationen den 50 MHz >Takt nimmst und nur die 25 MHz an den ADC ausgibst. Darüber hatte ich auch schon nachgedacht. Super, dass ich bei meinen Gedanken nicht total auf dem Holzweg bin. >JAIN. Hier geht es soweit. Aber in der anderen Richtung (Daten zum ADC >schreiben, wenn das möglich und sinnvoll ist) kann man sich in Knie >schiessen, wenn nämlich Daten un Takt in die gleich Richtung laufen. >Dann sieht der ADC den Takt nämlich zu spät. Zum Glück muss nichts an den ADC gehen. Nur der Takt, und dann die Daten zum FPGA. Gruß Maik
ach, was ich noch sagen wollte: Mein Codebeispiel oben haut natürlich so nicht hin. Da habe ich aus Versehen eine falsche Version hier rein gestellt. . . In den if-Abfragen darf nicht clk_out stehen, sondern merker . . . Maik
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.