Hallo,
ich suche einen Sinusgenerator, mit dem ich auf meinem Spartan3-Board
über den Atium Designer einen Sinus erzeugen kann, bei dem ich eine
genaue Frequenz vorgeben kann.
Er soll u.a. über Treiber und MOSFET einen Tiefsetzsteller ansteuern und
eine über Brückenschaltung eine Sinus-Dreieck-PWM ermöglichen.
Wichtig, wie gesagt, ist eine genaue Zielfrequenz, die sich nach
Möglichkeit einfach ändern lassen soll. So kann ich z.B: die Buttons mit
verschiedenen Wunschfrequenzen belegen, z.B. 48,13 kHz.
Hatte zunächst ein eine DDFS gedacht. Die Sinus-PWM von Lothar Miller
funktioniert großartig und hat auch gleiche eine Totzeit mit an Bord.
Jedoch habe ich dort das Problem, dass ich die Sinusfrequenz nur durch
Erhöhung des Zählwertes in definierten Schritten erhöhen kann. Diese
Schrittweite kann ich zwar durch Änderung der Boardfrequenz oder durch
Anpassung des Akkumulators ändern. Jedoch kann ich nicht völlig frei
alle beliebigen Sinusfrequenzen erreichen, sondern immer nur sukzessive
um eine bestimmte Frequenz erhöhen.
http://www.lothar-miller.de/s9y/archives/57-Sinusausgabe-mit-PWM.html
Gibt es andere Möglichkeiten der Sinuserzeugung auf FPGA, um einen Sinus
mit genauer Zielfrequenz zu erzeugen?
Wo kann ich weiterführende Infos dazu finden?
Vielen Dank für Eure Hilfe.
Steffen B. schrieb:> Gibt es andere Möglichkeiten der Sinuserzeugung auf FPGA, um einen Sinus> mit genauer Zielfrequenz zu erzeugen?
Definiere "genau". Du arbeitest mit einem digitalen System, dort gibt es
den Begriff "stufenlos" nicht. Du wirst immer irgendwelche
Diskretisierungsstufen haben (du kannst dir ein wenig "Analogfeeling"
vorgaukeln, indem du eine feste Frequenz gegen ein wenig gegen Rauschen
tauschst).
BTW: warum brauchst du eigentlich eine Sinusfrequenz(!) von 48,xx kHz?
Hallo,
die 48,xx waren nur ein Beispiel.
Konkret geht es darum, im Bereich von ca. 10 kHz eine Frequenz
einzustellen, die ich im Kilohertzbereich auf min. eine Nachkommastelle
genau wählen kann.
Also z.B. 10,2 kHz würde reichen.
Sorry, das war falsch. Eine Nachkommastelle allg. ist notwendig. Also
z.B. 10123,1 Hz.
Die Zielfrequenz liegt bei ca. 10 kHz.
Im Moment fuchse ich mich etwas ein. Später soll ein Messstromgenerator
betrieben werden - deswegen bereits jetzt die Anforderung an die
Genauigkeit.
Also du willst auf 0,1 Hz genau die Frequenz einstellen können, wenn ich
dich richtig verstehe.
Dann musst du dir als nächstes überlegen, ob du eine Periode immer mit
exakt der gleichen Anzahl zeitlicher Quantisierungen "abfahren" willst
oder ob die Anzahl der Quantisierungsschritte immer feiner werden soll,
je geringer die Frequenz ist.
Daraus ergibt sich dann, ob du eine Tabelle mit n Werten anlegst, und
über die eingestellte Frequenz entscheidest, wieviel Zeit du zwischen
den einzelnen Quantisierungsschritten verstreichen lässt oder ob du eine
sehr feine Tabelle anlegst und anhand der Frequenz entscheidest,
wieviele Tabelleneinträge du jeweils überspringst.
Um die geeignete Methode (oder einen Mix aus beiden) festlegen zu
können, musst du dir Gedanken darüber machen, in welchem Frequenzbereich
du arbeiten willst und wie grob oder fein sowohl die zeitliche Auflösung
als auch die der Amplitude sein soll.
Letztendlich kann man sowas ganz elegant über eine Tabelle im RAM
machen, in der die Stützpunkte einer Sinusperiode abgelegt sind und die
man dann Einrag für Eintrag in variabelen Zeitabständen durchläuft oder
eben variabel Tabellenwerte überspringt.
Nachtrag:
Mit "immer feiner" meinte ich bezogen auf eine Periode des Sinus.
Was umgekehrt bedeutet, dass die Abstände zwischen den zeitlichen
Quantisierungen konstant sind.
Und die Aufgabe kann wieder mit einer entsprechend skalierten DDFS
erledigt werden. Bei 50MHz Eingangstakt kann ich z.B. mit einem Akku von
30 Bit Breite eine Stufung von 0,1Hz erreichen. Latürnich mit
entsprechendem Jitter, weil sich 50MHz mit Ganzzahlen nicht genau auf
jedes zehntel Hertz teilen lassen. So hat das LSB bei einem Vorteiler
von 30Bit eine Abstufung von 46,56613mHz. Blöde Zahl. Ein Takt mit
53,6870912 MHz wäre günstiger, weil dann bei einer Akkubreite von 29 Bit
jeder Schritt im LSB eine Frequenzänderung von 0,1 Hz bewirken würde...
Siehe http://www.lothar-miller.de/s9y/archives/87-DDFS-Frequenz.htmlSteffen B. schrieb:> Eine Nachkommastelle allg. ist notwendig. Also z.B. 10123,1 Hz
Welche Taktquelle verwendest du denn überhaupt?
Ein "normaler" Oszillator mit 30ppm ist hier weit überfordert, du musst
hier schon mit deutlich weniger als 10ppm auffahren...
./. schrieb:> Mein Quartus-2 hat dafuer ein NCO-Plugin.
Und was macht das "Plugin"?
Warum braucht so ein bisschen Frequenzgenerator so viele Ressourcen?
Und wie schafft es die Hardware, eine Genauigkeit von 10^16 einzuhalten
(immerhin werden vom Wizzard 16 Nachkommastellen angezeigt)?
> Und wie schafft es die Hardware, eine Genauigkeit von 10^16 einzuhalten> (immerhin werden vom Wizzard 16 Nachkommastellen angezeigt)?
Das wuerde ein besserer Taschenrechner sicherlich mit den gleichen
Praezision ausrechnen.
Aus der DDS Taktfrequenz und dem Phasenakkumulatorincrement.
Der XP-Wind00ftaschenrechner liefert:
1000000.000931322574615478515625
Zumindest scheint das Plugin richtig rechnen zu koennen.
Das die Frequenz so genau getroffen wird, ist ein Glueckstreffer.
Ein Step des NCO sind 0,023 Hz.
Mit 565 LEs auf einem Cyclone ist man dabei.
Mit ein paar LEs mehr auch mit FM- oder Phasenmodulator...
./. schrieb:> Mein Quartus-2 hat dafuer ein NCO-Plugin.>> Gibts sowas bei Xilinx nicht?
Den gibt es bei Xilinx auch, allerdings nicht so kompfortabel und
modulierbar wie beim Altera Quartus.
Nee lumpige DDS ist aber direkt zu instanziieren.
Bei der Problematik des TE scheint mir aber die GEnauigkeitsanforderung
gfs der limiter. Implementierbar ist das locker -siehe die Artikel dazu
hier im Forum.
./. schrieb:> Das die Frequenz so genau getroffen wird, ist ein Glueckstreffer.
Sie wird sicher nicht getroffen, weil kein Taktgeber hinreichend
stabil und jitterfrei ist.
> Zumindest scheint das Plugin richtig rechnen zu koennen.
Es könnte aber bei 1ppm langsam mal anfangen zu runden und nicht noch 10
weitere unbrauchbare Stellen abliefern...
Ok, danke schon mal für die Hinweise. Werde nächste Woche versuchen das
Script anzupassen und den Akku zu vergrößern.
Weiß jemand, ob es bei Xilinx ein NCO-Plugin gibt und falls ja, wie es
heißt?
Steffen B. schrieb:> Taktquelle ist übrigens ein 50 MHz Quarz, der onboard auf dem> Spartan3-Board sitzt.
Und wie genau ist der?
0,1Hz von 10 000Hz sind 10ppm, wenn ich mich jetzt nicht verrechnet
habe. Leistet das der Quarz? Oder ist deine Anforderung an die
Genauigkeit auf dem Board eventuell gar nicht realisierbar?
Gute Frage, ob der Quarz 10 ppm leistet. Das weiß ich nicht.
Konnte kein Datenblatt finden.
Auf dem Quarz steht:
"FCO-736B"
"50.000"
"Fcom 4D"
Habe mal eine Messung mit dem Oszilloskop gemacht, jedoch kann ich da
nur einige Takte messen. Das sah ganz gut aus, aber ist nicht so
aussagekräftig. Müsste eigentlich mit einem Frequenzcounter arbeiten :-(
Das Spartan 3-Handbuch spricht von einer "50 MHz Epson SG-8002JF series
clock oscillator source". Das deckt sich leider nicht mit den
eingravierten Angaben auf dem Quarz.
Alternativ lässt sich auf dem S3-Board aber ein anderer Oszilator mit
8-pin DIP-footprint nachrüsten.
Steffen B. schrieb:> Gute Frage, ob der Quarz 10 ppm leistet. Das weiß ich nicht.
Tut er nicht.
> Konnte kein Datenblatt finden.
2 Minuten
http://www.fujicom.jp/FCO-700.pdf> Auf dem Quarz steht:> "FCO-736B"> "50.000"> "Fcom 4D">
Schlumpf schrieb:> Steffen B. schrieb:>> Taktquelle ist übrigens ein 50 MHz Quarz, der onboard auf dem>> Spartan3-Board sitzt.>> Und wie genau ist der?> 0,1Hz von 10 000Hz sind 10ppm, wenn ich mich jetzt nicht verrechnet> habe. Leistet das der Quarz? Oder ist deine Anforderung an die> Genauigkeit auf dem Board eventuell gar nicht realisierbar?
Wenn das board als alleinige Plattform hergenommen werden soll, ist das
in der Tat ein wichtiger Punkt.
Üblicherweise wird man aber bei hochpräzisen Applikationen nicht den
FPGA-Takt oder dessen PLL nehmen, um die Daten auszugeben, sondern einen
DAC mit eigener PLL, der die Daten über einen aFIFO abholt. Dessen PLL
wiederum wird aus einem hochgenauen Taktgenerator gespeist. Das FPGA
hängt nur "lose" davor und darf ruhig jittern.
Die ganze Geschichte haben wir auch schon vor längerer Zeit im Rahmen
des FPGA-DDS-Generators diskutiert, meine ich. Es braucht einen guten
Mastertakt, der gfs selbst präzise aus einer DDS kommt.
