Hat jemand zufällig den HDL-Coder schon mal dazu gebraucht, statistisch zu runden? Gibt es dafür eine box oder muss man das selber machen?
Was ist denn statistisches Runden? Wikipedia kennt es nicht: https://de.wikipedia.org/wiki/Rundung
Und falls es der HDL-Coder kann, sollte es in dessen Doku stehen, oder?
Es geht wohl um Runden bei "*.5" .
In HDL schneidet man gern lsb ohne Berücktsichtigung der msb ab, (Auf-)Runden nach der Geradzahlregel (so hiess es wohl an "meiner" Grundschule) wird in FPGA-Logik schnell aufwendig (Adder/Incrementer für den Rest).
Wird wohl auch unter "round or truncate" diskutiert.
:
Bearbeitet durch User
Was ist denn statistisches Runden?
Mittels statistischer Funktionen auf und abrunden, damit sich über die Zeit sinnvolle Mittelwerte ergeben und nicht Werte, die längere Zeit bei >0,5 und <1,0 liegen ständig eine anhaltende 1 erzeugen.
Wikipedia kennt es nicht:
Wikipedia kennt vieles nicht. Ich habe das von meinem Mathelehrer aus den 1980ern. Wird (wurde ?) wohl für die damals gebrächlichen niedrigen Auflösungen von CPUs genutzt.
Und falls es der HDL-Coder kann
Ich habe nichts gefunden - vermute(te) aber daß man es in einer toolbox finden könnte.
Was noch erwähnenswert ist: Es geht um INTEGER-Berechnung. Bei heutigen Anwendungen tritt das Problem kaum auf, das REAL benutzt.
Es geht wohl um Runden bei "*.5" .
Nicht nur, allerdings ist es da mit am Wichtigsten.
In HDL schneidet man gern lsb ohne Berücktsichtigung der msb ab,
Ja, das machen die Meisten und schleppen sich damit entsprechende Fehler ein.
(Auf-)Runden ... wird in FPGA-Logik schnell aufwendig
Man braucht einen Addierer vor dem Abschneiden - oder aber man rundet eben statistisch VOR oder sogar NACH der Berechnung.
Hier ist das Problem am Beispiel eines Sinussignals: Rundet man durch klassisches Aufrunden, entsteht ein u.U. langes Rechteck. Durch ein (hier einfaches alternierendes) Runden bekommt man eine Funktion, welche das reale Signal im Mittel besser repräsentiert.
Angehängte Dateien:
-
runden.jpg
(84 KB)
Hier ist eine Tabelle für eine INT-Multiplikation mit Werten die (als Beispiel) auf 2 Bit genau sind. Danaben das Ergebnis in Real. In den Zeilen darunter einmal Abschneiden, Runden und statistisches Runden mit jeweils der sich ergebenden Differenz. Bei normalen Runden ergeben sich immer Muster, beim Abschneiden ist der Wert zudem zu tief. Da ließe sich dann, wie oben schon erwähnt, im Nachhinein ein Wert beaufschlagen.
Angehängte Dateien:
-
Statistisches_Runden.jpg
(240 KB)
(*) vorweg: Von VHDL & Co. habe ich super wenig Ahnung, steuere bloß mal ein paar allgemeine Gedanken bei...
Hier ist das Problem am Beispiel eines Sinussignals: [...]
Ich kannte "wissenschaftliches Runden" = zusätzliche Regel, um die Asymmetrie des kaufmännischen Rundens (in 5 Fällen auf-, nur in 4 Fällen abrunden) im statistischen Mittel zu beseitigen.
Dein Beispiel mit dem Sinussignal: Kann eine bestimmte Rundungsstrategie da überhaupt helfen? Sich langsam ändernde Werte "kleben" ja (bei deterministischer Rundungsregel) so oder so eine Weile am jeweiligen korrekt gerundeten Wert fest.
Was Du als "statistisches Runden" beschreibst, hört sich für mich nach dem Einfügen von künstlichem Rauschen an (was vom Effekt her dann auf eine "mal-so-mal-so"-Rundungsregel hinausläuft).
Erinnert mich an Phänomene, die man bei Audio-/Signalverarbeitung haben kann, Stichworte "Quantisierungsfehler"/"Dithering".
Beispiel: Glaube die ersten Versionen des Audio-Editors Audacity hatten kein eingebautes Dithering. Hat man z.B. bei 16-Bit-PCM-Audio ein Fadeout gemacht, dann ergaben sich, kurz bevor eigentlich Stille eintreten sollte, schreckliche lautsprecherzerfetzende Störgeräusche - nicht als Fehler, sondern weil das aus Sicht des DA-Wandlers dann halt so in den digitalen Daten codiert und verlangt ist. Um dem zu entgehen, half es, das ausklingende Signal abschließend nochmal mit einigen dB weißem Rauschen zu überlagern.
==> vielleicht hilfreich, mal bzgl. "Dithering" weiterzuforschen, oder zu prüfen, ob sich das Problem in Deinem Anwendungsfall auch einfach durch Hinzufügen von künstlichem Rauschen austricksen ließe. (Sofern Gleitkommaarithmetik keine Option ist - vermutlich nicht(?) - ähm, wie gesagt: siehe ganz oben: (*) )
Wenn ich's richtig verstanden habe, geht's a priori um das Tool und weniger um die Klaerung der Begriffe, wobei ich das jetzt auch unter "symmetrischem Runden" eingetuetet haette. Aber ja, ich dachte auch erst mal an Error Diffusion.
Kann man denn beim HDL-Coder nicht einfach eine Blackbox-Funktion "my_round()" einschleusen und die nachher als HDL-Modul reinschlumpfen?
Was Du als "statistisches Runden" beschreibst, hört sich für mich nach dem Einfügen von künstlichem Rauschen an
Ja, das ist eine Möglichkeit, allerdings gibt es dazu auch noch eine intelligente Regelung drum herum, bedarfsweise.
Ich kannte "wissenschaftliches Runden" = zusätzliche Regel, um die Asymmetrie des kaufmännischen Rundens (in 5 Fällen auf-, nur in 4 Fällen abrunden) im statistischen Mittel zu beseitigen.
JA, mag sein. Wobei es ist ja nich nur eine Stelle. Schon bei zwei Stellen sind es 50:49 u.s.w
Quantisierungsfehler"/"Dithering
Ja klar, das ist eine Anwendung. Hatte dazu auch mal was geschrieben: Dithering
In VHDl habe ich das in allen Versionen, mein Problem ist, daß ich selbiges in MATLAB brauche, weil der Kunde alles in MATLAB macht. D.h. ich muss MATHWORKS beibringen, das zu codieren, was ich ansonsten per drop-in reinwerfe.
Der Umstand ist der, daß die Simulation auch innerhalb Simulink laufen muss und zwar mit 1:1 Modellen mit allem drum und dran, damit man das Systemverhalten high-level abstrakt simulieren kann und das Ganze möglichst ohne weiteren Aufwand.
Statistisches Runden: Eine Zahl, die nicht ganz ist, wird mit einer Wahrscheinlichkeit von je 0,5 nach oben bzw. nach unten zufällig gerundet. Der Beitrag, den diese Rundungsmethode zum Mittelwert aller Zahlen beiträgt ist statistisch gesehen exakt null. Somit bleibt der Mittelwert aller Zahlen unverändert.
:
Bearbeitet durch User
Um das nochmal zu klären:
Man kann das Ganze - wie üblich - natürlich mit einigen Bits mehr Auflösung erschlagen, weil dann genügend Genauigkeit mitgeschleppt wird, um alles weitere (genügend) richtig zu rechnen. Da reichen oft 4 Kommabits systemweit aus, lokal eventuell auch weniger! Dann klappen die Rundungen bzw. das Abschneiden, resp. es kratzt einen nicht. Dann wäre MATLAB's Modell sofort mit dem Code identisch und alles im Reinen.
Problem:
Schon 2-3 Bits mehr machen 4-6 Bits nach der Multiplikation und blähen nicht nur die Akkus auf, sondern erfordern gleich erheblich mehr Multiplier, weil die 18Bit-Grenze geknackt wird. Wie ich bei Xilinx schon mal diskutiert und gezeigt hatte, baut der Compiler zwar gemäß binomischer Formel (a+b)*(c+d) bei nur wenig "zuviel" erst einmal etwas Logik drum herum und kann da was einsparen, z.B. den 25-Bit Eingang nutzen und dann nur 3 MULs nehmen statt 4, aber das Ding wird sofort langsamer und größer.
-> Fetterer FPGA, der obendrein auch noch schneller sein muss, d.h. ein speed grad mehr. Das ist nicht so gut.
Jetzt habe ich ja genug Material, nur eben nicht im MATLAB.
Error Diffusion.
Faktisch ist es sowas.
Kann man denn beim HDL-Coder nicht einfach eine Blackbox-Funktion "my_round()" einschleusen und die nachher als HDL-Modul reinschlumpfen?
ja, Einschleusen tue ich das schon, aber es braucht eben jeweils die Komponente in MATLAB, als Symbol, für Simulink, also z.B. das XI-Blockset oder DSP-Blockset fürs Altera.
Ich werde mal einen Rauschgenerator drüberlegen, fürs Erste.
Statt (in MATHLAB) einen neuen Runder einzuführen, könnte man auch (falls vorhanden) parallel einen "Up-" und einen "Down-runder" instanzieren und mit einem nachgeschalteten Multiplexor entscheiden, welcher gerundete Wert in die nächste Iteration einfliesst.
Mit einer kleiennen Steuerungsblock am MUX-selector könnte man auch im Betrieb zwischen den verschieden Rundungsstrategien (allways up, allways down, intermediär, ...) umschalten. Natürlich kannst man auch dabei in das Problem des zusätzlichen Chiplevels (wegen dem Muxer) reinreinen, das könnte man aber bei Xilinx mit Nutzung der MUXF7, MUXF8, o.ä. abfangen.
:
Bearbeitet durch User
Ja, man könnte so eine Umschaltung per Rauschgenerator steuern, aber eine ausdrückliche Umschaltung der Rundung ist dann aber nichts anderes als die Rundung durch den statistisch beaufschlagten Wert und würde auch schwierig, weil nicht notwendigerweise immer matlabmäßig auf- und abgerundet wird, sondern eben auch je nach Zustand und Wert auch nicht, obwohl es müsste! d.h. es kann im Einzelfall auch mal eine 0,6 runtergezogen werden.
Ungeachtet dessen sehe ich den Zweck des Muxers nicht: Die Umschaltung in MATLAB könnte man genau so auch im Logik-Design des VHDLs vornehmen.
Und im Grunde will ich da auch nichts erweitern und groß nachrüsten, weil es auch an mehreren Stellen zu passieren hat.
Ich werde das nun mit deterministischem Rauschen lösen, das mit festen Werten arbeitet, die im MATLAB und im Block-RAM identisch sind. Damit ist das kongruent simulierbar.
Nochmals dazu:
Was ist denn statistisches Runden?
Ich habe nochmal gesucht: der offizielle Begriff ist "zufälliges" Runden und unter "randomized rounding" bekannt. Die deutsche Wikipedia kennt den (noch) nicht - die englische schon.
Lustigerweise sind die beiden ersten Zitate zu dem Thema ausgerechnet Publikationen von deutschen Mathematikern :D
Es wird wie gesagt zufällig gerundet, wobei die Wahrscheinlichkeit vom genauen Wert abhängt, d.h. eine Zahl mit 0,6 sollte mit 60% Wahrscheinlichkeit eine 1 werden und zu 40% eine 0 bleiben. Das bedeutet, daß auch eine 0,1 in einem von 10 Fällen eine 1 sein darf.
Damit bleibt der Durchschnittswert statistisch korrekt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.