Hallo, ich habe mich schon des Öfteren gefragt warum die Hardware Multiplizierer in FPGA's ausgerechnet 18 bit haben und keinen 2^n-Wert. Weiß von euch zufällig wer was das für einen technischen oder historischen Hintergrund hat? lg much
Das läuft letztendlich wahrscheinlich auf die Frage raus, warum FPGAs 9 (oder 18) Bit breits Block-RAM haben. Und die lässt sich wohl mit "dann geht auch Parity" beantworten.
Nee, das hat eher mit Overflow und Rundung zu tun. Und solche Features möchte man für Kaskadierung der Multiplier (32 bit, float, usw.) haben. Dazu sollte aber eine Menge im Netz zu finden sein.
Michael N. schrieb: > ich habe mich schon des Öfteren gefragt warum die Hardware > Multiplizierer in FPGA's ausgerechnet 18 bit haben und keinen 2^n-Wert. > Weiß von euch zufällig wer was das für einen technischen oder > historischen Hintergrund hat? Was spricht für 2**n ? Entscheidend ist doch die Auflösung der prozessierten Daten und die richtet sich üblicherweise nach der Quantisierung des Sensor resp. A/D wandlers als Datenquelle. Und die liegt trotz aller Bit-Fetischisten eher im 10bit statt im 16 oder gar 32 bit Bereich. Die unteren bits tragen eh nur rauschen und keine Information.
Bitwurschtler schrieb: > Entscheidend ist doch die Auflösung der prozessierten Daten und die > richtet sich üblicherweise nach der Quantisierung des Sensor resp. A/D > wandlers als Datenquelle. Und die liegt trotz aller Bit-Fetischisten > eher im 10bit statt im 16 oder gar 32 bit Bereich. Die unteren bits > tragen eh nur rauschen und keine Information. Naja, bei einer anderen Breite hätte ich mir das auch so erklärt. Bei 10 oder 12 bit hätte ich auch sofort an die Quantisierung mit einem ADC gedacht. 18bit ADC's gibt es zwar auch aber die gehören doch eher zu den Exoten. Zumindest ist mir bislang soweit ich mich erinnern kann noch keiner untergekommen. Im Audio-Bereich werden meines Wissens nach auch 24 bit verwendet aber ausgerechnet 18 bit kenne ich eigentlich nur von den HW-Multiplizierern in FPGA's. Martin S. schrieb: > Nee, das hat eher mit Overflow und Rundung zu tun. Das klingt für mich bis jetzt am plausibelsten.
Die internen BlockRAMs haben 9 Bits statt 8 Bits (bzw. 18 statt 16 etc.). D.h. für eine "optimale" Nutzung wurden die DSPs bzw. Multiplier einfach an die BRAM-Breite angepasst. Es gibt's bei Xilinx etliche Docs zum Thema "Wo und wie sollen DSPs am Besten neben BRAMS plaziert werden".
Wie hättest du denn 16 Bit gerne? Mit oder ohne Vorzeichen? Mit einem 18 Bit 2er-Komplement Multiplizierer kriegt man beides ohne weiteres hin.
Es hat natürlich mit der Breite der internen RAMs zu tun. Für ein FIR Filter z.B. brauchst du einen Koeffizientenspeicher, der normalerweise mit einem BRAM implementiert wird, und dann den einen Eingang zum Multiplizierer bildet. Breitere Multiplizierer wären schön, aber das ist halt auch eine Frage der Chipfläche die sie belegen. Ich denke die steigt irgendwie quadratisch zur Bitzahl. Die Lattice ICE40-Ultra DSPs haben z.B. 16x16 Multiplizierer, da sie auch nur 8/16 bit breite interne RAMs haben. Andi
Sigi schrieb: > Die internen BlockRAMs haben 9 Bits statt 8 Bits > (bzw. 18 statt 16 etc.). D.h. für eine "optimale" > Nutzung wurden die DSPs bzw. Multiplier Das liegt (auch) daran, dass BRAMs gegen Multiplier ausgetauscht werden können und sollen. In früheren Tagen waren solche Multiplier nichts anderes, als RAMs mit entsprechender Belegung. Bei manchen FPGAs (z.B. beim Spartan) teilen sich die RAMs und die MULs (deswegen!) die Zuleitungen. Wer viele RAMs verbrät, hat(te) dann irgendwann Probleme mit den MULs! Das Nette dabei ist, dass die Resourcen ja immer gerne getrennt aufgeführt werden, sodass sich manch einer wundert, warum mit ein paar mehr RAMs nicht nur die 9er RAMs und die scheinbar parallel verfügbaren 18er RAMs gleichzeitig dahinschmelzen, sondern auch die effektiv verfügbaren DSP-Elemente verdunste(te)n.
Michael N. schrieb: > Bitwurschtler schrieb: >> Entscheidend ist doch die Auflösung der prozessierten Daten und die >> richtet sich üblicherweise nach der Quantisierung des Sensor resp. A/D >> wandlers als Datenquelle. > Naja, bei einer anderen Breite hätte ich mir das auch so erklärt. Bei 10 > oder 12 bit hätte ich auch sofort an die Quantisierung mit einem ADC > gedacht. 18bit ADC's gibt es zwar auch aber die gehören doch eher zu den > Exoten. Naja die ideale Zuordnung ist ja nicht 1:1 bzgl der Bitbreite. Für einen 16bit Ad-wandler muß man zur Ausnutzung des dynamikbereiches 18 bit in der Signalverarbeitung vorsehen. Die 18 bit Multiplies passen also gut für 16 bit ad-wandler. Beispiel Mittelwertbildung: (Sample1 + Sample2) /2 da muss man für das Zwischenergebniss 1 bit mehr vorsehen um Überlauf zu verhindern. Oder man halbiert die werte vor der Addition aber damit schmeisst man 1 bit Genauigkeit und damit dynamik weg. Mit einem 18 bit Multiplizierer kann man also die Werte von einem 16 bit Wandler mit geringen Einschränkungen hinsichtlich des Dynamikumfangs verarbeiten. Beim Upsampling geht man sogar "noch mehr in die Breite", dort multipliziert man die 12 bit samples mit 25bit Koeffizienten: http://www.xilinx.com/support/documentation/xcell_articles/efficient-parallel-real-time-upsampling-with-xilinx-fpgas.pdf MfG,
Fpga K. schrieb: > Mit einem 18bit Multiplizierer kann man also die Werte von einem 16 bit > Wandler mit geringen Einschränkungen hinsichtlich des Dynamikumfangs > verarbeiten. So ist es. Das ist das, was viele gerne unterschlagen, wenn sie mit einem DSP arbeiten, weil sie glauben, dass eine durchgängige 16-Bit-Auflösung generell reicht. Wenn man aber multipliziert, entstehen "krumme" Zwischenwerte, die einer Rundung unterliegen und die Auflösung letzlich mindern. 2 Bit mehr führen da zu einer 1/4 Auflösung, die in der Tat meistens passt. Ohne es genauer zu untersuchen, spendiere ich gerne 4 Bit, um den einschlägigen Faktor 10 zu überwinden. > Beim Upsampling geht man sogar "noch mehr in die Breite", dort > multipliziert man die 12 bit samples mit 25bit Koeffizienten: ... was im konkreten Fall auch daran liegt, dass Xilinx zufällig 18x25 Bit Multiplier im Gepäck hat und sich die 25 für Koeffizienten geradezu anbieten. Aber genau so mache ich das bei den meisten Apps: 16 Bit rein und 24 Bit Koeffizienten für die FIR-Filter, weil sich da die Fehler aufsummieren. Wenn man sich das genauer ansieht, dann erkennt man, dass man auch mit einer geringen Anzahl an Filter-TAPs einen sehr genauen, zum Analogverlauf des Filters passenden Filtereffekt bekommt, wenn die Auflösung gut genug ist. Als Faustregel kann man die Wurzel heranziehen: 1024 TAPs kumulieren statistisch zu 32 Digit Fehler, die man mit 5+4=9 bit mehr an Auflösung abfangen kann. Macht bei 16 Bit Eingang eben 25 Bit für die Koeffizienten. Diese statistische Güte lässt sich durch Dithering in der Rechnung auch regelmäßig für ungünstige Datenströme erreichen. Beim Audio-Prozessor verwende ich bis zu 16384 TAPs. Kommt also auf eine Rechnungsauslösung von 8+4 = 12 Bit mehr für die Koeffizienten, damit alle Samples korrekt passen, auch wenn einige leer sind, peaks und spikes drin sind. Für 24 Bit Rohaudio landen wir damit bei 36Bit Auflösung für die Koeffizienten. Das sind dann jeweils 3 verkettete 25 x 18(x2) -er MULs.
SeriousSam schrieb: > Wie hättest du denn 16 Bit gerne? Mit oder ohne Vorzeichen? Wenn man es in dem Format hat, in dem die Daten kommen, braucht man immer 16 Bit. Ein Vorzeichen oder ein headroom wäre völlig konsistent, oder man braucht schon bei den Daten mehr Bits. Wäre halt schade, wenn man 1-2 bit mehr Auflösung braucht, die Datenbits breiter macht und dann das nächste Blockram antasten müsste.
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.