Stratix PLL für ADC benutzen?

[Maik R. (kiamur)]

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

[Falk B. (falk)]

@ 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

[Maik R. (kiamur)]

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

[Maik R. (kiamur)]

So, jetzt habe ich es mal so gemacht:

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
      if(clk_out = '0') then
        merker <= '1';
        clk_out <= '1';
      elsif (clk_out = '1') then 
        merker <= '0';
        clk_out <= '0';
      end if;
    end if;
  end process;
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

[Falk B. (falk)]

@ 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

[Maik R. (kiamur)]

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

[Maik R. (kiamur)]

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