Hallo, ich habe eine Hardware gebaut um etwas mit einem schnellen DAC zu spielen. Der DAC ist ein AD9747 https://www.analog.com/media/en/technical-documentation/data-sheets/AD9743_9745_9746_9747.pdf also 16 Bit und maximal 250 MHz. Der hängt an einem FPGA und wird mit Daten beliefert. Am Ausgang hängt jeweils ein THS3215. Den Takt bekommt der DAC schön aus einem Taktteiler, einem AD9508 https://www.analog.com/media/en/technical-documentation/data-sheets/AD9508.pdf . Der DAC liefert dann selber einen Takt DCO an den FPGA und mit diesem Takt werden Samplewerte aus einer großen Sinustabelle herausgetaktet. Das ist also eine große Tabelle mit 1024 16 Bit Werten und einem Index. Bei jedem Takt wird der Index 1 hochgezählt und der Tabelleneintrag von diesem Index an den Ausgang und somit den DAC angelegt. Ich verwende Unsigned Werte und habe das über SPI auch so im DAC eingestellt. Ich sehe am Oszi auch den Sinus, Frequenz passt, Amplitude ist gut, wenn ich die Spannung je Kästchen klein genug wähle und die Zeit passend einstelle kann ich sogar die einzelnen Stufen sehen. Über den PATHSELECT Eingang am THS3215 kann ich einstellen ob das Signal durch einen externen Tiefpassfilter gehen soll oder nicht und auch das funktioniert, mit Filter sind die LSB Stufen fast nichtmehr erkennbar. So, was ist das Problem? Weil alle Werte in der Tabelle schön nacheinander durchlaufen werden sollte das auch ein schöner Sinus sein. Klar mit Stufen, aber eben ohne Sprünge. In der Simulation ist das auch so, aber in der Realität leider nicht. Im Bild ist schön zu sehen, dass da manche Werte nicht passen. Ich habe schon lange gesucht aber keinen Fehler gefunden. Wenn ich einen konstanten Wert anlege ist das Signal frei von Stufen. Wenn ich den Takt langsamer mache im AD9508 bleiben die Stufen, werden aber eben auch länger. Daraus folgere ich, dass es kein Timingproblem ist. Ich habe auch schon überprüft ob ich irgendwelche Bits verwechselt habe, also falsch am FPGA angeschlossen habe, aber das passt alles. Habt Ideen was das sein könnte? Vielen Dank!
Angehängte Dateien:
-
DAC_Stufen.png
53 KB
Hallo Gustl, könntest Du bitte noch den Schaltplan bzw. den relevanten Schaltplanausschnitt posten? Danke.
Treten diese Sprünge an allen vier OUTs (single) des DAC ebenfalls auf? Ist der Fehler auch im Differenzsignal pro OUT-Pärchen messbar?
Moin, Vielleicht hilfts zur Fehlersuche, wenn du in die Tabelle mal keinen Sinus, sondern einen Saegezahn reinbaust. Dann sollten evtl. Bitfehler/tauscher regelmaessiger im Ausgang erscheinen. Gruss WK
Gustl B. schrieb: > Wenn ich den Takt langsamer mache im AD9508 bleiben die Stufen, werden > aber eben auch länger. Daraus folgere ich, dass es kein Timingproblem > ist. In welchen Bereich läuft denn die Taktung bei deiner Scope-Aufnahme. Sind es die 25MHz der Stufung? Oder deckt bei dieser Messung eine Stufe gleich mehrere Takte ab? Wenn es wirklich die 25MHz sind, dann könnte ich mir bei deiner Betriebsart (DCO des DAC taktet FPGA) tatsächlich keine Setup-Hold Probleme erklären. Hast du im FPGA verschiedene Taktdomänen? Sind die Übergänge sauber synchronisiert? Gab es diesbezüglich keine Timingwarnungen (und auch keine in der Art wie "ungünstiger CLK-Eingang gewählt")? Kann es vielleicht Signalintegritätsprobleme bezüglich DCO geben? Ändern sich die Sprünge, wenn du DCO am FPGA-Eingang mit einem passiven Oszi-Tastkopf belastest (~20pF)?
An den einzelnen Ausgängen ist der Spannungshub echt klein laut Oszi, ja, die Sprünge sind da, gehen aber fast im Rauschen unter. ysfg schrieb: > Ist der Fehler auch im Differenzsignal pro OUT-Pärchen messbar? Was meinst Du damit? Ich habe leider keinen Differenztastkopf. Aber es gibt noch ein seltsames Verhalten. Ich verwende den DAC im Singe-Port Mode. Der ist im Datenblatt https://www.analog.com/media/en/technical-documentation/data-sheets/AD9743_9745_9746_9747.pdf auf Seite 25 rechts beschrieben. Jetzt lege ich das Signal IQSEL im FPGA fest auf eine '1' oder '0'. Aber ich beobachte, dass ich den Sinus auf beiden Ausgängen gleichzeitig sehen kann. Und zwar auch mit voller Amplitude, also nicht nur irgendwie eingekoppelt. So wie ich das verstehe dürfte der aber jeweils nur auf einem der Ausgänge zu sehen sein wenn ich IQSEL statisch mit '1' oder '0' belege.
Angehängte Dateien:
-
DAC_DCO.png
66 KB -
DAC_BIT0.png
52 KB
Achim S. schrieb: > Wenn es wirklich die 25MHz sind, dann könnte ich mir bei deiner > Betriebsart (DCO des DAC taktet FPGA) tatsächlich keine Setup-Hold > Probleme erklären. Moin! Also ich habe extern einen echt genauen 250 MHz Oszillator, der geht an den Taktteiler und daraus geht es dann an den DAC. Im Bildchen hatte ich das so geteilt, dass da 25 MHz zum DAC gingen. Aber die Stufenfehler sind bei jeder Frequenz da. Achim S. schrieb: > Hast du im FPGA verschiedene Taktdomänen? Ja, habe ich, aber an dieser Stelle ohne Übergänge. Ich nehme die Platine gerade in Betrieb und habe da nur die Tabelle und dann einen VHDL Process der mit DCO getaktet wird und die Daten ausgibt. Achim S. schrieb: > Kann es vielleicht Signalintegritätsprobleme bezüglich DCO geben? Ändern > sich die Sprünge, wenn du DCO am FPGA-Eingang mit einem passiven > Oszi-Tastkopf belastest (~20pF)? Nein. Im Anhang zwei Bildchen, einmal DCO und einmal das Bit0. Das ist auf der Platine direkt daneben geroutet (vielleicht etwas ungünstig, sehen aber beide OK aus).
Dass die Signale schön aussehen ist nur die halbe Miete. Wie liegen die Taktflanken bezogen auf die Datenflanken. Es geht da um Setup und Hold Zeit.
Leg doch mal 22pF von einer Datenleitung nach Masse. Ändert sich dann was? Sind manche Datenleitungen empfindlich?
Die Daten ändern sich schön mittig. Aber vielleicht habe ich zumindest einen Fehler gefunden: Im Single-Port Modus wechselt IQSEL dauernd zwischen high und low. Vielleicht darf man das einfach nicht statisch belassen. Der Plan: Ich liefere aus dem Taktteiler den doppelten Takt an das FPGA und verwende den um IQSEL zu toggeln und Daten anzulegen. Das Schöne ist hier auch, dass ich den Takt schön phasenverschieben kann mit dem Taktteiler. Das ist also phasenstarr (sagt man das so?) weil aus dem gleichen Oszillator aber eben frei verschiebbar. Dann brauche ich den DCO nicht, den kann ich nämlich nur im FPGA mit einer PLL verschieben. Das macht wenig Spaß, dem Taktteiler kann man einfach per SPI neue Werte schicken und schon ist der neue Takt da.
Helmut S. schrieb: > Wie liegen die Taktflanken bezogen auf die Datenflanken. Es geht da um > Setup und Hold Zeit. Auf die hätte ich auch zuerst getippt. Aber mit seiner speziellen Taktkette - DAC wird extern von AD9508 getaktet und speichert die Daten mit diesem Takt, - DAC erzeugt ~2ns verzögert einen Taktausgang DCO, - dieser DCO schaltet FPGA weiter ist er eigentlich auf der sicheren Seite. Zumindest wenn die Schaltzeiten von DCO-in auf Data-Out seines FPGAs nicht in den Bereich >30ns kommen. Gustl B. schrieb: > Im Anhang zwei Bildchen, einmal DCO und einmal das Bit0. Das ist auf der > Platine direkt daneben geroutet (vielleicht etwas ungünstig, sehen aber > beide OK aus). Wenn es ein Problem mit doppelten Flanken aufgrund von Reflektionen sein sollte, würdest du das mit dem 70MHz-Oszi ggf. nicht erkennen können (das FPGA ist da wesentlich schneller als dein Oszi). Mit etwas Fantasie könnte die Störung grob alle 8 Stufen wahrscheinlicher werden. Schau dir vielleicht mal D3 statt D0 an ob es da Auffälligkeiten gibt. Kannst du den Vorschlag von Der gute W umsetzen? Also eine lineare Rampe in den Kurvenspeicher setzen, die bei jedem Takt genau einen Schritt weiter zählt? Dann würden die einzelnen Bits sehr regelmäßig schalten und Fehler in der Bitfolge würden direkt ins Auge springen. Gustl B. schrieb: > Jetzt lege ich das Signal IQSEL im FPGA fest auf eine '1' oder '0'. Aber > ich beobachte, dass ich den Sinus auf beiden Ausgängen gleichzeitig > sehen kann. Und zwar auch mit voller Amplitude, also nicht nur irgendwie > eingekoppelt. So wie ich das verstehe dürfte der aber jeweils nur auf > einem der Ausgänge zu sehen sein wenn ich IQSEL statisch mit '1' oder > '0' belege. Sehe ich ebenso. Sehr seltsam. Gustl B. schrieb: > Im Single-Port Modus wechselt IQSEL dauernd zwischen high und low. > Vielleicht darf man das einfach nicht statisch belassen. Zumindest wurde in diesem AD-Forum mal behauptet, man dürfe es: https://ez.analog.com/data_converters/high-speed_dacs/f/q-a/22877/dac-part-ad9747-unused-channel-pin-configuration Aber die toggelnde Version mal auszprobieren ist trotzdem sinnvoll.
ARGH!!!! Die Bits 7 und 10 sehen nicht gut aus. Deren Rechteck ist jeweils mit dm des Anderen moduliert und ja die liegen genau nebeneinander unter dem FPGA. Tja ... mal gucken ob das jetzt mit reflow was wird.
Du hast vermutlich auch keine Serienterminierung in den Signalen...? Wenn dein FPGA es kann: spiele mal mit der Drive-Strength der Ports herum. Weniger ist oft mehr...
Ne, habe ich nicht. Das sind unter 2 cm Leiterbahnlänge. Also das Problem ist gelöst, ich habe den FPGA runtergenommen und einen neuen draufgesetzt. Jetzt ohne Kurzschluss drunter. Zumindest ist dieser Kurzschluss weg, vielleicht gibt es ja neue. Wegen der Heißluft musste ich auch die USB-C Buchse wechseln und ... das Zeug ist Müll. Das ist jetzt die 3. Buchse vom gleichen Hersteller und alle haben krass viel Spiel und zwar so viel, dass die USB-Verbindung wegbricht. Aber gut, das ist die einige USB-C Buchse, die ich mit den Design Rules von Beta Layout verwenden konnte. Alle besseren Buchsen fordern kleinere Bohrungen.
So, fertig. Jetzt funktionieren beide Kanäle des DACs getrennt wie man es sich wünscht. Ich teile die 250 MHz Clock durch zwei und füttere sie dem DAC. Das FPGA bekommt die vollen 250 MHz und gibt dem DAC dann die Werte. Mit der hohen Samplerate sind auch die Stufen so ziemlich komplett weg. Das Gesamtprojekt (wieder nur was privat zum Spielen) werde ich die Tage hochladen wenn ich den ADC in den Griff bekommen habe. Der ist ziemlich sehr verrauscht ... Ein weiteres Problem ist die Abwärme. Das wird zwar über USB versorgt und braucht keinen wirklich großen Strom, aber die Platine ist eher sehr klein und wird nach wenigen Minuten so warm, dass Anfassen schmerzt.
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.