Forum: FPGA, VHDL & Co. ADC clock & FPGA


von Manuel (Gast)


Lesenswert?

Hallo!

so viel ich gelesen habe soll ich einen ADC ja nicht mit einem Clock aus 
einem FPGA füttern (wegen jitter).

Wenn ich jetzt aber z.B. oversampling mit dem ADC machen möchte? Gibt es 
da überhaupt eine möglichkeit außer den Clock aus dem FPGA zu nehmen und 
die Phase zu verschieben??

Gruß,
  Manuel

von Falk B. (falk)


Lesenswert?

@  Manuel (Gast)

>so viel ich gelesen habe soll ich einen ADC ja nicht mit einem Clock aus
>einem FPGA füttern (wegen jitter).

Jain. Das gilt in erster Line nur für sehr schnelle ADCs (100MHz++) und 
sehr auf Super-duper-HiFi bedachte Audio-ADCs. Der Rest kann durchaus 
mit einem FPGA Takt gut leben.

>Wenn ich jetzt aber z.B. oversampling mit dem ADC machen möchte? Gibt es
>da überhaupt eine möglichkeit außer den Clock aus dem FPGA zu nehmen und
>die Phase zu verschieben??

Wozu brauchst du eine verschobene Phase bei Oversampling?

MFG
Falk

von Manuel (Gast)


Lesenswert?

Das mit der verschobenen Phase hab ich mir so überlegt:  Ich habe ein 
(sich wiederholendes) Signal. Wenn ich jetzt bei 0, 90, 180, 270 Grad 
messe, dann sollte sich doch die Bandbreite vervierfachen.

von Falk B. (falk)


Lesenswert?

@ Manuel (Gast)

>Das mit der verschobenen Phase hab ich mir so überlegt:  Ich habe ein
>(sich wiederholendes) Signal. Wenn ich jetzt bei 0, 90, 180, 270 Grad
>messe, dann sollte sich doch die Bandbreite vervierfachen.

Sooo einfach ist es nicht. Und du schriebst was von OVERsampling. Das 
erhöht keine Bandbreite.

MfG
Falk

von Manuel (Gast)


Lesenswert?

Habe mich wohl etwas umständlich ausgedrück... Was ich machen will ist 
erstmal folgendes:

2 x ADC 80MS/S ADS831 jeweils mit 80MHZ clock mit 180° Differenz zu 
samplen. Das sollte dann auch die doppelte Bandbreite der ADCs geben 
wenn die clocks stimmen.

Als nächstes hab ich schon gesehen (was ich auch vorhin schon 
geschrieben habe) das sich wiederholende Signale zu unterschiedlichen 
Zeiten gemessen werden und somit das Signal dann berechnet werden kann. 
Hierüber habe ich mir ehrlich gesagt noch keine weiteren Gedanken 
gemacht, ist aber z.B. auch bei relativ günstigen Scopes implementiert.

Steht die Aussage noch das ich die ADCs vom FPGA clocken kann? Oder wie 
würde man das machen?

Gruß
  Manuel

von Falk B. (falk)


Lesenswert?

@ Manuel (Gast)

>2 x ADC 80MS/S ADS831 jeweils mit 80MHZ clock mit 180° Differenz zu
>samplen. Das sollte dann auch die doppelte Bandbreite der ADCs geben
>wenn die clocks stimmen.

Nur wenn die Sample&Hold Stufen dee ADCs schnell genug sind.

>Als nächstes hab ich schon gesehen (was ich auch vorhin schon
>geschrieben habe) das sich wiederholende Signale zu unterschiedlichen
>Zeiten gemessen werden und somit das Signal dann berechnet werden kann.

Das ist Repititive Sampling, auch Undersampling oder Time Equivalent 
Sampling genannt, KEIN Oversampling.

>Steht die Aussage noch das ich die ADCs vom FPGA clocken kann?

Würde ich sagen.

MFG
Falk

von 6632 (Gast)


Lesenswert?

Wenn man das so machen will muss der ADC eine hoehere analoge Bandbreite 
besitzen. Der LCT2299 zB hat 80MSample und 575MHz analoge Bandbreite. Dh 
wenn man den Trigger genau genug bringt erreicht man ein 575MHz Signal 
mit undersampling zu digitalisieren.

von Manuel (Gast)


Lesenswert?

"Wide Analog Input Bandwidth: 700 MHz Typ" sollte also ausreichend sein.

Ich bin jetzt noch am recherchieren was es mit der von Falk angegebenen 
Sample&Hold Problematik auf sich hat. Soweit ich das verstanden habe ist 
das die Zeit die der ADC die analoge Eingangsspannung während des 
Konvertiurngsvorganges hält. In wie weit sich das auf mehrere parallel 
"horchende" ADCs auswirkt ist mir noch nicht klar.

von ----- (Gast)


Lesenswert?

Was Falk vermutlich meit, ist die "Sample-and-Hold Acquisition Delay 
Time tAP". Ist die Differenz dieser Zeit zwischen den beiden ADCs zu 
gross, wirst du keine verschiebung 180° erreichen können.

von Stefan Salewski (Gast)


Lesenswert?

>Ich bin jetzt noch am recherchieren was es mit der von Falk angegebenen
>Sample&Hold Problematik auf sich hat.

Das wesentliche Element der Sample&Hold Stufe ist doch ein (winziger) 
Kondensator, der kurzzeitig über einen Schalter an das Signal gelegt 
wird, und dann diesen Wert für die Digitalisierung zwischenspeichert. 
Wenn dieses "Laden" des Kondensators relativ lange dauert, bekommt man 
dadurch eine Mittelung des Signals und kann schnelle Signalveränderungen 
nicht mehr auflösen.

von manuel (Gast)


Angehängte Dateien:

Lesenswert?

habe das Datenblatt jetzt mehrfach durchgelesen - leider nichts über die 
Sample-and-Hold time gefunden. Kann vielleicht mal jemand schauen? Im 
Datenblatt steht allerdings schon etwas über Daisy-Chain...

Und wenn ich schonmal dabei bin dumme Fragen zu stellen :-) Was sind die 
Auswahlkriterien für den OP? Den im Datenblatt angegebenen hab ich 
leider nicht bei Reichelt und den üblichen Verdächtigen gefunden.

Gruß,
  Manuel

von Martin (Gast)


Lesenswert?

Die ganzen Timings werden doch Im Timing Diagram angegeben. Die Zeit vom 
Analogwert abgreifen bis zum digitalen Wert sollte die New Data Delay 
Time sein.

von Chris N. (lamda)


Lesenswert?

Nicht vergessen, wenn du mehrere ADC´s verbindest, sollten sie die 
gleiche
Vref haben. Weiters schadet es nicht, den Clock durch z.B. AS Bausteine
zu buffern, damit wird jitter eliminiert.

von Falk B. (falk)


Lesenswert?

@ Chris None (lamda)

>Nicht vergessen, wenn du mehrere ADC´s verbindest, sollten sie die
>gleiche Vref haben.

Das ist das kleinste aller Probleme.

> Weiters schadet es nicht, den Clock durch z.B. AS Bausteine
>zu buffern, damit wird jitter eliminiert.

???

MfG
Falk

von Stefan Salewski (Gast)


Lesenswert?

>Weiters schadet es nicht, den Clock durch z.B. AS Bausteine
>zu buffern, damit wird jitter eliminiert.

Leider ist es wohl eher umgekehrt.
Gute CLOCK-Generatoren haben Jitter < 1ps -- wenn man einen ADC mit 12 
Bit bei 100 MHz hat sollte der Jitter auch nicht wesentlich schlechter 
sein.
Wenn man den Takt durch einen FPGA oder andere Logik-Bausteine schleust, 
wird der Jitter in der Regel deutlich größer. Warum eigentlich?

von Chris N. (lamda)


Lesenswert?

>> Weiters schadet es nicht, den Clock durch z.B. AS Bausteine
>>zu buffern, damit wird jitter eliminiert.
>
> ???
Habe so eine Schaltung mit einem FPGA gemacht, 40Mhz VCXO, unmoduliert 
bzw
mit Sinus für Undersampling moduliert, sowie frequenzverdoppelt ohne 
DLL.
 Das FPGA schaffte die 2nS, die der ADC gerne hat, nicht sauber bzw 
waren vielleicht auch ground bounce usw,
bzw gleichzeitiges Schalten von Ausgängen für nicht saubere rise/fall 
levels
verantwortlich. Ein Buffer mit 1.5nS rise/fall time hat da sehr viel 
gebracht.
Bezüglich der T/H Schaltung, welche im Datenblatt abgebildet ist, dürfte
ein nicht 50%es duty-cycle was bringen. Wie weit das getrieben werden 
kann,
muß experimentell festgestellt werden, 120 Mhz sind warscheinlich 
machbar.

>
> MfG
> Falk

von Chris N. (lamda)


Lesenswert?

Stefan Salewski wrote:
>>Weiters schadet es nicht, den Clock durch z.B. AS Bausteine
>>zu buffern, damit wird jitter eliminiert.
>
> Leider ist es wohl eher umgekehrt.
> Gute CLOCK-Generatoren haben Jitter < 1ps -- wenn man einen ADC mit 12
> Bit bei 100 MHz hat sollte der Jitter auch nicht wesentlich schlechter
> sein.
> Wenn man den Takt durch einen FPGA oder andere Logik-Bausteine schleust,
> wird der Jitter in der Regel deutlich größer. Warum eigentlich?

Sorry, ich meinte die <2nS rise/fall time, die der ADC haben möchte, 
welche
bei überschreiten jitter im internen clock des ADC generiert und zu zu
Jitter im S/H sampling führt, was dann letztendlich die Genauigkeit 
senkt.

von Stefan Salewski (Gast)


Lesenswert?

>Das FPGA schaffte die 2nS, die der ADC gerne hat

Was soll das aussagen?

2 Nanosekunden Jitter? Das wäre für mich ein völlig unbrauchbarer Takt?

Wer als Einheit für Sekunde mehrfach ein großen S verwendet, ist eh 
nicht sonderlich glaubwürdig.

von Stefan Salewski (Gast)


Lesenswert?

>Sorry, ich meinte die <2nS rise/fall time, die der ADC haben möchte,
>welche
>bei überschreiten jitter im internen clock des ADC generiert und zu zu
>Jitter im S/H sampling führt, was dann letztendlich die Genauigkeit
>senkt.

Ok, rise/fall time ist ein ganz anderes Thema. Es ging um Clock-Jitter.

von Michael (Gast)


Lesenswert?

Eine Langsame rise/fall time erzeugt Jitter durch das Rauschen der 
Komperatorschwelle des Takteinganges.

Mfg Michael

von Stefan Salewski (Gast)


Lesenswert?

>Eine Langsame rise/fall time erzeugt Jitter durch das Rauschen der
>Komperatorschwelle des Takteinganges.

>Mfg Michael

Ah ja -- ein weiterer Punkt den man bedenken muss.

von Manuel (Gast)


Lesenswert?

Was wäre denn ein guter Clock Generator?

von Stefan Salewski (Gast)


Lesenswert?

>Was wäre denn ein guter Clock Generator?

Ich hatte mir vorläufig den hier ausgesucht -- kostet bei Digi-Key aber 
ca. 20 Euro, Datenblatt findet man auch über Digi-Key:

Oszillator 100 MHz, low jitter:
  OSC 100.0000MHZ 3.3V LVPECL SMD (Digikey CW590-ND)


Nur so als Anhaltspunkt...

von Manuel (Gast)


Lesenswert?

Das ist ja nicht gerade günstig... Wann ist eigentlich eine PLL zu 
bevorzugen?

von Stefan Salewski (Gast)


Lesenswert?

Ach ja, wenn die Frequenz einstellbar sein soll gibt es Bausteine wie

AD9540

Damit habe ich mich aber noch nicht näher beschäftigt.

von Düsentrieb (Gast)


Lesenswert?

>Das ist ja nicht gerade günstig
für low.jitter schon...die meisten kosten 30eu +++
>Wann ist eigentlich eine PLL zu bevorzugen?
für variablen takt,
dann kannst du gleich ne pll bzw dll im fpga nehmen.

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.