Generierung Rechtecksignal-overflow flag

[Kersty F. (kersty_f)]

Hallo Zusammen,

Ich implementiere für meine Masterarbeit einen Funktionsgenerator auf 
einem FPGA. Bin aber noch VHDL Anfängerin. Die Generierung des Sägezahns 
hat geklappt. ich hänge bei der Rechteck-Generierung.
Das ist mein Code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--USE ieee.std_logic_arith.ALL;
USE ieee.std_logic_unsigned.ALL;
use IEEE.numeric_std.all;

entity DDS1T2 is
 Port (
 --Takteingang
clk           :in std_logic;                           --Systemtakt legt d. max. synth. Frequenz fest, 125MHz
--Signaleingänge
Phase         :in std_logic_vector(14-1 downto 0);      --Channel 1
DutyCycle  : in std_logic_vector(10-1 downto 0);         --Wert bestimmt Tastgrad
Slope      : in std_logic_vector(10-1 downto 0);         --Wert bestimmt Flankensteilheilt
--Signalausgang
Ch_out        :out std_logic_vector(14-1 downto 0)      --Channel 
);
end DDS1T2;

architecture Behavioral of DDS1T2 is
--interne Hilfssignale
signal phase_vorher   : std_logic_vector(14-1 downto 0);            --Initialisierung das bei 1 direkt VGL erfolgt (:=)
signal ce             : std_logic;                                  --clock enable
signal Y              :unsigned(14-1 downto 0) := (others => '0') ;
                       
--Verarbeitung Eingangs- und Hilfssignale
begin
process(clk)
begin
if rising_edge(clk) then
    phase_vorher <= Phase;                   --setzten des Hilfsvektors
    -- Erzeugung clock enable "ce"
    if Phase /= phase_vorher then           --Vergleich
        ce <= '1';
     else
        ce <= '0';
    end if;
                     
 end if;
 end process;
    
 process(clk)
 begin
 if rising_edge(clk) then
 --Generierung der Treppenfunktion
    if ce = '1' then
      -- Ein Durchlauf pro Phasenwert
    if Phase< DutyCycle then
    --erste Halbwelle
      Y <= Y + unsigned(Slope);
      --Bereichsüberlauf, overflow flag setzten (definieren)
        if y = 16384 then
         y <=(others =>'0') ;   
          
    else 
    --zweite Halbwelle
      Y <= Y - unsigned(Slope);
        if y =0 then
           y <= (others=>'1');
              
        end if;
        end if;
    end if;
    end if; -- ce
 end if; -- clk
 end process; 
 
 
 --Signalausgabe
 Ch_out <= std_logic_vector(Y);          

end Behavioral;

Mein Problem sin die Start/Stop Kriterien um ein overflow flag zu 
denfinieren. Könntet ihr mir bitte dabei weiter helfen? So wie der Code 
jetzt ist, funktioniert er nicht.

Ich bin für jeden Tipp und jeden Hinweis dankbar.
viele Grüße
Kersty

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

Kersty F. schrieb:
> ich hänge bei der Rechteck-Generierung.
Du willst da ein Rechteck mit einstellbarer Tastverhältnis und 
Flankensteilheit machen? Für welche(n) Frequenz(bereich) mit welcher 
Taktfrequenz? In welchem Bereich soll die Flankensteilheit definiert 
werden können?

Dir ist schon klar, dass du ein lustiges Signal bekommst, wenn die 
Frequenz, das Tastverhältnis und die Flankensteilheit passend gewählt 
sind. Das ist dann so eine Art ansteigender/abfallender Sägezahn.

> Mein Problem sin die Start/Stop Kriterien um ein overflow flag zu
> denfinieren. Könntet ihr mir bitte dabei weiter helfen?
Ich würde da einfach mal ein Rechtecksignal mit der gewünschten Frequenz 
(und Phasenlage/Offest) erzeugen.

Und wenn ich das dann habe, dann würde ich die Rampe per simplem 
sättigendem Zähler hinzufügen.

Wie sieht denn die ursprüngliche Aufgabenstellung aus?

[Falk B. (falk)]

Kersty F. schrieb:
> Ich bin für jeden Tipp und jeden Hinweis dankbar.

Mach es wie die Profis mit den preiswerten Funktionsgeneratoren. Die 
haben eine Tabelle in einem BRAM und geben die einfach aus. Wenn die 
Signalform variabel sein soll, muss die meist ein Mikrocontroller neu 
berechnen bzw. laden. Natürlich kann man variable Rampen und Rechtecke 
auch mit einer VHDL-Turnübung erzeugen, als Trainig ganz nett. Aber so 
wirklich sinnvoll erscheint es nicht.

Wenn man es denn WIRKLICH in VHDL machen will, würde ich trotzdem einen 
BRAM nehmen und mittels State machine füllen. Dies FSM muss vier Phasen 
an Daten dort einfüllen.

Ansteigende Rampe
Plateu 1
Fallende Rampe
Platea 2

Das kann man mittels Akkumulator ala DDS machen, den man mit 
unterschiedlichen FTW (frequency tuning word) füttert, damit erzeugt man 
die Rampen.
Diese Daten gibt man dem VHDL Modul sinnvollerweise von außen fertig 
vor, denn das Umrechnen von Tastgrad in Anstieg und zeiten ist 
aufwändig. Dafür verschwendet man keine Harware. Oder nur zu Lehrzwecken 
und als Turnübung.

[Kersty F. (kersty_f)]

Danke für die Unterstützung.



zu Lother
> Du willst da ein Rechteck mit einstellbarer Tastverhältnis und
> Flankensteilheit machen? Für welche(n) Frequenz(bereich) mit welcher
> Taktfrequenz? In welchem Bereich soll die Flankensteilheit definiert
> werden können?
>
Taktfrequenz ist 25MHz bedingt durch das Redpitaya Board und das v0.92 
projekt. ADC hat eine Auflösung von 14 Bit.



Ich arbeite zunächst mit dem vio und dem clockwizzard, schreibe auf den 
FPGA via extention connector. Sobald Rechtecksignale und sinus generiert 
werden, werde ich das in das fertige v0.92 open source project 
einbinden.

> Dir ist schon klar, dass du ein lustiges Signal bekommst, wenn die
> Frequenz, das Tastverhältnis und die Flankensteilheit passend gewählt
> sind. Das ist dann so eine Art ansteigender/abfallender Sägezahn.
>
ja das ist richtig

Aufgabenstellung ist die Generierung von Rechtecksignalen und dem Sinus 
mit phasenverschiebung, veränderlicher flankensteilheilt, veränderlichem 
tastgrad, sinus soll (im ideal Fall) angeschnitten sein, alles für 
zukünftige Test von Baugruppen, die im Zug die Signale von 
(Wegimpulssensoren, verschiedene Impulsgeber) aufnehmen (schreibe in 
einem Betrieb).
Ich habe  mit dem Block DDS1Teil1 angefangen, in dem ich einen Zähler 
definiert habe, der den Sägezahn generiert und eine phasenverschiebung.
hier ist der code (sorry die Kommentare sind bissl durcheinander):

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--USE ieee.std_logic_arith.ALL;
USE ieee.std_logic_unsigned.ALL;
use IEEE.numeric_std.all;

entity DDS1Teil1 is
--generic(DataWidth : integer);
port(
clk           :in std_logic;                                  --Systemtakt legt d. max. synth. Frequenz fest, 25MHz, --nicht 25 sondern 125MHZ!!
a_reset       :in std_logic;                                  --Resetsignal, low aktiv, bei 0 Phaenaccu auf 0 gesetzt und der ganze Automat steht 
f_DDS         :in std_logic_vector(32-1 downto 0);       
--FTW(freqeuncy tuning word), Abstimmungswort ermittelt durch Bitbreite, 10 bit, 2^10=1024 Stützstellen und Taktfreqeunz, f_out
--
Dphi          :in std_logic_vector(32-1 downto 0);             --Phase zwischen Ch1 und Ch2
Phase_ch1         :out std_logic_vector(14-1 downto 0);        --Channel 1
Phase_ch2         :out std_logic_vector(14-1 downto 0)         --Channel 2
);             
end DDS1Teil1;

architecture Behavioral of DDS1Teil1 is

signal phasenaccu :unsigned(32-1 downto 0);                     -- Zähler mit 2^32 Zuständen, counter with states
signal phasenaccu_ch2    :unsigned(32-1 downto 0);
--signal out_Dphi   :unsigned(32-1 downto 0);
begin
-- nco= numerically controlled oscillator
--Zähler zum generieren der Sägezahnfunktion/ counter to generate a sawtooth wave (saw wave)
nco: process(clk, a_reset)
begin
    if a_reset = '0' then                                      --Reset signal defines start value, if reset=0 then
      phasenaccu <=(others => '0');                          --all signals of phasenaccu are set to o
     elsif rising_edge(clk) then                                -- moreover of risng_edge(clk) then start to count
      phasenaccu <= phasenaccu +unsigned(f_DDS);             --phase accumulater, counter
    phasenaccu_ch2 <= phasenaccu+unsigned(Dphi);           -- phase shift channel 2
    end if;
end process;

Phase_ch1 <=  std_logic_vector(phasenaccu(31 downto 18));       --either 0 or the counter with 13 bits is assigned to the output signal
--S_ch2 <= '0' & phasenaccu(31 downto 19);
Phase_ch2 <=  std_logic_vector(phasenaccu_ch2(31 downto 18));   -- either 0 or the counter with 13 bits and a phase shift is assigned to the output signal

end Behavioral;

> Ich würde da einfach mal ein Rechtecksignal mit der gewünschten Frequenz
> (und Phasenlage/Offest) erzeugen.

> ja das ist mein Ziel , nur klappt es noch nicht

Der erste gepostete Code ist aus meinem Block DDS1T2,
dieser nimmt das Signal aus DDS1T1 und soll das rechteck generieren
So hoffe ich habe Euch nicht verwirrt..
hier noch mein Blockdesign zum jetzigen Standpunkt (channel 1 Sägezahn 
funktioniert, channel2 rechteck leider nicht)

[Kersty F. (kersty_f)]

zu Falk B.:

> Das kann man mittels Akkumulator ala DDS machen, den man mit
> unterschiedlichen FTW (frequency tuning word) füttert, damit erzeugt man
> die Rampen.
> Diese Daten gibt man dem VHDL Modul sinnvollerweise von außen fertig
> vor, denn das Umrechnen von Tastgrad in Anstieg und zeiten ist
> aufwändig. Dafür verschwendet man keine Harware. Oder nur zu Lehrzwecken
> und als Turnübung.

ja siehe mein Block DDSTeil1
und ja aber soweit bin ich noch nicht, Berechnungen sollen mit c 
erfolgen
da muss ich noch rein arbeiten (kenne nur c++) ..

[Falk B. (falk)]

Kersty F. schrieb:
> Aufgabenstellung ist die Generierung von Rechtecksignalen und dem Sinus
> mit phasenverschiebung, veränderlicher flankensteilheilt, veränderlichem
> tastgrad, sinus soll (im ideal Fall) angeschnitten sein, alles für
> zukünftige Test von Baugruppen, die im Zug die Signale von
> (Wegimpulssensoren, verschiedene Impulsgeber) aufnehmen (schreibe in
> einem Betrieb).

Umso mehr ein Grund, das nicht vom Urschleim aufzubauen sondern was 
MÖGLICHST Fertiges nehmen, z.B. den FY6900.

[Falk B. (falk)]

Kersty F. schrieb:
> und ja aber soweit bin ich noch nicht, Berechnungen sollen mit c
> erfolgen
> da muss ich noch rein arbeiten (kenne nur c++) ..

DER war gut! Du GLAUBST, C++ zu kennen, naja, KENNEN tust du es 
wahrscheinlich. Aber nicht eine Sekunde beherrschen! Denn wer nur die 
GRUNDZÜGE von C++ beherrscht, kann auch C, denn die sind, Oh Wunder, 
GLEICH!

Ich wiederhole mich. Nimm was Fertiges. Da bist du mehr als genug 
beschäftigt, das zum Laufen zu kriegen. Aber mit der Chance, fertig zu 
werden und ein DEUTLICH besseres Ergebnis zu erreichen.

[Achim S. (Gast)]

Kersty F. schrieb:
> Ich bin für jeden Tipp und jeden Hinweis dankbar.

Na, dann mal ein paar Hinweise, was du auf jeden Fall ändern solltest:

Kersty F. schrieb:
> USE ieee.std_logic_unsigned.ALL;
> use IEEE.numeric_std.all;

Kombiniere nicht diese beiden packages. In ieee.numeric_std ist alles 
drin, was du zum Rechnen mit unsigned brauchst.

Kersty F. schrieb:
> Y <= Y + unsigned(Slope);
>       --Bereichsüberlauf, overflow flag setzten (definieren)
>         if y = 16384 then

y ist vom Typ unsigned(13 downto 0). Damit kannst du den Wert 16384 
nicht erreichen, der Vergleich liefert also immer false. Der größte 
mögliche Wert  für Y ist 16383.

Außerdem zählst du y in Schritten von Slope hoch. Wenn Slope größer als 
1 ist, dann ist es wahrscheinlich, dass du einen bestimmten 
Vergleichswert gar nicht triffst sondern über ihn drüberspringst. 
Dasselbe gilt beim Zählen nach unten und beim Vergleich mit 0.

Falk B. schrieb:
> Nimm was Fertiges.

Zumindest solltest du dir mal anschauen, wie das in Standardlösungen 
gemacht wird. Einfach die Phase hochzählen. Den aktuellen Phasenwert als 
Index auf eine Sinustabelle im BlockRAM nehmen. (Für Phasenverschobenen 
Sinus nimmst du den aktuellen Phasenwert und zählst einen Phasenoffset 
dazu). Und für die Rechteckfunktion einfach prüfen, ob der Phasenwert 
über einem Grenzwert liegt oder nicht.

Wenn du verstanden hast, wie es standardmäßig funktioniert, kannst du ja 
immernoch versuchen, es selbst besser zu machen.

[Kersty F. (kersty_f)]

Falk B. schrieb:
> Kersty F. schrieb:
>> und ja aber soweit bin ich noch nicht, Berechnungen sollen mit c
>> erfolgen
>> da muss ich noch rein arbeiten (kenne nur c++) ..
>
> DER war gut! Du GLAUBST, C++ zu kennen, naja, KENNEN tust du es
> wahrscheinlich. Aber nicht eine Sekunde beherrschen! Denn wer nur die
> GRUNDZÜGE von C++ beherrscht, kann auch C, denn die sind, Oh Wunder,
> GLEICH!
>
:)

> Ich wiederhole mich. Nimm was Fertiges. Da bist du mehr als genug
> beschäftigt, das zum Laufen zu kriegen. Aber mit der Chance, fertig zu
> werden und ein DEUTLICH besseres Ergebnis zu erreichen.

Ich benutzte den Redpitaya
https://redpitaya.com/stemlab-125-14/,
ich bin da an den Betrieb gebunden...

Aber sonst hast du Recht- das wäre einfacher.

[Kersty F. (kersty_f)]

Achim S. schrieb:

>
> Falk B. schrieb:
Kombiniere nicht diese beiden packages. In ieee.numeric_std ist alles
drin, was du zum Rechnen mit unsigned brauchst.

Danke für den Tipp. Blos wenn ich ieee.numeric_std ausklammere werden 
gleich alle y markiert und die Fehlermeldung, das y nicht deklariert 
ist, erscheint.


>> Nimm was Fertiges.
>
> Zumindest solltest du dir mal anschauen, wie das in Standardlösungen
> gemacht wird. Einfach die Phase hochzählen. Den aktuellen Phasenwert als
> Index auf eine Sinustabelle im BlockRAM nehmen. (Für Phasenverschobenen
> Sinus nimmst du den aktuellen Phasenwert und zählst einen Phasenoffset
> dazu). Und für die Rechteckfunktion einfach prüfen, ob der Phasenwert
> über einem Grenzwert liegt oder nicht.
>
> Wenn du verstanden hast, wie es standardmäßig funktioniert, kannst du ja
> immernoch versuchen, es selbst besser zu machen.

Das ist eine gute Idee, wo finde ich solche Standardlösungen? Und Gibt 
es das auch für die Generierung des Sinus?

[Kersty F. (kersty_f)]

Achim S. schrieb:

> Kersty F. schrieb:
>> Y <= Y + unsigned(Slope);
>>       --Bereichsüberlauf, overflow flag setzten (definieren)
>>         if y = 16384 then
>
> y ist vom Typ unsigned(13 downto 0). Damit kannst du den Wert 16384
> nicht erreichen, der Vergleich liefert also immer false. Der größte
> mögliche Wert  für Y ist 16383.
>
> Außerdem zählst du y in Schritten von Slope hoch. Wenn Slope größer als
> 1 ist, dann ist es wahrscheinlich, dass du einen bestimmten
> Vergleichswert gar nicht triffst sondern über ihn drüberspringst.
> Dasselbe gilt beim Zählen nach unten und beim Vergleich mit 0.
>

Stimmt ich zähle Slope hoch, habs gerade mit y=1023 ausprobiert:

  Y <= Y + unsigned(Slope);
--Bereichsüberlauf, overflow flag setzten (definieren)
    if y = 1023 then
        y <=(others =>'0') ;
                else
    --zweite Halbwelle
         Y <= Y - unsigned(Slope);
          if y = 0 then
              y <= (others=>'1');
Leider wird der Rechteck trotzdem nicht generiert..

[Achim S. (Gast)]

Kersty F. schrieb:
> Danke für den Tipp. Blos wenn ich ieee.numeric_std ausklammere werden
> gleich alle y markiert und die Fehlermeldung, das y nicht deklariert
> ist, erscheint.

Du sollst nicht "ieee.numeric_std ausklammern". Du sollst 
ieee.std_logic_unsigned.ALL; löschen oder auskommentieren, so dass nur 
noch die ieee.numeric_std benutzt wird.

Kersty F. schrieb:
> Das ist eine gute Idee, wo finde ich solche Standardlösungen?

Z.B. im Datenblatt jedes DDS-ICs. Da du ein Zynq-FPGA verwendest, suche 
bei Xilinx nach "DDS user guide" und schau dir die Dokumente durch. Das 
liefert zwar mehr Informationen, als du zu Beginn brauchst. Aber die 
relevanten Informationen zum Einstieg sind auch enthalten.

Kersty F. schrieb:
> Und Gibt
> es das auch für die Generierung des Sinus?

Das ist die Standardanwendung einer DDS, Rechteck und Dreieck sind nur 
"Nebenprodukte" davon...

Kersty F. schrieb:
> Leider wird der Rechteck trotzdem nicht generiert..

Kersty F. schrieb:
> Stimmt ich zähle Slope hoch, habs gerade mit y=1023 ausprobiert:

Was bedeutet dieser Satz? Welchen Wert hat Slope? Wenn es nicht den Wert 
1 hat, dann gibt es eine signifikante Wahrscheinlichkeit, dass du die 
1023 nicht triffst.

Der Kniff bei der DDS ist aber auch, dass du den Überlauf gar nicht zum 
Anlass nimmst, den Wert des Phasenakkumulators auf einen bestimmten Wert 
zurückzusetzen. Wenn Y den Wert 16380 hat, und du zählst Slope=10 dazu, 
dann startet Y im nächsten Taktzyklus gleich mit 6. Dadurch triffst du 
im Mittel die gewünschte Periodendauer viel besser, als wenn du es beim 
Überlauf auf 0 zurücksetzen würdest.

[Kersty F. (kersty_f)]

Achim S. schrieb:


> Der Kniff bei der DDS ist aber auch, dass du den Überlauf gar nicht zum
> Anlass nimmst, den Wert des Phasenakkumulators auf einen bestimmten Wert
> zurückzusetzen. Wenn Y den Wert 16380 hat, und du zählst Slope=10 dazu,
> dann startet Y im nächsten Taktzyklus gleich mit 6. Dadurch triffst du
> im Mittel die gewünschte Periodendauer viel besser, als wenn du es beim
> Überlauf auf 0 zurücksetzen würdest.

Könntest Du bitte die Rechnung ausführlicher aufschreiben? Wie kommst du 
auf 6?

[Achim S. (Gast)]

Kersty F. schrieb:
> Könntest Du bitte die Rechnung ausführlicher aufschreiben? Wie kommst du
> auf 6?

hast du schon Mal einen Überlauf berechnet?

16380 + 10 = 16390
16390 mod 16384 = 6

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

Das Problem hier ist wie üblich, dass zu viele Themen gleichzeitig 
angegangen werden. Ich sehe hier ganz speziell 3 Themenbereiche, von 
denen jeder einzelne geraume Zeit zur Einarbeit braucht:

1. FPGA
2. VHDL
3. Signalverarbeitung/-erzeugung

Wie gut beherrscht du jedes dieser Themen?
Wie gut kann dich dein Betreuer unterstützen?

1. Wenn du nicht weißt, was dein FPGA kann, welche internen Komponenten 
du hast und wie du sie verwenden kannst, dann wird das nichts.

Dagegen hilft nur ausgiebiges Datenblattstudium.

2. Wenn du nicht weißt, welche VHDL Konstrukte auf welche Hardware in 
deinem FPGA abgebildet werden und was du tun musst, um das zu bekommen, 
was du willst/brauchst, dann wird das nichts.

Da musst du unbedingt beim Urschleim anfangen und dich hocharbeiten. 
Ganz am Anfang der VHDL Lernkurve solltest du z.B. 5-6 verschiedene und 
unterschiedliche Arten herausfinden, um eine LED blinken zu lassen. Mit 
ausreichend Phantasie geht das bis hin zur Rückkopplung über ein 
externes RC-Glied. Oder einen Ringoszillator im FPGA. Allein mit dieser 
blinkenden LED und dem nachfolgenden Lauflicht kann ich einen 
Praktikanten eine Woche beschäftigen ohne dass ihm langweilig wird...

3. Wenn du nicht weißt, auf welche Arten man überhaupt solche Signale 
erzeugen kann und du nicht weißt, wie du die beste Art davon für dein 
FPGA auswählen kannst, dann wird es auch nichts.

Für dieses Wissen gibt es aber zum Glück Fachbücher und Fachartikel und 
fertige Bausteine und deren Datenblätter samt Appnotes.

[Kersty F. (kersty_f)]

Achim S. schrieb:
> Kersty F. schrieb:
>> Könntest Du bitte die Rechnung ausführlicher aufschreiben? Wie kommst du
>> auf 6?
>
> hast du schon Mal einen Überlauf berechnet?
>
> 16380 + 10 = 16390
> 16390 mod 16384 = 6

nein noch nicht

[Kersty F. (kersty_f)]

Lothar M. schrieb:
> Das Problem hier ist wie üblich, dass zu viele Themen gleichzeitig
> angegangen werden. Ich sehe hier ganz speziell 3 Themenbereiche, von
> denen jeder einzelne geraume Zeit zur Einarbeit braucht:
>
> 1. FPGA
> 2. VHDL
> 3. Signalverarbeitung/-erzeugung
>
> Wie gut beherrscht du jedes dieser Themen?
> Wie gut kann dich dein Betreuer unterstützen?
>
> 1. Wenn du nicht weißt, was dein FPGA kann, welche internen Komponenten
> du hast und wie du sie verwenden kannst, dann wird das nichts.
>ich weiß welche internen Komponenten mein FPGA hat, bei der Verwendung kriege ich 
Unterstützung


> Dagegen hilft nur ausgiebiges Datenblattstudium.
>
> 2. Wenn du nicht weißt, welche VHDL Konstrukte auf welche Hardware in
> deinem FPGA abgebildet werden und was du tun musst, um das zu bekommen,
> was du willst/brauchst, dann wird das nichts.
Meinst du damit wie der FPGA aufgebaut ist?-mit der grundlegenden 
Struktur habe ich mich schon beschäftig

>
> Da musst du unbedingt beim Urschleim anfangen und dich hocharbeiten.
> Ganz am Anfang der VHDL Lernkurve solltest du z.B. 5-6 verschiedene und
> unterschiedliche Arten herausfinden, um eine LED blinken zu lassen. Mit
> ausreichend Phantasie geht das bis hin zur Rückkopplung über ein
> externes RC-Glied. Oder einen Ringoszillator im FPGA. Allein mit dieser
> blinkenden LED und dem nachfolgenden Lauflicht kann ich einen
> Praktikanten eine Woche beschäftigen ohne dass ihm langweilig wird...
>
Led und Lauflicht habe ich auch schon blinken lassen, nur nicht über 5-6 
verschiedene Weg sondern mit Hilfe der von RedPitaya fertigen 
Beispielen.


> 3. Wenn du nicht weißt, auf welche Arten man überhaupt solche Signale
> erzeugen kann und du nicht weißt, wie du die beste Art davon für dein
> FPGA auswählen kannst, dann wird es auch nichts.

Meinst du mit Art ob DDS oder PLL besser geeignet ist? Ich hatte von 
Begin an die Aufgabe DDS umzusetzen, habe ich mich dadurch nicht mit 
anderen Möglichkeiten beschäftigt.
>
> Für dieses Wissen gibt es aber zum Glück Fachbücher und Fachartikel und
> fertige Bausteine und deren Datenblätter samt Appnotes.

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

Kersty F. schrieb:
> Ich hatte von Begin an die Aufgabe DDS umzusetzen
Ja, und deshalb musst du 2 Sachen machen:
1. ein RAM/ROM mit der berechneten Wellenform füllen und dann
2. mit der DDS aus diesem RAM die entsprechenden Werte auslesen und 
ausgeben.

Der Teil 2 ist für jede beliebige, sich wiederholende Wellenform immer 
gleich. Bleibt also lediglich der Teil 1 mit dem Füllen des RAMs.

Kersty F. schrieb:
> Led und Lauflicht habe ich...
> mit Hilfe der von RedPitaya fertigen
> Beispielen.
Dir ist hoffentlich klar, dass du dabei nichts gelernt hast ausser das 
"Knöpfen in der richtigen Reihenfolge drücken"?

Mein Tipp: suche die anderen 4 Blink-LED Varianten selber (also auch 
nicht bei Google...).

[Kersty F. (kersty_f)]

Lothar M. schrieb:
> Kersty F. schrieb:
>> Ich hatte von Begin an die Aufgabe DDS umzusetzen
> Ja, und deshalb musst du 2 Sachen machen:
> 1. ein RAM/ROM mit der berechneten Wellenform füllen und dann
> 2. mit der DDS aus diesem RAM die entsprechenden Werte auslesen und
> ausgeben.
>
> Der Teil 2 ist für jede beliebige, sich wiederholende Wellenform immer
> gleich. Bleibt also lediglich der Teil 1 mit dem Füllen des RAMs.
>
> Kersty F. schrieb:
>> Led und Lauflicht habe ich...
>> mit Hilfe der von RedPitaya fertigen
>> Beispielen.
> Dir ist hoffentlich klar, dass du dabei nichts gelernt hast ausser das
> "Knöpfen in der richtigen Reihenfolge drücken"?
>
> Mein Tipp: suche die anderen 4 Blink-LED Varianten selber (also auch
> nicht bei Google...).

Das RedPitaya hat gar keine Knöpfe (Schalter) zum Drücken aber ich suche 
mal,
ist mir klar natürlich

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

Kersty F. schrieb:
> Das RedPitaya hat gar keine Knöpfe (Schalter) zum Drücken
Ich meinte damit: du hast im Grunde nur gelernt den "Download"-Knopf der 
PC Software anzuklicken. Du hast gelernt, wie man die Toolchain bedient, 
aber eben nichrs über VHDL.

Oder hast du diesen fertigen vorliegenden LED-Blink Code analysiert? Das 
Design vor dem Runterladen aufs FPGA auch mal simuliert und die 
Simulation dann mit der Realität verglichen (der Simulator ist der 
FPGA-Debugger)? Hast du das Syntheseergebnis angeschaut und 
kontrolliert, ob die benötigten Ressourcen plausibel sind? Hast du 
herausgefunden, wie man einen RTL-Schaltplan anzeigt und nachgeschaut, 
ob er zu deiner Schaltung passt, die du mit VHDL beschrieben hast?

Das alles sind die Grundlagen, ohne die du dich ständig fragen wirst, 
warum das jetzt schon wieder nichts oder ganz was anderes als das tut, 
was du erwartest.

Dort ist übrigens genau so ein LED-Blinker: 
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html