DDS mit DE0-Nano Board nur niedrige Frequenzen?

Hier nun dazu ein paar Oszillogramme!
Die letzten beiden sollten eigentlich 3,2kHz sein.
Die davor alle 200Hz!

Thomas Reinemann schrieb:
> Wenn du Timing-Probleme hast, sagt das dir Quartus.

Ja, weiss aber nicht wie ich die beheben kann?
Meldung:
Critical Warning (332148): Timing requirements not met
Wo kann ich da denn überhaupt rumspielen, um das zu beheben?

Thomas Reinemann schrieb:
> Das sagt dir die Simulation. Hast du dein Design simuliert?

Ja Modelsim lief drüber und habe meine Ausgangsdaten für mehrere 
"Schrittweiten" überprüft -> z.B. keine Phasensprünge am Ende des 
Tabellendurchlaufs!


Thomas Reinemann schrieb:
>> Ich kann somit theoretisch mit einer Schrittweite von 200Hz Frequenz
>> unterhalb von fs/2 also 192kHz generieren.
>
> Was willst du uns damit sagen?

Was meine Intention ist! mehr nicht!


Viele Grüße
AV

Was soll die -12 in dieser Zeile?
Wenn SINE_INDEX_OLD kleiner 12 ist, wird nicht korrekt auf die Tabelle 
zugefriefen.

1

           DIN(31 downto 0) <= sine_LUT(SINE_INDEX_OLD-12);

Lothar Miller schrieb:
> Hört sich umständlich an. VHDL kann auch rechnen. Siehe dort in der
> Mitte:
> http://www.lothar-miller.de/s9y/archives/37-DDFS-m...

so ich bin nun halbwegs dahinter gestiegen, wie Du Dir das mit deiner 
DDFS gedacht hast. Ein pi/2 Sinus zu verwenden ist ja schon mal gut 
aber, das mit dem Signal "Accum" ist mir nicht ganz klar:
Warum ist das genau 21Bit lang? Wie erhöhe ich dort denn die 
Schrittweite, also den Index aus der Sinustabelle "Rom64x8"?
Es wird dort ja nur mit
Accum <= Accum + unsigned(Freq_Data)
der hintere (LSB) Teil von Accum um Freq_Data erhöht, später jedoch
werden mit
z.B.
Accum(Accum'high-2 downto Accum'high-7) ... die Bits 18 bis 13 in 
"Address'" kopiert/zugewiesen! ?
Accum hat also lange Zeit bis diese Bit überhaupt von Freq_Data erhöht 
werden den Wert "0"!?
Den Bit 18 bis 13 bleiben ja durch das Accum <= Accum + 
unsigned(Freq_Data) lange Zeit unbeeinflusst?

Tutorial zur DDS:

http://www.analog.com/static/imported-files/tutorials/450968421DDS_Tutorial_rev12-2-99.pdf

Wird zwar immer wieder bezug auf (ältere) Analog Devices Bauteile 
genommen, ist aber trotzdem allgemein genug.

Atmega-Verleger schrieb:
> Accum(Accum'high-2 downto Accum'high-7) ... die Bits 18 bis 13 in
> "Address'" kopiert/zugewiesen! ?

Ok kann mein Problem nun besser umschreiben und habe es in Modelsim 
simuliert!
Das Signal "Accum" müsste also nur 8Bit lang sein ! So wird die 
Schrittweite, mit der der Viertelsinus durchlaufen wird um Freq_Data 
erhöht. Der maximale Wert (ohne Alias) wäre dann bei 31!
Die genierte Frequenz wäre dann (also in diesem Fall bei einer 64 
Elemente langen Liste!) bei (Freq_Data/64)*fs , wobei fs die 
Abtastfrequenz der Datenausgabe ist!
klingt das halbwegs plausibel?
Oder sehe ich da etwas noch nicht?


Änderung:

signal Accum : unsigned (20 downto 0) := (others=> '0');"
zu
signal Accum : unsigned (7 downto 0) := (others=> '0');"

Atmega-Verleger schrieb:
> Die genierte Frequenz wäre dann (also in diesem Fall bei einer 64
> Elemente langen Liste!) bei (Freq_Data/64)*fs , wobei fs die
> Abtastfrequenz der Datenausgabe ist!

Da wir ja von nem Viertelsinus ausgehen, müsste dann ja die Frequenz 
doch so berechnet werden:
(Freq_Data/(64*4))*fs
Die generierte Frequenz hängt ja von den Werten des "gedachten" vollen 
Sinuses ab! ?

Lothar Miller schrieb:
> Dabei ist es letzlich egal, ob ein Viertel oder Halbsinus oder ein
> ganzer Sinus betrachtet wird. Denn letzlich ist das nur eine andere
> Verwendung der beiden führenden Bits des Akkus (MSB=pos/neg,
> MSB-1=Tabellenzugriff "von vorn"/"von hinten"). Du solltest/kannst also
> für deine Betrachtungen von einem kompletten Sinus in der Tabelle
> ausgehen.

Ja das stimmt schon und ist mir auch klar!

Also du hast aber einen ACCUM wie folgt:

x"0  0  0  0| 0  0  0  0| 0  0  0  0 |0 0 0 0|0 0 0 0| 0" 21 Bits
 20  19 18 17 16 15 14 13 12 11 10 9  8 7 6 5 4 3 2 1  0 Bitnummern
dann Freq_Data->x"0000|000|0"
Freq_Data wird zu ACCUM addiert also zu den Bits 7 bis 0!
in Address werden aber Bit 18 13 gespeichert!
Bit 19 ist in der Tat für die Unterscheidung, von welcher Seite die 
Tabelle
gelesen werden soll und Bit20 ist das eigentliche Vorzeichen-Bit!

Ich kann aber mit meiner Tabelle nur Frequenzen generieren, die wie 
folgt  berechnet werden (1/4*Tabellenlänge)*fs--> kleinste generierbare 
Frequenz! also jeder Wert einer Sinustabelle wird ausgegeben! bei der 
Viertelsinustabelle wird dann jeder Wert pro Ausgabesinus 4mal ausgegen 
(natürlich mit entsprechender Vorzeichen und Quadrantenanpassung) !!!!
So mein Gedanke!!!

Accum ist also zu lang! muss nur 8 Bit lang sein!

Lothar Miller schrieb:
> Ein kompletter Zyklus ist nach einmaligem Durchlaufen des kompletten
> Akkus erledigt. Die "unnötigen" Bits im Akku "vor" dem Tabellenindex
> sind einfach Vorteilerbits...

wozu so viele "vorteiler" bits?

Lothar Miller schrieb:
> Damit man auch mit einer hohen Taktfrequenz (z.B. 50MHz) auf niedrige
> Ausgabefrequenzen (z.B. 2Hz) kommt. Und so auch auf kleine
> Frequenzschritte, wenn das Signal Freq_Data um 1 incrementiert wird...

Dann (also Freq_Data = 1) dann würde auch immer ein "beträchtlicher" 
Anteil der Frequenz (1/(4*Tabellenlänge)*fs im Ausgangssignal vorhanden 
sein?
Entsprechendes Interpolationsfilter notwendig?

Lothar Miller schrieb:
> "Störfrequenzen" kommen bei der DDFS von den "Stufen" des
> Digitalsignals. Du musst also nur die Schritte klein genug machen (und
> damit für die selbe Ausgangsfrequenz viel schneller durch die Tabelle
> laufen), dann verschwinden diese Frequenzen immmer weiter.
> Aber bei einer 8 Bit ist dieser Störpegel schon 8*6dB = 48dB vom
> Nutzpegel entfernt. Und zudem ist die Störfrequenz um den Faktor
> "Tabellenlänge" (*1,*2 oder *4) höher als die Nutzfrequenz...

Ich hab mir mal das ganze umgemodelt auf 32 Bit und werde sollte ich
niedrigere Frequenzen ausgeben wollen eine längere Tabelle verwenden!
Zumindest als nächsten Schritt!

Ok hab jetzt alles umgebaut und in Quartus 2 synthetisiert (vorher mit 
Modelsim simuliert)
irgendwie sehen die ausgegebenen Signale noch immer so aus!

Gibt es eine Möglichkeit, die Modelsim-Daten also die 32Bit-Werte in 
eine Datei zu leiten, um die dann grafisch darzustellen?
Ansonsten etwa doch Timing-Probleme zumindest sagt das die Quartus 2 
Software genauso wie beim vorherigen Versuch?

Mit Glück kann ich nächste Woche das mal auf 'nen Xilinx Spartan3 
testen!

Hallo,
hier nochmal die Oszillogramme zu meinen Versuchen, 3kHz bzw. 6kHz 
auszugeben!
Da stellt sich mir nun zwingend die Frage nach dem Datenexport bei 
Modelsim?

ja, gibt es: filereader funktion.

Uli schrieb:
> ja, gibt es: filereader funktion.

mal ausprobieren... morgen oder Montag!

Atmega-Verleger schrieb:
> mal ausprobieren... morgen oder Montag!

So ich hab es jetzt mal ausprobiert (gestern + heute), also die 
Simulationsergebnisse aus dem Modelsim-List-File gelesen, in MatLab 
eingelesen und grafisch dargestellt!

Die Schrittweite (FREQ_DATA/FREQ_INC) ist in diesem Fall x"02"!
Somit ist das Modul "funktional" korrekt! ah, mir gehen die Optionen 
aus!
Als nächstes auf'm Spartan ausprobieren... sinnvoll?

Lothar Miller schrieb:
> Atmega-Verleger schrieb:
>> Als nächstes auf'm Spartan ausprobieren... sinnvoll?
> Wenn die Simulation sagt: "Alles ok", dann kannst du auf die Hardware
> gehen...

Und dann zuallererst das hier beheben, sonst kommt potentiell eh nur 
Mist raus:

Atmega-Verleger schrieb:
> Critical Warning (332148): Timing requirements not met

Witz:
Lothar's LUTs können 1920 Werte Speichern :)

Klaus schrieb:
> Und dann zuallererst das hier beheben, sonst kommt potentiell eh nur
> Mist raus:
>
> Atmega-Verleger schrieb:
>> Critical Warning (332148): Timing requirements not met

OK hab jetzt mal den TImeQuestTimingAnalyzer von Quartus 2 verwendet und 
dort meine Clocks angegeben d.h. CLK, BCK_OUT und LRCK_OUT mit der 
jeweiligen
Frequenz definiert und siehe da: nur noch eine "Critical Warning" aber 
eine böse!

1

Critical Warning (308042): (High) Rule C105: 

2

  Clock signal should be a gobal signal. (Value defined:25). 

3

  Found 1 node(s) related to this rule.

4

Critical Warning (308012): Node "CLK"

also ich soll das CLK auf "global" setzen weiss aber nicht wie..... 
angeblich
unter "Assignments -> Assignments Editor" ??

Atmega-Verleger schrieb:
> also ich soll das CLK auf "global" setzen weiss aber nicht wie.....
> angeblich
> unter "Assignments -> Assignments Editor" ??

Ok konnte meinen CLK nun als global festlegen---> keine kritischen 
Warnungen mehr!
Das allein hat nichts gebracht! Daher habe ich den Oszillator, der in 
der Nähe vom DAC platziert war direkt am FPGA Board angebaut, generiere 
den Takt dort direkt für das FPGA-Board..... der DAC bekommt dann sein 
CLK von nem anderen Ausgang des FPGA-Board "CLK_OUT".
Dachte, so könnte ich ein wenige gegen Verzögerungen zwischen den 
einzelnen CLKs wirken!
Leider ist das DAC Ausgangssignal immer noch "bescheiden"!!!

Läuft dein Eingangstakt über eine PLL im FPGA?

Lothar Miller schrieb:
>> Leider ist das DAC Ausgangssignal immer noch "bescheiden"!!!
> Lass einfach mal einen Zähler zählen und sieh dir dessen Bits an.
> Jittern die auch?

Hab das größte Problem endlich gefunden!

Es lag am DAC "PCM5142"
Der hat intern Interpolationsfilter 8x und 16x
Einstellbar über Register 34 page 0.
Ich habe den Auf 16x gehabt!!! Nun mal auf 8x ausprobiert und nun läufts 
kann
nun auch Frequenzen im gewünschten Kilohertzbereich generieren!

Beste Grüße an dieser Stelle auch
and "Alfred Banause"

Hallo ich hab da nun mal ein Problem bzgl. des DDS(DDFS) Modulus von 
Lothar Miller!

Ich wollte das DDS Modul so anpassen, dass ich nicht nur "Listen" mit 
einer Länge einer Zweierpotenz anlegen muss!
Also ich wollte Listen mit einem Vielfachen der Abtastrate von 384kHz 
anlegen
also hier z.B.
7680 Werte daraus folgt dann eine pi/4-Liste mit 1920 Werten!

das folgende habe ich dann im Modul ergänzt/geändert:

   process begin
     wait until rising_edge(CLK);
     if BCK = '1' then
     ACCUM_TMP <= ACCUM;  -- Wert von ACCUM einen Takt lang speichern
     if (DIN_CNT = DIN_CNT_MAX-1) then
        QUADRANT <= "00";
        SIGN <= '0';
        if (ACCUM >=1920) then
          QUADRANT <= "01";
          SIGN <= '0';
        end if;
        if (ACCUM >= 3840) then
          QUADRANT <= "10";
          SIGN <= '1';
        end if;
        if (ACCUM >= 5760) then
          QUADRANT <= "11";
          SIGN <= '1';
        end if;
      end if;
    end if;
   end process;


   --QUADRANT <= ACCUM(ACCUM'left-1);
  process begin
   wait until rising_edge(CLK);
    case QUADRANT is
        when   "00" => ADDRESS <= ACCUM_TMP;  -- erster Quadrant
        when   "01" => ADDRESS <= 3840-ACCUM_TMP; -- zweiter Quadrant
        when   "10" => ADDRESS <= ACCUM_TMP-3840; -- dritter Quadrant
        when   "11" => ADDRESS <= 7680-ACCUM_TMP; -- vierter Quadrant
        when others => ADDRESS <= 0;
    end case;
  end process;

leider rechnet der nicht richtig!
ich laufe immer aus dem Indexbereich von 0... 1919 raus?
nutze hier nur noch integer!
Die Ausgabe also ob positiv oder negativ ist wie im original DDFS.vhd!

Hmmh ich hab das jetzt wie unten angefügt aufgebaut!
Aber der läuft immer noch in den Index 2000! erreicht also den Fall für 
den zweiten Quadranten nicht rechtzeitig? ob wohl doch
"QUADRANT" und "ACCUM_TMP" zusammengehörig sein sollten, also beide 
Signale passen zum selben Takt?


  process begin
     wait until rising_edge(CLK);
     if BCK = '1' then
     ACCUM_TMP <= ACCUM;  -- Wert von ACCUM einen Takt lang speichern
     if (DIN_CNT = DIN_CNT_MAX-1) then
        if ((ACCUM >= 5760) and (ACCUM < 7680)) then
          QUADRANT <= "11";
          SIGN <= '1';
        elsif ((ACCUM >= 3840) and (ACCUM < 5760)) then
          QUADRANT <= "10";
          SIGN <= '1';
        elsif ((ACCUM >=1920) and (ACCUM < 3840)) then
          QUADRANT <= "01";
          SIGN <= '0';
        elsif ((ACCUM >= 0) and (ACCUM < 1920)) then
          QUADRANT <= "00";
          SIGN <= '0';
        else
          QUADRANT <= "01";
          SIGN <= '1';
        end if;
      end if;
    end if;
   end process;


   --QUADRANT <= ACCUM(ACCUM'left-1);
  process begin
   wait until rising_edge(CLK);
    case QUADRANT is
        when   "00" => ADDRESS <= ACCUM_TMP;  -- erster Quadrant
        when   "01" => ADDRESS <= 3840-ACCUM_TMP; -- zweiter Quadrant
        when   "10" => ADDRESS <= ACCUM_TMP-3840; -- dritter Quadrant
        when   "11" => ADDRESS <= 7680-ACCUM_TMP; -- vierter Quadrant
        when others => ADDRESS <= 0;
    end case;
  end process;

Wie gross ist denn das Inkrement? Ist das nur einen Takt zu spät, oder 
mehrere?

Zeige mal eine Simulation

Oli schrieb:
> Wie gross ist denn das Inkrement? Ist das nur einen Takt zu spät, oder
> mehrere?

Das Inkrement liegt bei "200"! un er sagt mir bei der Simu, dass 2000 
nicht im Bereich von 0 bis 1919 liegt! Eine wahre Aussage!
Das heißt aber auch, dass der nicht rechtzeitig in den "Fall" für den 
zweiten
Quadranten wechselt?

Oli schrieb:
> Zeige mal eine Simulation

Kann ich jetzt gerade nicht, sitze leider vor nem anderen Rechner... 
morgen!

Jürgen S. schrieb:
> Ohne vollständigen Code und Sim ist da herzlich wenig zu sagen, fürchte
> ich. Gfs liegt es an der "DIN_CNT = DIN_CNT_MAX-1" die die Bedingung in
> den Abfragen überspringt.

Ah die Abfrage von QUADRANT mache ich ja in nem getakten Prozess mit 
CLK!
und QUADRANT bekommt zu der Bedingung DIN_CNT = DIN_CNT_MAX-1 neue Werte 
zugewiesen.
Hmmhh dann könnte das Problem ja auch daran liegen, dass ich auc die 
Abfrage
von QUADRANT zu der Bedingung "DIN_CNT = DIN_CNT_MAX" machen muss? oder
ich takte den Prozess zum Abfragen von QUADRANT gar nicht und packe 
QUADRANT in die Sensitivitätsliste?
Mal sehen heute abend mal ausprobieren und ggfs. poste ich mal mehr 
Code!

Lothar Miller schrieb:
>> Das Inkrement liegt bei "200"!
> Wozu hast du denn 1920 Stützstellen im Viertelkreis, wenn du nur 0,5%
> davon verwendest?

Ich habe jetzt ein Inkrement von 200 will aber das Modul auch für andere 
Frequenzen verwenden, dafür muss das Inkrement dann aber höher bzw. 
niedriger sein!

Lothar Miller schrieb:
> Aber m.E. liegt das Problem etwa hier:

1

      if ((ACCUM >= 5760) and (ACCUM < 7680)) then

2

>           QUADRANT <= "11";

3

>           SIGN <= '1';

4

>         elsif ((ACCUM >= 3840) and (ACCUM < 5760)) then

5

>           QUADRANT <= "10";

6

>           SIGN <= '1';

> Eine DDFS sollte vorteilhafterweise so an den Binärgrenzen angelegt
> werden, dass ein solches Herumgewürge nicht nötig wäre...
> Insbesondere, wenn du soweiso mit RIESENSCHRITTEN quer durchs RAM
> rennst:

Und ja mir ist klar, dass es sonst besser wäre sich an Zweierpotenzen zu 
halten. Ich wollte aber Vielfache von 384 haben. Das ist die Abtastrate 
und so sind "ganzzahlige" Frequenzschritte möglich!

Ok zumindest hätte ich hier andere Grenzen setzen müssen:

1

  process begin

2

   wait until rising_edge(CLK);

3

    case QUADRANT is

4

        when   "00" => ADDRESS <= ACCUM_TMP;  -- erster Quadrant

5

        when   "01" => ADDRESS <= 3839-ACCUM_TMP; -- zweiter Quadrant

6

        when   "10" => ADDRESS <= ACCUM_TMP-3840; -- dritter Quadrant

7

        when   "11" => ADDRESS <= 7679-ACCUM_TMP; -- vierter Quadrant

8

        when others => ADDRESS <= 0;

9

    end case;

10

  end process;

also in Fall "01" 3839 statt 3840 und in
Fall "11" 7679 statt 7680

aber da das tatsächlich nur Probleme gibt werde ich doch wieder auf
ein System mit Zweierpotenzen wechseln. Die "kleine" Ungenauigkeit ist 
dann auch noch gut in Kauf zu nehmen!

Irgendwie ist mir nicht klar, wie Du mit 200er Schritten die Grenzen 
erreichen willst und wozu es dann einer 386er Teilung braucht.