EduBoard DE2-115 & DAC - erzeugtes Signal weicht erheblich von dem erwarteten ab

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Mahlzeit ihr liben,

ich sitze seit ca. einer Woche an einem, für mich unlösbarem, Problem.

Folgendes habe ich vor: Eine DDS soll auf einem FPGA Entwicklungsboard 
(hier: DE2-115) zusammen mit einem 14 Bit-DAC/ADC (THDB-ADA) realisiert 
werden.
Die verbauten Komponenten des DAC/ADC sind: AD9767 und AD9248 von Analog 
Devices.

Hierzu habe ich mir zwei Signale (Sinus- und Rechtech-Signal) mittels 
einer 9 Bit LUT erzeugt welche wie üblich durch eien Akkumulator 
angesteuert werden.
Dieser Akkumulator ist jeweils mit einer Schrittweite versehen, sodass 
ich die Frequenz in gewissen Breiten einstellen kann.

Nun wird mir aber anstelle des Rechteckssignals ein ganz anderes, 
periodisches, Signal ausgegeben.

Eigentlich würde ich Signale erwarten, wie sie auch auf den Bilder der 
Simulation (*TB)zu sehen sind.

Die verwendeten VHDL-Files und Testbenches habe ich mit angehängt

Die Datenblätter habe ich nun auch schon ausführlich studiert, komme 
jedoch nicht weiter.

Wenn ich das 14 Bit breiten Steuersignals für den DA-Wandler an LEDs 
anlege um zu verfolgen welche Werte ausgegeben werden entsprechen diese 
wiederum der Simulation.

Ich komme hier nun nicht mehr weiter.

Liegt es vielleicht daran, dass ich mein System Asynchron aufgebaut 
habe?
Denke ich eher wenig, lasse mich aber gerne eiens besseren belehren.

Danke schon einmal für eure Hinweise.

[Duke Scarring (Gast)]

Stephan K. schrieb:
> Liegt es vielleicht daran, dass ich mein System Asynchron aufgebaut
> habe?
Mit Sicherheit.
Der DAC arbetet nur sinnvoll, wenn man den mit dem richtigen Timing 
ansteuert.

    DAC_WRT_A <= CLK_50;
    DAC_CLK_A <= CLK_50;
    DAC_WRT_B <= CLK_50;  
    DAC_CLK_B <= CLK_50;

Welchen Modus verwendest Du? Interleaved oder dual?

Duke

[Dumdi D. (dumdidum)]

Bei squaure hast Du Dein Oszi auf AC und nicht DC gestellt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dumdi D. schrieb:
> Bei squaure hast Du Dein Oszi auf AC und nicht DC gestellt.
Glaube ich auch. Für einen falsch abgeglichenen Tastkopf ist die 
Frequenz noch zu niedrig...


BTW
Das ist echt übler STRG-C-STRG-V Stil:

    case acc is
      when "000000000" => square_out_tmp <= "11111111111111";
      when "000000001" => square_out_tmp <= "11111111111111";
      when "000000010" => square_out_tmp <= "11111111111111";
      :
      when "011111001" => square_out_tmp <= "11111111111111";
      when "011111010" => square_out_tmp <= "00000000000000";
      :
      when "111110001" => square_out_tmp <= "00000000000000";
      when "111110010" => square_out_tmp <= "00000000000000";
      when "111110011" => square_out_tmp <= "00000000000000";
      when others => square_out_tmp <= "00000000000000";

Und die Sinustabelle ist nicht viel besser wartbar:

    case acc is
      when "000000000" => sin_out_tmp <= "10000000000000";
      when "000000001" => sin_out_tmp <= "10000001100110";
      :
      :
      when "111110010" => sin_out_tmp <= "01111100110010";
      when "111110011" => sin_out_tmp <= "01111110011001";
      when others => sin_out_tmp <= "00000000000000";
    end case;

Das grenzt an sinnlose Arbeitszeitvergeudung und könnte ein Grund für 
eine Abmahnung sein... ;-)

Man kann den Sinus auch vom Compiler berechnen lassen. Sieh dir mal 
das da an:
http://www.lothar-miller.de/s9y/archives/37-DDFS-mit-BROM.html

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Duke Scarring schrieb:
> Der DAC arbetet nur sinnvoll, wenn man den mit dem richtigen Timing
> ansteuert.
>

>     DAC_WRT_A <= CLK_50;
>     DAC_CLK_A <= CLK_50;
>     DAC_WRT_B <= CLK_50;
>     DAC_CLK_B <= CLK_50;
>

> Welchen Modus verwendest Du? Interleaved oder dual?

Wichtige Info! Ich arbeite im "dual-port-mode". Habe mich mit dem Timing 
auch an der Doc vom AD9767 orientiert. Wie in Figure 26. Dual Mode 
Timing zu sehen sind die Signale dort ebenfalls so zugewiesen worden wie 
in meiner Schaltung. Das Datensignal schicke ich dabei mit der fallenden 
Flanke der Clock. Hierzu steht im Datenblatt, dass die Datenübergabe 
nahe der fallenden Clock-Flanke liegen sollte um genauere 
Signalübertragunen zu gewährleisten.

Dumdi Dum schrieb:
> Bei squaure hast Du Dein Oszi auf AC und nicht DC gestellt.

Sehr guter Hinweis, darauf hatte ich nicht weiter geachtet. Wobei man 
als erstes nachschaune sollte. ;) Merk ich mir.
Daran liegt es nu leider nicht. Auch bei der DC-Messung des 
Rechteck-Signals wird kein Rechtecksignal angezeigt.

Lothar Miller schrieb:
> Das ist echt übler STRG-C-STRG-V Stil

Naja, ich habe mir die LUTs mit einem m-script generieren lassen, wüsste 
nicht wieso das an einen üblen Stil oder sinnlose Zeitvergäudung 
erinnert, es ist immerhin "nur" eine LUT.

Ansonsten muss ich Recht geben. Den Sinus vom FPGA generieren lassen ist 
der elegantere Weg! Die angegebene Seite war mir dem entsprechend auch 
schon bekannt. Wollte mich nicht unvorbereitet an das Forum wenden.

Wie ist das den mit dem "Wartbar" gemeint? Generell einfacher halten um 
Fehler ausfindig zu machen?

Mommentan arbeite ich mich auch noch in das Thema ein. Ich bin von Haus 
aus Maschinenbauer und denke die nötige Erfahrung in einigen 
Monaten/Jahren auch erworben zu haben.

Soweit aber erst einmal lieben Dank für das Feedback!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stephan K. schrieb:
> Dumdi Dum schrieb:
>> Bei squaure hast Du Dein Oszi auf AC und nicht DC gestellt.
> Daran liegt es nu leider nicht. Auch bei der DC-Messung des
> Rechteck-Signals wird kein Rechtecksignal angezeigt.
Sondern was?

> mit einem 14 Bit-DAC/ADC (THDB-ADA) realisiert werden.
Hat die Karte Trafos im Ausgangspfad?
http://www.alteraforum.com/forum/archive/index.php/t-5957.html
So ein Trafo ist auch ein genialer Hochpass: weil er DC nicht übertragen 
kann, bleiben von deinem (für ihn ziemlich niederfrequenten) Rechteck 
nur noch die Flanken über...

> Wie ist das den mit dem "Wartbar" gemeint?
Naja, bei einer Formel siehst du sofort, ob da ein Sinus oder ein 
Dreieck oder sonstwas generiert wird. Bei diesem Scriptungetüm siehst du 
gar nichts. Ich musste da sogar noch die steigende Flanke im Rechteck 
suchen (hätte ja sein können, dass da ein asymmetrisches Rechteck 
erzeugt werden soll). Und sobald es mit "Herumsuchen" losgeht ist der 
Code nicht mehr übersichtlich.

> es ist immerhin "nur" eine LUT.
Und wie wird die implementiert?
Als RAM-Block?
Oder ressourcenfressend auf die LUTs der Logikblöcke verteilt?

> immerhin "nur" eine LUT.
BTW: du solltest im Zusammenhang mit FPGAs nicht von LUTs sprechen. 
Dieser Begriff ist für FPGAs schon belegt: eine LUT ist eine logische 
Einheit, die einem Logikzelle vor einem Flipflop sitzt. Sag also zu 
dieser Tabelle einfach Tabelle...

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Lothar M. schrieb:
> Sondern was?
Eben genau das gleiche, wie auch zuvor. Habe dieses nochmals mit halber 
Frequez aufgenommen.

>> mit einem 14 Bit-DAC/ADC (THDB-ADA) realisiert werden.
> Hat die Karte Trafos im Ausgangspfad?
> http://www.alteraforum.com/forum/archive/index.php/t-5957.html
> So ein Trafo ist auch ein genialer Hochpass: weil er DC nicht übertragen
> kann, bleiben von deinem (für ihn ziemlich niederfrequenten) Rechteck
> nur noch die Flanken über...

Genau darber bin ich gerade beim studieren der Dokumentation auch 
nochmals drüber gestolpert. Nach Abgleichen mit den Schaltplänen.. Ja, 
das Board hat nen Trafo. Nun ist's klar.

> Naja, bei einer Formel siehst du sofort, ob da ein Sinus oder ein
> Dreieck oder sonstwas generiert wird...sobald es mit "Herumsuchen" losgeht ist 
der
> Code nicht mehr übersichtlich.

Hmm, verstehe. Gut, danke für den Hinweies.

>> es ist immerhin "nur" eine LUT.
> Und wie wird die implementiert?
> Als RAM-Block?
> Oder ressourcenfressend auf die LUTs der Logikblöcke verteilt?

Tatsächlich noch als Ressourcenfressend auf die LEs verteilt.
Ist sicher auch beim compilieren schneller, wenn ich das anders löse.

>> immerhin "nur" eine LUT.
> BTW: du solltest im Zusammenhang mit FPGAs nicht von LUTs sprechen.
> Dieser Begriff ist für FPGAs schon belegt: eine LUT ist eine logische
> Einheit, die einem Logikzelle vor einem Flipflop sitzt. Sag also zu
> dieser Tabelle einfach Tabelle...

Okay, werd ich machen.


Dann wäre das Problem ja an sich gelöst.
Mit diesem AD-/DA-C wird das nichts mit einem hochfrequenten Rechteck, 
bedingt durch den Trafo..

Danke ihr!!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stephan K. schrieb:
> Mit diesem AD-/DA-C wird das nichts mit einem hochfrequenten Rechteck,
> bedingt durch den Trafo..
Mit einem richtig hochfrequenten Rechteck wird das schon was. Aber 
eben nicht mit deinem niederfrequenten 99kHz Signal...

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Ah stimmt, war gedanklich beim Tiefpass.

[J. S. (engineer)]

Dein Code sieht komisch aus. Sowohl die Sinustabelle, als auch der 
ansteuernde Vektor. Das mit den "Phase:  9 Bit (499 vales)" würde Ich 
mir auch nochmal durchdenken.

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Jürgen S. schrieb:
> "Phase:  9 Bit (499 vales)"

Hab die Tabelle mit einem MatLab- Skript erstellt, die 500 Werte in der 
Tabelle stimmen schon und ergeben eine ´komplette Periode. ich habe sie 
so konstruiert, damit ich bei einer 50 MHz Ckock beim durchlaufen auf 
geau 100 kHz komme.

Wie Lothar M. schrieb,  ist dies nicht ganz aus der Beschreibung 
ersichtlich.

Grüße, Stephan

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stephan K. schrieb:
> die 500 Werte in der Tabelle ... ergeben eine komplette Periode.
Du solltest hier ein wenig Binärer denken.

> ich habe sie so konstruiert, damit ich bei einer 50 MHz Ckock
> beim durchlaufen auf geau 100 kHz komme.
Das sind doch irgendwelche zufällig gewählten Werte. Du bekommst nämlich 
schon keine "genauen" 100kHz, weil der Quarz nicht so genau ist. Du 
bekommst je nach Qualität des Oszillators dann 99999995 Hz oder 
100000005 Hz.
Du hättest die 100kHz also sicher auch so wählen können, dass du mit 512 
Stützpunkten in der Tabelle arbeiten könntest und den Wrap-Around 
kostenlos bekämst...

[Duke Scarring (Gast)]

Lothar M. schrieb:
>> ich habe sie so konstruiert, damit ich bei einer 50 MHz Ckock
>> beim durchlaufen auf geau 100 kHz komme.
> Das sind doch irgendwelche zufällig gewählten Werte. Du bekommst nämlich
> schon keine "genauen" 100kHz, weil der Quarz nicht so genau ist. Du
> bekommst je nach Qualität des Oszillators dann 99999995 Hz oder
> 100000005 Hz.

Alles richtig, was Ihr schreibt, aber:
es kann - je nach Anwendung - auch wichtig sein, das die 100 kHz durch 
einen richtig glatten Teiler aus den 50 MHz erzeugt werden müssen.

Wenn der Teiler 'leicht' krumm ist, stimmt zwar die erzeugt Frequenz auf 
den ersten Blick, aber bei synchronen Langzeitmessungen sieht man die 
Abweichung.
Auch wenn es nur wenige ns pro Stunde sind. BTDT.

Wie gesagt, im Prinzip nur relevant, wenn auch andere Teile aus dem 
selben Referenztakt versorgt werden und das Ganze synchron laufen muss.

Duke

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Duke Scarring schrieb:
> Alles richtig, was Ihr schreibt, aber:
> es kann - je nach Anwendung - auch wichtig sein, das die 100 kHz durch
> einen richtig glatten Teiler aus den 50 MHz erzeugt werden müssen.
>
> Wenn der Teiler 'leicht' krumm ist, stimmt zwar die erzeugt Frequenz auf
> den ersten Blick, aber bei synchronen Langzeitmessungen sieht man die
> Abweichung.
Richtig. Ich meinte auch, dass dann eben mit 50MHz Takt und 512 
Stützpunkten eine "gewünschte" Frequenz von 97656250 Hz gänzlich ohne 
Jitter herauskommt.

> Auch wenn es nur wenige ns pro Stunde sind. BTDT.
Da hast du aber einen recht guten Oszillator gehabt, wenn der noch 
genauer als 0,000001 ppm war... ;-)

[Duke Scarring (Gast)]

Lothar M. schrieb:
> Da hast du aber einen recht guten Oszillator gehabt, wenn der noch
> genauer als 0,000001 ppm war... ;-)
Schön wär's.
Selbst der beste Oszillator den ich hier habe, darf inzwischen 0,02 ppm 
Frequenzabweichung haben.

Mir ging es nicht um die absolute Frequenz, sondern darum, das die 
Flanke des generierten Signals nach Stunden noch im 'gleichen' Abstand 
zur Flanke des Referenzsignals steht.
Das 'gleich' wird natürlich durch Jitter verwischt.

Duke

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Lothar M. schrieb:
>> die 500 Werte in der Tabelle ... ergeben eine komplette Periode.
> Du solltest hier ein wenig Binärer denken.

Wie ist das mit dem "Binär denken" gemeint?
So, dass ich immer die volle Auflösung ausnutze?

[Duke Scarring (Gast)]

Stephan K. schrieb:
> Wie ist das mit dem "Binär denken" gemeint?
Das Du z.B. 2^9 Werte nimmst.

[Stephan K. (Firma: FAU Erlangen) (sofa1780)]

Duke Scarring schrieb:
> Stephan K. schrieb:
> Wie ist das mit dem "Binär denken" gemeint?
>
> Das Du z.B. 2^9 Werte nimmst.

Mir erscheint nur nicht klar, welche Vorteile ich dadurch haben sollte, 
bzw. welche Nachteile, wenn ich nicht den vollen Werte Bereich nutze.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Der wesentliche Vorteil ist, dass du den Zähler ohne Vergleicher einfach 
durchlaufen lassen kannst. Wenn du mal ein richtig schnelles Design 
brauchst, dann ist das von Vorteil. Und wenn du kein schnelles Design 
brauchst, dann solltest du es wenigstens wissen,  wie es ginge, wenn du 
es bräuchtest...

Mit dieser Binärdenkweise werden viele übrigens viele Designs fast 
automatisch übersichtlicher und einfacher.