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
Angehängte Dateien:
-
LTC2387-18.png
88 KB
@ 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.
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.
Angehängte Dateien:
-
LTC.png
33 KB
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
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.
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
Angehängte Dateien:
-
LTC2387_Timing.PNG
87 KB -
LTC2387_DCO.PNG
26 KB
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...
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
Nicht nötig, der S3 kennt schon die IDELAYs. Damit kann man die Verzögerung intern machen. Duke
Angehängte Dateien:
-
LTC2387-18_-_Kopie.png
89 KB -
Clock.png
65 KB
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
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
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
@ 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.
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
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.
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
Angehängte Dateien:
-
33761.png
59 KB
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
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
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
Angehängte Dateien:
-
LTC-Demo.png
170 KB
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
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.
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 ;)
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
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.
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
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
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.
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.
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:
1 | process begin |
2 | wait until rising_edge(DCO); |
3 | DA_rise <= DA_rise(3 downto 0) & DA_delayed; |
4 | DB_rise <= DB_rise(3 downto 0) & DB_delayed; |
5 | end process; |
6 | |
7 | process begin |
8 | wait until falling_edge(DCO); |
9 | DA_fall <= DA_fall(3 downto 0) & DA_delayed; |
10 | DB_fall <= DB_fall(3 downto 0) & DB_delayed; |
11 | 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:
1 | data <= DA_rise(4) & DB_rise(4) & DA_fall(4) & DB_fall(4) & |
2 | DA_rise(3) & DB_rise(3) & DA_fall(3) & DB_fall(3) & |
3 | DA_rise(2) & DB_rise(2) & DA_fall(2) & DB_fall(2) & |
4 | DA_rise(1) & DB_rise(1) & DA_fall(1) & DB_fall(1) & |
5 | 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?
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?
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.
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!
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.
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.
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
1 | process begin |
2 | wait until rising_edge(DCO); |
3 | DA_rise <= DA_rise(3 downto 0) & DA_delayed; |
4 | DB_rise <= DB_rise(3 downto 0) & DB_delayed; |
5 | end process; |
6 | |
7 | process begin |
8 | wait until falling_edge(DCO); |
9 | DA_fall <= DA_fall(3 downto 0) & DA_delayed; |
10 | DB_fall <= DB_fall(3 downto 0) & DB_delayed; |
11 | end process; |
sowas mache
1 | process begin |
2 | wait until falling_edge(DCO); |
3 | DA_rise <= DA_rise(3 downto 0) & DA_Q1; |
4 | DB_rise <= DB_rise(3 downto 0) & DB_Q1; |
5 | DA_fall <= DA_fall(3 downto 0) & DA_Q2; |
6 | DB_fall <= DB_fall(3 downto 0) & DB_Q2; |
7 | end process; |
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.
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
1 | process begin |
2 | wait until falling_edge(DCO); |
3 | DA_reg <= DA_reg(6 downto 0) & DA_Q2 & DA_Q1; |
4 | DB_reg <= DA_reg(6 downto 0) & DB_Q2 & DB_Q1; |
5 | end process; |
schreiben.
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. ;-)
Angehängte Dateien:
-
LTC2387_bench.png
17 KB
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:
1 | process begin |
2 | wait until rising_edge(DCO); |
3 | DA_reg <= DA_reg(3 downto 0) & DA_Q1 & DA_Q2; |
4 | DB_reg <= DB_reg(3 downto 0) & DB_Q1 & DB_Q2; |
5 | 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ß!
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.