Hallo liebe Gemeinde, ich habe es mir mittlerweile mehrfach überdacht, komme jedoch mit meiner Erkenntnis nicht so recht weiter. Folgendes ist die Problemstellung: Ich habe einen 14 Bit AD-Wandler mit 2 Ein- und Ausgängen. Dieser gibt die digitalen Daten parallel als offset Binary aus. Gekoppelt sind die Ein- und Ausgänge derweil Single Ended. Somit kann ich die binären Daten also im Datenformat unsigned weiter verarbeiten. Nach einer Multiplikation der beiden Eingänge entstet jedoch ein 28 Bit Vektor, ebenfalls als unsigned/offset binary. Nun frage ich mich, wie ich den Ausgangsvektor sinnvoll auf 14 Bit kürzen kann, damit dieser wieder über den AD-Wandler ausgegeben werden kann. Bei einer Festkommaarithmetik hätte ich sicher kein geößeres Problem, wenn ich die LSBs rechts des Binärpunktes einfach abschneide, hier nimmt lediglich die Genauigkeit ab. In meinem Fall jedoch mache ich erhebliche Fehler, da alles über die 14 Bit hinaus einen Überlauf darstellt, wenn ich den Berreich o_mult(13 downto 0) nehme. Sehe ich das richtig? Wie kann ich damit nun umgehen?? Besten Gruß, Stephan
Stephan K. schrieb: > Wie kann ich damit nun umgehen?? Du darfst eigentlich immer nur die höchstwertigen Bits nehmen. Wenn du "00000000000001" * "00000000000001" rechnest, kommt "0000000000000000000000000001" heraus. Wenn du "11111111111111" mit "11111111111111" multiplizierst, kommt "1111111111111111111111111110" heraus. Und richtig wäre es jetzt für eine weitere Verarbeitung, mit den führenden Bits zu arbeiten, wenn am Eingang der gesamte Dynamikumfang verwendet wird. Stephan K. schrieb: > Nun frage ich mich, wie ich den Ausgangsvektor sinnvoll auf 14 Bit > kürzen kann, damit dieser wieder über den AD-Wandler ausgegeben werden > kann. Da muss man mit einer Konterfrage kommen und fragen: In welchen der 28 Ergebnisbits steckt denn die relevante Information? Wie groß sind deine Eingangswerte?
Lothar M. schrieb: > Stephan K. schrieb: >> Wie kann ich damit nun umgehen?? > Du darfst eigentlich immer nur die höchstwertigen Bits nehmen. Gelesen hatte ich das auch schon mehrfach, jedoch treten genau hier ja Rechenfehler in deinem zu erst genannten Beispiel auf. > Wenn du "00000000000001" * "00000000000001" rechnest, kommt > "0000000000000000000000000001" heraus. Die höchstwertigen 14 Bits bestehen nur aus Nullen. > Konterfrage: > In welchen der 28 Ergebnisbits steckt denn die relevante Information? > Wie groß sind deine Eingangswerte? Die Eingangswerte liegen bei ca. 1 V, also der halben Auflösung, auf dem ersten Kanal und bei voller Auflösung auf dem zweiten Kanal. Sind damit allein die LSBs schon vernachlässigbar, bzw. wie groß ist der Fehler den ich da mache? Gibt es keine Mölichkeit mit einem skalierungsfaktor zu rechenen oder wird das durch die Benutzung der höchstwertigen Bits irrelevant?
:
Bearbeitet durch User
Stephan K. schrieb: > Die höchstwertigen 14 Bits bestehen nur aus Nullen. Korrekt, weil die Eingangswerte so klein sind. > Die Eingangswerte liegen bei ca. 1 V, also der halben Auflösung, auf dem > ersten Kanal und bei voller Auflösung auf dem zweiten Kanal. Du kannst also links 1 Bit wegschneiden, wenn tatsächlich und garantiert(!) einer der Eingänge das LSB nicht ändert. > Sind damit allein die LSBs schon vernachlässigbar, bzw. wie groß ist der > Fehler den ich da mache? Der Fehler ist +1 LSB des abgetrennten Wertes. Denn z.B. der abgeschnittene "11111110001111" hätte genauso "1111111000111111111111111111" wie auch "1111111000111100000000000000" sein können. > Gibt es keine Mölichkeit mit einem skalierungsfaktor zu rechenen Du kannst bestenfalls nichtlinear 28 Bits auf 14 Bits reduzieren. Oder eben eine Fließkommazahl draus machen und z.B. aus "0000000110000110101010101010" nicht einfach die oberen Bits "00000001100001" abspeichern, sondern die 8 führenden Nullen zusätzlich als "111"abzuspeichern und dazu den Wert "11000011010101". Dann ist dein neues Format also 3 Bit Exponent und 14 Bit Mantisse. Zur ausgabe auf dem DAC musst du das natürlich wieder zurückskalieren, weil der ja mit einem Exponenten nichts anfangen kann.
WS schrieb: > Fliesskomma im FPGA? Kann man machen. Muss ja nicht IEEE-compliant double precision sein.
An der Stelle gibt es mehrere Fragen: 1) Welches ist die maximale Zahl, die aufgrund der "Füllstände" der Vektoren entstehen kann und welches Bit wird dabei ausgelastet? 2) Wie genau brauche Ich das Ergebnis im Bezug auf die Auflösungen der Eingänge? Sind beide Werte ähnlich genau oder ist der Multiplikator deutlich genauer? 3) Mit welcher Repräsentation will ich weiterrechnen, also wo sitzen die Kommastellen? Man kann das Ganze in Excel bauen und sich die Werte anhand der Auflösung (die sich ja an den Genauigkeiten der physikalischen Grössen zu orientieren hat) ausrechnen und designen. Das Thema hatten wir an anderer Stelle schon mehrfach. Was man beim Abschneiden unten beachten muss: Wie möchte Ich runden, um keinen unzulässigen Offset in den Datenstrom reinzuschleppen? Da hätten wir: a) Addition mit 0,5 b) statistische Addition mit 1 - also Rauschen Mit Methode b) arbeite Ich z.B. bei meinen Oszillatoren: Damit laufen die Filter in der Tat gegen Null, ansonsten gibt es digitale Artefakte.
Jetzt mal konkret als Beispiel: 40% Kanal 1 x 60% Kanal 2 macht insgesamt 24% des durch die Summe der Bits darstellbaren Zahl. Es fallen also 2 weg. Ansonsten nur eins oder eben auch keins, bei z.B. 80%x80%. Bei signed fällt eigentlich immer 1 weg, bei dem von mir empfohlenen Limit auf 2hn-1 für +/- sind es immer 2. D.h. man nimmt bei einem Wandler nicht 1023 ... -1024 sondern nur runter bis -1023. Eine Quadierung liefert dann maximal 20 bit im Positiven, statt 22. Stephan K. schrieb: > Sind damit allein die LSBs schon vernachlässigbar, bzw. wie groß ist der > Fehler den ich da mache? Bei einer Multiplikation würde Ich immer mal eine -> Fehlerrechnung machen, also "Wert 1 +/- Delta 1" x "Wert 2 +/- Delta 2" -> ? Damit bekommst Du einen Hinweis auf die benötigte Auflösung. Generell beantwortet, schleppst Du 4 Bit mehr mit, als der schlecht aufgelöste Wert - das passt meistens, es sei denn da kommt irgendwann noch eine Subtraktion.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.