Forum: FPGA, VHDL & Co. Spartan 3 mit two lane LVDS á 200Mbit/s


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Richard (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

ich würde gerne die Daten eines LCT2387-18 ( 18 Bit ADC 15MSPS über two 
lane LVDS ), in einem Spartan 3 weiterverarbeiten.

Im Anhang das timing Diagramm des ADCs, muss ich über den Clock DCO den 
ich aus dem ADC erhalte, mittels PLL eine 90° Phasendrehung machen, um 
die Daten richtig zu samplen?

Ist der Spartan 3 überhaupt Leistungsfähig genug für 200Mbit/s, oder 
muss ich etwas höherwertigeres in Betracht ziehen, bzw. alternativ ein 
externes deserializing IC verwenden?

Danke

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
@ Richard (Gast)

>Im Anhang das timing Diagramm des ADCs, muss ich über den Clock DCO den
>ich aus dem ADC erhalte, mittels PLL eine 90° Phasendrehung machen, um
>die Daten richtig zu samplen?

So in etwa. Das DIng arbeitet ja auch mit dual data rate (DDR), sprich, 
der Takt hat bei 200 Mbit/s nur 100 Mhz und es werden Daten auf der 
fallenden und steigenden Flanke ausgegeben.

Wobei, wenn man GENAU hinschaut, wechselt die Taktflanke doch schon 
recht genau in der MItte der Bits, d.h. man könnten den Takt direkt 
verwenden, um die Daten ins FPGA zu takten. Da muss man mal genauer im 
Datenblatt nach dem Timing schauen.

>Ist der Spartan 3 überhaupt Leistungsfähig genug für 200Mbit/s,

Ja.

>muss ich etwas höherwertigeres in Betracht ziehen, bzw. alternativ ein
>externes deserializing IC verwenden?

Nein.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> Im Anhang das timing Diagramm des ADCs, muss ich über den Clock DCO den
> ich aus dem ADC erhalte, mittels PLL eine 90° Phasendrehung machen, um
> die Daten richtig zu samplen?
Du gibt einen Takt aus (den CLK) und bekommst irgendwann später einen 
Takt synchron zu den Daten vom ADC zurück (den DCO). Für den Empfang 
interessieren dich also nur die DCO, DA und DB, denn unabhängig vom 
Abstand bzw. von der Leitungslänge zwischen FPGA und ADC sind die drei 
zueinander synchron.

> mittels PLL eine 90° Phasendrehung machen, um die Daten richtig zu
> samplen?
Auf einen Takt, der ab und zu "aussetzt" kannst du sowieso keine PLL/DCM 
ansetzen.

> Ist der Spartan 3 überhaupt Leistungsfähig genug für 200Mbit/s
Der packt das schon, die effektive Datenrate nach dem Deserializing ist 
ja nur noch 15MHz.

: Bearbeitet durch Moderator
von Richard (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die Rückmeldung.

Habe ein weiteres Timing Diagramm angehängt.

Aber ich habe doch das "Problem", dass ich nicht zum Zeitpunkt 1, wo ja 
eine Flanke des DCO wäre samplen darf, sondern zum Zeitpunkt 2, also 
exakt in der Mitte des Taktes.
Ich kann aber doch nur auf Flanken "triggern", also müsste ich doch ein 
um 90° versetztes Taktsignal zur Verfügung haben, oder denke ich aktuell 
sehr falsch?

Richard

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> Aber ich habe doch das "Problem", dass ich nicht zum Zeitpunkt 1, wo ja
> eine Flanke des DCO wäre samplen darf, sondern zum Zeitpunkt 2, also
> exakt in der Mitte des Taktes.

Du kannst aber auf den Flanken von CLK samplen. Die sind mitten in den 
Datenbits.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das DCO betrachtest Du einfach wie ein weiteres Datensignal. Damit 
kannst Du anschließend die Bits von DA und DB richtig zuordnen.
Zum Samplen wird CLK genommen.

Ich würde noch einen Zähler o.ä. an DCO machen, um zu wissen wann die 
Übertragung fertig ist und die Daten der Ziel(Takt-)domäne übergeben 
werden können.

Duke

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> muss ich über den Clock DCO den ich aus dem ADC erhalte, mittels PLL
> eine 90° Phasendrehung machen, um die Daten richtig zu samplen?
Die 90° sind nirgends spezifiziert. Sie sind nur so hingekritzelt...
Die Zeit vom CLK zum DCO kann irgendwas zwischen 0,7ns bis 2,3ns sein. 
Dazu kommt noch die Laufzeit auf der Leiterplatte. Irgendwie 
undefiniert.

S. R. schrieb:
> Du kannst aber auf den Flanken von CLK samplen. Die sind mitten in den
> Datenbits.
Lediglich der DCO ist im Bezug auf die Datenleitungen mit +-200ps 
tatsächlich spezifiziert.
Das Datenblatt schlägt vor, mit dem DCO zu sampeln. Ich würde auf jeden 
Fall diesen Weg anpeilen...

von Jens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Man könnte die DCO Leitung etwas länger machen und somit über die 
Laufzeit ein delay bewirken wird bei DDR Speicher mit den clocks so 
gemacht

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nicht nötig, der S3 kennt schon die IDELAYs. Damit kann man die 
Verzögerung intern machen.

Duke

von Richard (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis mit den Input Delays!

Damit dürfte es wirklich am sinnvollsten zu machen sein, ich werde mich 
das ansehen.

Eine kleine nicht ganz in den FPGA Bereich passende Frage hätte ich 
noch, vl. kann mir hier ja auch jemand einen Denkanstoß verpassen.

Laut Datenblatt ist immer nur ein kurzer high Impuls bei CNV angegeben, 
aber kann ich hier nicht einfach einen 15MHz 50% duty Cycle Clock 
anhängen um meine 15MSPS zu erreichen?

Weiters verwirrt mich der Bereich "internal conversion clock" das heißt 
er arbeitet intern mit einem Clock, unabhängig ob ich an CNV 15MHz 
anlege, oder 1MHz, die Abtastzeit beträgt immer maximal 63ns, aufgrund 
des internen Clocks?

Schönen Abend wünscht
Richard

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> Laut Datenblatt ist immer nur ein kurzer high Impuls bei CNV angegeben,
> aber kann ich hier nicht einfach einen 15MHz 50% duty Cycle Clock
> anhängen um meine 15MSPS zu erreichen?
Ja, könnte man machen, aber dann fällt die fallende Flanke vermutlich 
immer in die Umsetzung und kann dort für Störungen sorgen.

> Weiters verwirrt mich der Bereich "internal conversion clock" das heißt
> er arbeitet intern mit einem Clock, unabhängig ob ich an CNV 15MHz
> anlege, oder 1MHz, die Abtastzeit beträgt immer maximal 63ns, aufgrund
> des internen Clocks?
Genau.

Ist der Jitter bei Deiner Anwendung relevant?

Duke

von Richard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Duke!

Danke für diesen Einwand, daran habe ich absolut nicht gedacht!
Das heißt da muss ich mir noch etwas anderes überlegen.

Geplant ist diesen ADC für eine FFT von ~ 10kHz - 5MHz zu verwenden. Da 
dürfte sich Jitter nicht extrem auswirken oder?

Richard

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ Richard (Gast)

>Geplant ist diesen ADC für eine FFT von ~ 10kHz - 5MHz zu verwenden. Da
>dürfte sich Jitter nicht extrem auswirken oder?

Was ist schon extrem? Bei einem ADC sollte man sich schon anstrengen, 
den mit sauberen Signalen zu füttern, erst recht was das Steuersignal 
zur Abtastung angeht.

von Richard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja anders gefragt, auf welche Signale wirkt sich ein hoher Jitter 
besonders aus?
Periodische Signale sind von Jitter vmtl. weniger betroffen als nicht 
periodische Signale oder?

Weiß jemand wodurch bedingt vergleichbare ( zb. 16 Bit 15MSPS ) SAR und 
Pipeline ADCs verschiedene SNR Werte haben, das heißt SAR ADCs haben zum 
Teil ~10dB mehr SNR als vergleichbare Pipeline ADCs

Richard

von Arduinoquäler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> Naja anders gefragt, auf welche Signale wirkt sich ein hoher Jitter
> besonders aus?

Auf alles was du mit dem ADC konvertierst.

Die Clock-Frequenz des ADC muss so sauber sein (eher besser)
wie die Signalgüte des zu wandelnden Signals das du erwartest.

Betrachte den Wandlungsvorgang als eine Mischung mit dem
Taktsignal des Wandlers. Alles was auf dem Taktsignal
an Jitter (=Nebenlinien) drauf ist bildet sich im
Mischprodukt (=digitalisiertes Signal) ab. Da hilft auch
kein Filter danach ....

Die ganzen "Regeln" gelten natürlich auch für das Phasenrauschen.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> Naja anders gefragt, auf welche Signale wirkt sich ein hoher Jitter
> besonders aus?
Anders gefragt: auf welche Signale wirkt sich Jitter nicht aus?
Richtig: DC-Signale

Je höher die Frequenz, desto mehr wird der Zeitfehler (Jitter) in einen 
Amplitudenfehler überführt.

Bei einer FFT führt das dazu, das die Spektrallinien verbreitert werden 
(und dafür die Höhe nicht mehr stimmt). Je dicker die FFT, deso mehr 
wird das Problem sichtbar.

Ob es in der Anwendung stört, kannst Du über eine Fehlerbetrachtung 
entscheiden.

Duke

von Richard (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Erläuterungen!

Ok das heißt ich brauche eine Taktquelle mit recht niedrigem Jitter.

Im Anhang der Ausschnitt des Taktes aus dem DemoBoard von Linear.

Wäre ein 100MHz TCXO + D-FlopFlop wie im Schaltplan eine adäquate 
Möglichkeit?
Bzw. da 100MHz TCXOs natürlich selten sind, einen Niederfrequenteren + 
Vervielfacher?

Richard

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kalkuliere doch erstmal was für ein Jitter zulässig ist.
Vervielfachen, verstärken, optisch- und zurückwandeln etc. pp. erhöht 
üblicherweise den Jitter.

Duke

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Kalkuliere doch erstmal was für ein Jitter zulässig ist.
> Vervielfachen, verstärken, optisch- und zurückwandeln etc. pp. erhöht
> üblicherweise den Jitter.
>
> Duke

Zum Beispiel ganz easy hiermit:: 
https//www.maximintegrated.com/en/design/tools/calculators/general-engineering/jitter.cfm

von Richard (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

Das heißt möchte ich ein Signal mit 5MHz mit vollen 18 Bit auflösen, 
darf der Clock Jitter maximal 121fs betragen.

Ich vermute der Wert wird sehr schwer zu erreichen.

Im Demo Aufbau von LTC verwenden sie als Clock einen SAW Oszillator, 
gefolgt von einem 1/8 Teiler.
Der wird am Board dann nochmals 1/2 geteilt.

Aber durch das D FlipFlop vor dem ADC wird ja ohnehin erreicht, dass nur 
die positive Flanke zum ADC kommt, die negative Flanke für über den 
Reset am D - FlopFlop und damit durch den FPGA/CPLD bestimmt, da die ja 
unkritisch ist.

Ist ein Aufbau SAW Oszillator + 1/16 Teiler im produktiven Aufbau 
sinnvoll?

Wären ähnliche Werte nicht auch mit Standard XOs möglich wie zb.:
http://www.mouser.com/ds/2/741/LFSPXO022825Bulk-939467.pdf (können diese 
Daten stimmen?)

Richard

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Naja. Welches SNR hat denn der ADC selbst und vor allem die 
Analogstrecke davor? Ich glaube kaum dass die 108dB SNR und Dynamik 
schafft...meist sind über 16 Bit die ADC Bits großes Werbeversprechen.
Und ja es gibt Quarzoszillatoren die so wenig Jitter haben, aber dann 
sollte man nix rum teilen oder gar in eine PLL stecken.

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Ahja, etwa 95dB bei 5MHz SNR am ADC. Naja da kann man sich die unteren 2 
Bit ja gleich schenken, je nach Analogstrecke auch noch ein paar mehr. 
Da brauchst du auch keinen Super XO ;)

von Richard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja das ist wahr, rein rechnerisch eher 16Bit als 18Bit ;).
Aber bei anderen (Pipeline) ADCs mit 16Bit ist der SNR nochmal 10dB 
weniger, ist das Prinzipbedingt, oder schummelt LTC bei den Angaben 
etwas?

Wird aber schwierig, ich müsste zumindest um den Faktor 2 Teilen, da 
mein CNV min. 5ns auf high sein muss.

Wie würdest du das am sinnvollsten angehen, einen Standard XO wie oben 
mit ~60fs und dahinter ein D-FF?

Richard

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Wir machen das immer mit einem recht hohen Takt im FPGA, und generieren 
die Steuersignale über Zähler.
Wobei diese SAR Wandler ziemlich fies sind, denn die Zeit zum Daten raus 
schieben ist viel kürzer als die Conversion time. In den Datenblättern 
sieht das immer anders dargestellt aus. Da braucht man schon sehr hohe 
Taktfrequenzen.

von Richard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und der Jitter über den FPGA + Zähler ist annehmbar?

Das heißt du nimmst für den FPGA einen recht hohen Takt mit gutem Jitter 
(zb. der XO wie oben?) und machst die Ansteuerung für die Conversion 
direkt im FPGA mittels Zähler?

Zum Abholen der Daten habe ich laut Datenblatt maximal 50ns Zeit, das 
heißt ich muss mit annähernd 200MHz Takt die Daten holen.

Richard

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Richard schrieb:
> Und der Jitter über den FPGA + Zähler ist annehmbar?
>
> Das heißt du nimmst für den FPGA einen recht hohen Takt mit gutem Jitter
> (zb. der XO wie oben?) ...

> Zum Abholen der Daten habe ich laut Datenblatt maximal 50ns Zeit, das
> heißt ich muss mit annähernd 200MHz Takt die Daten holen.

Ich antworte mal statt Chris:
Der externe Oszillator muss nicht besonders schnell takten, 50 MHz sind 
üblich, im FPGA sind Baugruppen implementiert (bei Spartan3 heissen die 
wohl DLL oder DCM) die diesen Takt vervielfachen können. Ob dein 
Spartan3 die 200 MHz schafft verrät das Datenblatt, das ist auch vom 
Speedgrad das Bausteins abhängig den wir nicht kennen.

http://www.weblearn.hs-bremen.de/risse/RST/WS05/uc/Spartan/Spartan3/xapp462_clock-manager-im-s3.pdf


Schau mal in folgenden thread, da werden ein paar Appnotes genannt die 
auf dein Szenario zutreffen könten: 
https://www.fpgarelated.com/showthread/comp.arch.fpga/30037-1.php

Für die ähnlichen Typen Startan-3e und -3A siehe folgende AppNote, mglw. 
kannst du die Infos ohne größere Anpassungen für dein Design 
übernehmen:
https://www.xilinx.com/support/documentation/application_notes/xapp485.pdf

von Arduinoquäler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Der externe Oszillator muss nicht besonders schnell takten, 50 MHz sind
> üblich, im FPGA sind Baugruppen implementiert (bei Spartan3 heissen die
> wohl DLL oder DCM) die diesen Takt vervielfachen können.

Nö.

PLLs und Konsorten in FPGAs sind extrem ungünstig und verschlechtern
den Nebenlinienanteil (verstärken den Jitter) eines guten externen
Referenzsignals deutlich.

Allenfalls ist ein hochvervielfachtes Signal geeignet die Taktung
der gesamten Logik zu übernehmen, nicht jedoch die Taktung
(Referenz) eines ADCs.

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
Der XO wird natürlich parallel an FPGA und ADC angeschlossen, sonst ist 
der Jitter viel zu hoch. Die Ausgabe des conv Singnals sollte dann 
synchron zum Takt erfolgen, aber diese SAR Wandler sind mit ihrem 
internen Takt halt sehr ungünstig für sowas. Daher machen die dort 
solche Klimmzüge mit dem D FF.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Moin!
Ich werde auf meine nächste Hardware ebenfalls diesen ADC setzen und 
habe dazu eine Frage:

Ich könnte zur Erfassung der Daten zwei IDDR verwenden. Die geben mir 
dann jeweils das Bit aus das zur steigenden und das zur fallenden Flanke 
erfasst wurde.
Ich könnte das aber auch zu Fuß machen:
process begin
  wait until rising_edge(DCO);
  DA_rise <= DA_rise(3 downto 0) & DA_delayed;
  DB_rise <= DB_rise(3 downto 0) & DB_delayed;
end process;

process begin
  wait until falling_edge(DCO);
  DA_fall <= DA_fall(3 downto 0) & DA_delayed;
  DB_fall <= DB_fall(3 downto 0) & DB_delayed;
end process;

Es sind ja im TWOLANE = '1' Modus 5 Clock Pulse, also 5 rising, 5 
falling. Da wollte ich also für DA und DB jeweils ein 5Bit-Register für 
rising und ein 5Bit-Register für falling verwenden.
Nach einer Übertragung müssen die Bits natürlich passend geordnet 
werden:
data <= DA_rise(4) & DB_rise(4) & DA_fall(4) & DB_fall(4) &
      DA_rise(3) & DB_rise(3) & DA_fall(3) & DB_fall(3) & 
    DA_rise(2) & DB_rise(2) & DA_fall(2) & DB_fall(2) &
    DA_rise(1) & DB_rise(1) & DA_fall(1) & DB_fall(1) &
    DA_rise(0) & DB_rise(0);

Hat das einen Nachteil wenn ich das zu Fuß baue?

Ja, das mit dem Edge-Aligned DDR und der gated Clock ist etwas doof. Ich 
verwende dafür die IDELAYE2 um DA und DB zu verzögern. Sieht in der 
Simulation gut aus.
Aber gibt es noch einen anderen Weg? Natürlich darf man nur DCO, DA und 
DB verwenden weil die Verzögerungen zwischen CLK und DA und DB nicht 
spezifiziert sind.
Und wieso machen Hersteller denn überhaupt dieses Edge-Aligned DDR?

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Hat das einen Nachteil wenn ich das zu Fuß baue?

Allgemein ist das groesste Problem, dass du keinen IOB als Inpur 
Register nehmen kannst, weil du dort entweder nur mit der steigenden 
oder fallende Flanke eintakten kannst. Daher muss das Signal nach 
"innen" geroutet werden und dort auf zwei getrennte Register gesplittet 
werden.

Die Konsequenz: Komplexitaet in den Timing Constraints mit all den damit 
verbundenen Routing Problemen. Ebenso wirst du Schwierigkeiten bekommen 
das Clock to Data Timing anzupassen, z.B. ueber IDELAYs. Haengt also 
alles stark davon ab wie schnell dein Signal ist.

Die Frage ist daher eher: Hat es einen Vorteil das zu Fuss zu bauen?

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Ja. Wenn man sich im ug471 die Seiten 110 und 111 anguckt, dann sieht 
man, dass man einen Takt mehr benötigt um alle Daten zu bekommen.
Wenn ich also 5 Takte habe in der Transaktion, dann brauche ich 6 Takte 
um auch die Daten vom 5. Takt zu erfassen. Aber diesen 6. Takt Puls habe 
ich leider nicht.
Wobei bei diesem ADC nur 9 Bits mit 5 Pulsen übertragen werden. Also mit 
der fallenden Flanke von Puls 5 werden keine Daten mehr übertragen. Das 
bedeutet in den Bildchen aus dem UG, dass ich nur bis und inklusive D8A 
erfassen muss. Dafür habe ich 5 Pulse. Die Frage ist aber:
Liegt D8A am Ausgang des IDDR schon bei der fallenden Flanke von Puls 5 
an? In der Zeichnung ist das so, aber es sieht eher knapp aus.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal den OPPOSITE_EDGE Mode an. Der sollte eigentlich dein 
Problem loesen.

Die Zeichnung zeigt dir keine Timings nur Ablaeufe. Also verlasse dich 
nicht darauf was dort knapp oder nicht knapp aussieht!

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Schau dir mal den OPPOSITE_EDGE Mode an. Der sollte eigentlich dein
> Problem loesen.

Ja, aber auch Same Edge wäre möglich. Ich muss ja bei OPPOSITE_EDGE Mode 
Q1 mit der fallenden Flanke erfassen weil ich nur 5 Pulse habe aber D8A 
noch haben will.

Bei Same Edge würde ich Q1 und Q2 mit der fallenden Flanke erfassen. Und 
auch beim OPPOSITE_EDGE Mode könnte ich nicht nur Q1 sondern auch Q2 mit 
der fallenden Flanke erfassen.

Tobias B. schrieb:
> Die Zeichnung zeigt dir keine Timings nur Ablaeufe. Also verlasse dich
> nicht darauf was dort knapp oder nicht knapp aussieht!

Das stimmt schon, aber aus der Zeichnung wird klar, dass es knapper ist 
D8A mit der fallenden Flanke des 5. Pulses zu erfassen als mit einer 
steigenden Flanke eines 6. Pulses den ich leider nicht habe.

Aber wie auch immer, ich kenne jetzt die Möglichkeiten, warte auf die 
Platinen und dann wenn ich die bestückt habe werde ich das mal 
ausprobieren und mich hier wieder melden mit (hoffentlich 
funktionierendem) Code.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Das stimmt schon, aber aus der Zeichnung wird klar, dass es knapper ist
> D8A mit der fallenden Flanke des 5. Pulses zu erfassen als mit einer
> steigenden Flanke eines 6. Pulses den ich leider nicht habe.

Nope, aus der Zeichnung wird absolut 0 klar wie knapp das Timing ist 
oder wieviel Luft du hast. Die ist zu 100% schematisch. Da hilft nur 
Timing Constraints definieren und dein STA Tool anwerfen.

Aber ich ehe jetzt immer noch nicht das Problem das dich zwingt auf 
einen IDDR zu verzichten.

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> wie knapp das Timing ist oder wieviel Luft du hast.

Das stimmt ja auch. Quantitativ kann man da nix draus lesen. Aber 
qualitativ kann man sehen, dass die Zeit zwischen D8A valid und der 
fallenden Flanke des 5. Pulses kürzer ist als die Zeit zwischen D8A 
valid und der steigenden Flanke des 6. Pulses. Ganz einfach weil die 
steigende Flanke des 6. Pulses eben erst nach der fallenden Flanke des 
5. Pulses kommt. Es wäre also besser Q1 mit der steigenden Flanke zu 
erfassen und Q2 mit der fallenden Flanke. Ob man Q1 trotzdem mit der 
fallenden Flanke erfassen kann oder nicht geht aus der Zeichnung nicht 
hervor, das muss ich ausprobieren. Oder mit einem IDELAYE2 die Pulse 
intern verzögern.
Aber egal, werde ich ausprobieren.
Ich werde auch den Weg zu Fuß ausprobieren, es könnte ja sein, dass mir 
da automagisch ein IDDR eingebaut wird. Glaube ich aber nicht.

Tobias B. schrieb:
> Aber ich ehe jetzt immer noch nicht das Problem das dich zwingt auf
> einen IDDR zu verzichten.

Was macht das IDDR genau? Das liefert mir ein Q1 und ein Q2. Und die 
kann ich dann entweder mit zwei unterschiedlichen Flanken auslesen, aber 
weil ich keinen 6. Puls habe geht das nicht, ich muss also im 
OPPOSITE_EDGE Mode für Q1 auch die fallende Flanke verwenden. Aber das 
ist OK wenn es das Timing schafft. Das würde bedeuten, dass ich vor 
meinen "Weg zu Fuß" eben dieses IDDR setze und dann statt
process begin
  wait until rising_edge(DCO);
  DA_rise <= DA_rise(3 downto 0) & DA_delayed;
  DB_rise <= DB_rise(3 downto 0) & DB_delayed;
end process;

process begin
  wait until falling_edge(DCO);
  DA_fall <= DA_fall(3 downto 0) & DA_delayed;
  DB_fall <= DB_fall(3 downto 0) & DB_delayed;
end process;
sowas mache
process begin
  wait until falling_edge(DCO);
  DA_rise <= DA_rise(3 downto 0) & DA_Q1;
  DB_rise <= DB_rise(3 downto 0) & DB_Q1;
  DA_fall <= DA_fall(3 downto 0) & DA_Q2;
  DB_fall <= DB_fall(3 downto 0) & DB_Q2;
end process;

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Das stimmt ja auch. Quantitativ kann man da nix draus lesen. Aber
> qualitativ kann man sehen, dass die Zeit zwischen D8A valid und der
> fallenden Flanke des 5. Pulses kürzer ist als die Zeit zwischen D8A
> valid und der steigenden Flanke des 6. Pulses. Ganz einfach weil die
> steigende Flanke des 6. Pulses eben erst nach der fallenden Flanke des
> 5. Pulses kommt. Es wäre also besser Q1 mit der steigenden Flanke zu
> erfassen und Q2 mit der fallenden Flanke. Ob man Q1 trotzdem mit der
> fallenden Flanke erfassen kann oder nicht geht aus der Zeichnung nicht
> hervor, das muss ich ausprobieren. Oder mit einem IDELAYE2 die Pulse
> intern verzögern.

Nein, auch das kannst du aus dem Diagramm nicht mit Sicherheit sagen. 
Dir hilft wirklich nur der Timing Report weiter. Und selbst wenn es so 
waere: Du hast bevor du den Timing Report ausgewertet hast, erstmal kein 
Problem und daher keine Notwendigkeit fuer den geplanten Pfusch.

Gustl B. schrieb:
> Aber egal, werde ich ausprobieren.

Genau, dazu brauchst du nichtmal ein Board.

Edit: Ok, der Code Beispiele sind alle nicht gut. Daher erstmal alles 
weg.

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Klar kann ich sagen dass die Zeit von D8A valid bis zur fallenden Flanke 
des 5. Pulses kürzer ist also bis zur steigenden Flanke eines 6. Pulses.

Tobias B. schrieb:
> Ok, der Code Beispiele sind alle nicht gut. Daher erstmal alles weg.

Mag sein, funktioniert aber in der Simulation. Ohne Begründug werde ich 
da nix verwerfen.

Aber mit nur einer Flanke könnte ich auch gleich zwei 9Bit Register 
verwenden für DA und DB und
process begin
  wait until falling_edge(DCO);
  DA_reg <= DA_reg(6 downto 0) & DA_Q2 & DA_Q1;
  DB_reg <= DA_reg(6 downto 0) & DB_Q2 & DB_Q1;
end process;
schreiben.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Mag sein, funktioniert aber in der Simulation. Ohne Begründug werde ich
> da nix verwerfen.

Das ist klar, da hast du auch keine reale Welt Timings zu 
beruecksichtigen. ;-)

: Bearbeitet durch User
von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
So und funktioniert.
Der Witz: Im Datenblatt ist gezeichnet wie viele CLK Pulse man minimal 
benötigt, aber es steht nirgends, dass es nicht auch mehr Pulse seien 
dürfen. Und siehe da, wenn man mehr Pulse als nötig ausgibt dann bekommt 
man auch mehr Pulse über DCO wieder rein und kann ganz bequem das IDDR 
mit DDR_CLK_EDGE => "SAME_EDGE_PIPELINED" verwenden.
Dazu braucht man dann einen Puls zusätzlich. Das geht auch mit dem 
Timing. Im One-Lane Output Mode braucht man also statt der 9 Pulse dann 
10.

Bei 15 MSample/s hat man zwischen T_FIRSTCLK = 65 ns und T_LASTCLK = 49 
ns eine Zeit von 66.666 ns - 65 ns + 49 ns = 50.666 ns.
Damit muss der Takt von SCK mindestens 1/((50.666 ns/(10+9))*2)=187.5 
MHz sein. Und das ist zulässig. Beim Two-Lane Output Mode wird das 
nochmal entspannter und beim LTC2387-16 ist es ebenfalls entspannter, 
denn bei dem gelten die gleichen Zeitangaben im Datenblatt.

Ich habe das jetzt mal für einen LTC2387-16 getestet und zwar mit etwas 
höherem Sampletakt. Mein externer Takt hat 125 MHz, den verwende ich im 
FPGA um ein CNV_EN zu erzeugen. Und mit einem ODDR gebe ich 5 Pulse auf 
CLK aus. Dazu verwende ich einen Zähler der von 0 bis 7 zählt, also den 
Takt durch 8 teilt. Meine Abtastrate liegt also bei 1/64 ns = 15.625 
MSample/s.

Die Daten DA und DB werden dann gegenüber der DCO mit je einem IDELAYE2 
verzögert und danach in je ein IDDR mit DDR_CLK_EDGE => 
"SAME_EDGE_PIPELINED" gefüttert.

Mit der steigenden Flanke von DCO werden dann die Ausgänge der IDDRs in 
je ein 6 Bit Schieberegister geschoben:
process begin
  wait until rising_edge(DCO);
  DA_reg <= DA_reg(3 downto 0) & DA_Q1 & DA_Q2;
  DB_reg <= DB_reg(3 downto 0) & DB_Q1 & DB_Q2;
end process;

Aber im "SAME_EDGE_PIPELINED" Modus bekomme ich valide Daten erst mit 
der 3. steigenden Flanke. Es werden also mit den steigenden Flanken der 
CLK Pulse 3, 4 und 5 zusammen (Two-Lane und DDR) 2*2*3 = 12 Bits 
erfasst. Die letzten 4 Bits hole ich dann später ab wenn ich die Daten 
ausgebe. Da hat man ja Zeit weil sich die Ausgänge der IDDRs in der 
Pause von DCO nicht ändern.
Man könnte aber auch die Daten mit DCO abholen, dazu bräuchte man aber 
zwei zusätzliche Pulse auf CLK zu der minimalen Pulsanzahl wie sie im 
Datenblatt gezeichnet ist.

Im Anhang ein Minimalprojekt mit Testbench, Bildchen der Simulation und 
das VHDL für den LTC2387-16 mit einer Abtastfrequenz von 1/8 des 
Eingangstaktes. Darf gerne verwendet werden und modifiziert, bei Fragen 
fragen.
Viel Spaß!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.