DDS Compiler - Phase nur bis 16 Bit?

Achim S. schrieb:
> einen großen Block-RAM instanziieren und die Sinuswerte über ein
> Koeffizientenfile vorbelegen. Um Sinus-Werte zu berechnen brauchst du ja
> nicht zwingend den DDS-Compiler, das kannst du auch unabhängig von
> Xilinx z.B. per Excel erledigen.

Exakt. Mache ich schon immer so. Der DDS-Compiler scheint auch so seine 
Eigenheiten zu haben, bzw. die Firma Xilinx hat ein eigenes Verständnis, 
wie Sinuswerte auszusehen haben, damit man sie sequenziell ausgeben 
kann. Ich habe vor etwa 10 Jahren dazu schon einen Artikel gepostet, in 
welchem ich auf die Unterschiede hingewiesen habe. Es scheint sich um 
Rundungsfehler zu handeln, bzw. ich runde anders, als Xilinx es tut. 
Mein Phasenoffset ist auch ein anderer und orientiert sich an dem 
Prinzip, dass ein Phasenwert X immer die Mitte eines Phasenbereiches 
abdeckt, also die 0 repräsentiert den Bereich von 0 bis 1,  die 1 den 
von 1 bis 2. Damit ist der richtige Sinuswert Y der des Wertes X in der 
Mitte, also z.B. 0.5, 1.5 etc. Der erledigt das Problem eines impliziten 
Offsets und einer möglichen Änderung des Verhaltens wenn der Vektor mal 
aufgebohrt wird. Auch sind die Sinuswellen unterschiedlicher Auflösungen 
so immer auf derselben Phasenlage. Siehe auch meine Ausführungen im 
Artikel
Digitale Sinusfunktion.

Der Nachteil einer selbst erzeugten Tabelle ist leider die extreme 
Synthesezeit bei langen Tabellen, wenn man es nicht im BRAM, sondern 
unter z.B. Mitbenutzung von LUTRAM bauen will. Ich erlebe das auch 
gerade wieder bei meinen fest verbauten Wellenformen. Die haben z.B. 20 
Bit-Phasen und synthetisieren ewig. Ich will die aber in LUT haben, 
damit sie klein bleiben. Typisch lassen sich die Umfänge ja stark 
reduzieren, wenn die Logik optimiert wird.

Wenn es nur ein Sinus sein soll, dann tut gfs auch der CORDIC. Der hat 
dann eben wieder Latenzen und den Nachteil, dass man nur binäre 
Auflösungen erzeugen kann.

Ich habe in 2010 eine Sinustabelle in reinem VHDL nach

<  https://opencores.org/projects/sincos      >

hochgeladen. Die hat keine künstlichen Beschränkungen.
Wenn du das RAM /ROM hast, dann bekommt er es voll.
Das Testbett enthält als Beispiel einen DDS.
Reines portables VHDL, kein ise/vivado/matlab, was auch immer.

Es werden alle möglichen Symmetrien ausgenutzt und man
bekommt Sinus & Cosinus gleichzeitig ohne Mehraufwand.
(Na ja, ein paar Pipelineregister).

Die Anzahl der Pipelinestufen kann man einstellen von 0
(rein kombinatorisch) bis 10, WIMRE. Die werden halbwegs
sinnvoll an den richtigen Stellen eingefügt, weil der
Register-balancer zumindest damals bei der ISE nicht
viel getaugt hat.

Bei der Compilation wird gecheckt, dass alle Werte
korrekt bis zum letzten Bit gerundet sind; das heisst
der Fehler ist max. ein halbes Bit.

Die einzigen Beschwerden die bisher gekommen sind,
waren dass Leute es nicht geschafft haben ihren
Modelsim auf ps einzustellen.

Wenn man z.B. wirklich niedriges Phasenrauschen
braucht, dann muss man eben den Speicher opfern.

Wenn man Phasen/Frequenzmodulation/sweeps machen will,
dann bekommt man beim Cordic Latenz-Probleme.

Die Sinustabelle ist dieses Jahr bisher 139 mal runter-
geladen worden. Meist in Clustern. Ich vermute,
immer dann, wenn passende Hausaufgaben verteilt werden. :-)

Gruß, Gerhard

BSD ist doch letztlich "Mach damit was du willst, aber lass mich in
Ruhe und behaupte nicht, es wäre von dir."
Entgegenkommender kann man kaum sein.

Ja, ich wollte eigentlich noch erweitern auf BCD, damit man aus einer
100 MHz clock auch EXAKT und phasenstarr 0.999 MHz machen kann, aber
wenn nie eine Rückmeldung kommt, ausser wenn jemand Probleme mit
seinen Werkzeugen hat, dann verschwindet der Antrieb recht schnell.

Gruß, Gerhard

(BCD gestrichen, auf stable gesetzt)

Ah, Sonntag morgen um 00:45....

Float ist ein ganz normaler VHDL-Datentyp, und der wird nur
zur Compilationszeit auf deinem PC benutzt. Im FPGA landet
keinerlei Gleitkomma-Arithmetik. Die Funktion init_sintabxxxx()
macht zwar intern jede Menge Gleitkomma-Turnerei, aber was
sie letztendlich abliefert ist nur ein ROM-Image, mit dem man
ein konstantes Dingens vom Typ sintab initialisieren kann.
Und sie ist beim Compilieren geschwätzig.

VHDL ist eine Simulationssprache, von der ein Teil
synthetisierbar ist. VHDL kann alles was C oder Pascal
können. Die libraries sind halt beschissen (textio etc)
und es macht eher weniger Spaß. Das kotzt einen spätestens
an, wenn man aus Vorschriftswut kein wirkliches Äquivalent
zu printf() mit variabler Parameterzahl bekommt.

Die Vektor-Breiten ergeben sich automatisch daraus, was du
"von oberhalb" anschliesst. Da ist nix zu tun. Du musst es
nur im Context compilieren.

Wenn Du einen Bus mit 20 Bit Breite an den Ausgang anschliesst,
dann liefert die Tabelle eben 20 Bit. Du brauchst nicht sagen,
übrigens, wir brauchen 20 Bit. Das kann man schon an den
Attributen des Ausgangsbusses sehen. Es wird einfach das 'length
oder 'high-Attribut der angeschlossenen Busse benutzt.
Das passt dann von selbst.

Aaargh, ich hatte > 8 Jahre keinen Grund mehr, mir das anzuschauen.
Ich bemühe mich, mehr in analoge Raumfahrtelektronik abzudriften.
Aber auch da poppt schon mal ein Steinzeit-Virtex hoch, das
nach einer triple module redundancy library fragt.

Gute Nacht für heute!

Gerhard

Braucht es das wirklich so genau? Mit einer Tabelle, die 16 Bit Phase 
hat und sowohl SIN als auch COS enthält, kann man durch direktes 
rechnerisches Interpolieren deutlich erhöhte Auflösungen erzielen, als 
es scheint, in man einfach 2 Punkte ausliest und eine Kurve darüberlegt 
(bis zu 4 Randbedingungen). Heutige Microprozessoren sind rechenstark 
genug, um das zu leisten. Selbst im FPGA mache ich keine Sinustabellen 
mehr, die größer sind. Im Gegenteil: Ich habe schon mit WaveTables 
gearbeitet, die nur 12 Bit Phase hatten und die haben ja noch Oberwellen 
drin.

Ein einfacher Sinus mit 11Bit Auflösung für die volle 4/4-Phase und nur 
9 Bit Amplitude, unter Aufspaltung in 5 Phasen- und 6 Restbits bringt 
selbst bei linearer Interpolation nur 0,6% Abweichung, wenn man es 
richtig macht.
(effektiv eine Altera-freundliche Tabelle mit (16 9 Bit-Werten, 
inklusive Offsettrickserei 8 Stützwerte!). Unter Ausnutzung eines 
kompletten Block-RAMs mit voller Symmetrienutzung (11 Bit für die 
1/4-Phase und 6 Bit für den Steigungskoeffizienten) sind es es nochmal 
einen Faktor 10 besser.

Erhöht man die Amplitudenauflösung auf quasi artefaktfrei, ab z.B. 4 
Bits mehr, reduziert sich der Fehler auf etwa die Hälfte, was aber nicht 
wirklich besser ist, weil dann je nach erzeugter Frequenz die Werte in 
den Tälern rhythmisch getroffen werden und sich der Fehler spektral 
schlechter verteilt.

Noch besser wird es mit quadratischer Interpolation über 3 Punkte, 
besser aber gleich 4 mit der doppelten RAM-Größe. Das ist im ersten 
Schritt sogar effektiver, als die doppelte RAM-Größe in die Amplituden- 
oder Phasenauflösung zu investieren.

Erst, wenn man das hat, lohnen mehr Bits in den Tabellen. Das scheint 
vielen nicht so recht klar zu sein. Hatte schon mehrere erstaunte 
Kunden, die trotz gut aufgelöster Sinus-Tabellen in ihren Generatoren 
sehr mäßige Ergebnisse hatten im Vergleich zu meinen spezialisierten 
MINI-Cores.
Wenn ich mir den Resourcenbedarf so ansehe, den der XI-Core da 
erfordert, steht das in keinem Verhältnis zum Ergebnis.

Ist aber heute Designstrategie: Hauptsache schnell fertig, rein damit 
und zufrieden sein. Chipfläche kostet ja nichts.

In James A. Crawford's Synthesizer Design Handbook, Artech House

< 
https://www.amazon.de/Frequency-Synthesizer-Handbook-Microwave-Hardcover-ebook/dp/B006TWYZ5Y/ref=sr_1_fkmr0_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=James+A.+Crawford%27s+Synthesizer+Desihn+Handbook%2C+Artech+House&qid=1576525910&sr=8-1-fkmr0 
>

sind einige Techniken zur Reduktion der Tabellengröße aufgeführt.
Das reicht von etwas Interpolation über Sunderland's Zerlegung
des ROMs in 2 kleinere bis zum Dithering, um die entstehenden
spurs glattzurubbeln.
Die Reduktion kann bis 1:50 gehen, WIMRE.
Das geht so über 30 Seiten; wenn ich das scanne, dann bekomme
ich wohl Ärger.

Ich werde mich im Januar noch mal mit dem Opencores-Block befassen,
jetzt ist Meilenstein-Rallye.

Gruß, Gerhard

Gerhard H. schrieb:
> Sunderland's Zerlegung des ROMs
Die Methode sollte sich IMHO in der Gesamtschau bei der Qualität 
heutiger Synthesewerkzeuge und Hardware erledigt haben. Das gilt 
insbesondere für Tabellen in FPGAs, die in LUTs abgebildet sind. 
Aufgrund der geringen BIT-Zahl kommt man da nicht mehr so gut bei raus, 
sobald die erforderliche Bit-Breite mehr, als 2 LUT-Breiten sind. Eine 
Abbildung im Block-RAM ist zielführender, weil schneller addressierbar 
und am Ende kleiner und stromsparender, weil der Adress-MUX schon hart 
implementiert ist. Und wenn man ein BRAM hat, sind 10kb-20kb das minimal 
verfügbare.

Beitrag "Re: Bildung und Nutzung von Sunderland Tabellen für Sinus"

Für etwas rechenschwache Systeme wie NIOS oder MicroBlaze, die in sehr 
kleinen FPGAs gebaut werden sollen, welche kaum BRAM haben, aber dennoch 
hohe Durchsätze produzieren sollen, könnte das noch ein Thema sein.


Gerhard H. schrieb:
> bis zum Dithering, um die entstehenden
> spurs glattzurubbeln.

Mit dithering ist diesbezüglich aber nicht viel zu wollen. Das taugt 
mehr, um die Auflösung in Y und X zu tunneln und so richtig wirkt das 
dann, wenn derselbe Y-Wert oder Werte mit Bezug zueinender infolge 
starrer Frequenz mehrfach ausgelesen werden. Das ist aber nur bei tiefen 
Frequenzen der Fall / wirklich hilfreich.

Dithering behebt auch keine Interpolationsfehler und die sind bei der 
Diskussion hier der Hauptfokus, denke ich. Um bei dem Thema DDS mit 
groben Interpolationen klarzukommen, gibt es 3 Hauptstrategien:

1) Anpassung der Tabellenlänge, weg von binären Längen hin zu einer 
Länge, welche entweder perfekt zur Zielfrequenz passt oder insofern dazu 
passt, dass bei hohen Frequenzen nur gut filterbare Frequenzen entstehen 
und nicht etwas tieffrequente Schwebungen.

2) Einteilung der Vektorunterteilung so, dass die Knicke so liegen, dass 
ganzzahlige Vielfache der Grundwelle entstehen, also anhand der Phase 
und nicht anhand der Amplitude. Bei meinem abschnittsweise definierten 
Sinus verfahre ich so. Das produziert harmonische Oberwellen, die 
passen.

3) Postfilterung unter Nutzung einer TAP-Zahl die zur Tabellenlänge 
komplementär ist, also die Artefakte, die durch das Springen des 
Phasenvektors entstehen, optimal filtert und nicht etwa interferiert, 
was ich auch schon gesehen habe. Gerade schnell und damit einfache 
FIR-Filter haben die unangenehme Eigenschaft, Oberwellen durchzulassen, 
die nicht gut in die Filterlänge passen. Da sowohl Filterlänge, als auch 
Tabellenlänge oft Binärwerte sind, haben beide genau an derselben 
Stelle, also für die selben Frequenzen Stärken und für andere Schwächen.