Hi Leute ich arbeite seit einer Woche an einem mathematischen Konzept. Seit heute morgen bin ich dabei es via VHDL zu implementieren. Leider habe ich das Problem, dass einige Zwischenergebnisse recht groß werden. (Beispielsweise führt die Multiplikation von zwei 8-Bit Zahlen zu einem 16-Produkt). Am Ende würden diese Zahlen alle wieder kleiner, weil ich da dann dividiere. Das eigentliche Problem ist, dass der CoreGenerator nur Divider mit max 32-Bit Breite erstellen kann. Das reicht nicht aus für meine Zwecke. Hat jemand nen Tipp wie ich das lösen kann? thx for help Kiigass
Kiigass schrieb: > Das eigentliche Problem ist, dass der CoreGenerator > nur Divider mit max 32-Bit Breite erstellen kann. Das würde mir zu denken geben... > Das reicht nicht aus für meine Zwecke. Rechne einfach selber... Die Division dort funktioniert mit beliebigen Breiten: http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html BTW: wie schnell mußt du mit dieser Division fertig sein? > (Beispielsweise führt die Multiplikation von zwei 8-Bit Zahlen zu einem > 16-Produkt) Das liegt in der Natur der Dinge. Nur ist die Frage: Brauchst du dieses Ergebnis auch tatsächlich in der vollen Breite?
Der divider ist auch mit einer Schiebe Operation darstellbar. Dies wird in DSPs auch so gemacht. Im FPGA ist dies noch einfacher verdrahte einfach die unteren Bits nicht und benutz nur die oberen Bits vom Ergebnis. z.B. bei Accumulation von 16 Bit x 16 Bit in ener Schleife von 1024 Iterationen (1024 entspricht 10 Bit) also kann das Ergebnis im Worst case 16+16+10=36 Bit lang sein. Das Ergebnis normalisierst du indem du die oberen Bits die du nicht haben willst nicht benutzt. Wenn du nur 16 Bit brauchst nimmst du auch nur die 16 MSBs zum weiterrechnen (Most significant bits).
Uwe schrieb: > Der divider ist auch mit einer Schiebe Operation darstellbar. Nur dann, wenn der Divisor eine 2er-Potenz ist. > Das Ergebnis normalisierst du indem du die oberen Bits die du nicht > haben willst nicht benutzt. Wenn du nur 16 Bit brauchst nimmst du auch > nur die 16 MSBs zum weiterrechnen (Most significant bits). Die "most siginficant bits" sind üblicherweise die Oberen...
Ja schon klar man möchte im Normalfall aber mit 16 oder 15 oder 8 oder 7 oder 32 Bit weiterrechnen. Mit halben Bits rechnet man im Normalfall nicht weiter bzw. rundet dann auf das nächste Bit auf. Oder etwa nicht ?
> Das Ergebnis normalisierst du indem du die oberen Bits die du nicht Muss natürlich > Das Ergebnis normalisierst du indem du die UNTEREN Bits die du nicht heißen
Uwe schrieb: > z.B. bei Accumulation von 16 Bit x 16 Bit in ener Schleife von 1024 > Iterationen (1024 entspricht 10 Bit) also kann das Ergebnis im Worst > case 16+16+10=36 Bit lang sein. Die +10 Bit stimmen nicht. Bei der Addition zweier gleich breiter Vektoren kommt ein Bit dazu (16Bit+16Bit = 17Bit). Aber wenn auf diesen Vektor nochmal einer mit der originären Breite dazukommt, dann wird das Ergebnis nicht automatisch nochmal ein Bit länger. Denn ich könnte diese Addition ja auch als Baum aufbauen, hier mit einer 16 Bit-Addition von 10 Zahlen: Wert Bitanzahl 1 16 \ 2 16 ,+ 17 \ 3 16 \ + 18 \ 4 16 ,+ 17 / \ 5 16 \ \ 6 16 ,+ 17 \ + 20 7 16 \ + 18 \ / 8 16 ,+ 17 / `+ 19 / 9 16 \ \ / 10 16 ,+ 17 ,+ 18 / Es müsste also heißen >>> kann das Ergebnis im Worst case 16+16+log2(10)=32+4 Bit lang sein. <<<
ich schrieb > z.B. bei Accumulation von 16 Bit x 16 Bit in ener Schleife von 1024 > Iterationen (1024 entspricht 10 Bit) Also 16 Bit Multipliziert mit 16 Bit und 1024 mal aufaddiert (integriert). Oder auch 1024 mal die Summe von 16 Bit Multipliziert mit 16 Bit. Der Maximalwert ist 16+16+10 Bit
ähm ups 16+16+10 sind nicht 36 sonder und jetzt kommts 42 !!! Die Antwort auf Alles !
Uwe schrieb: > Also 16 Bit Multipliziert mit 16 Bit und 1024 mal aufaddiert Ok, übersehen. Dann passt das auch wieder mit ld(1024) = 10... ;-) Uwe schrieb: > Die Antwort auf Alles ! Q.E.D.
Uwe schrieb: > Mit halben Bits rechnet man im Normalfall > nicht weiter bzw. rundet dann auf das nächste Bit auf. Oder etwa nicht ? Eigentlich schon, weil man sich sonst Fehler mitreinschleppt. Die rundung sollte immmer der letzte Schritt sein. Selbst, wenn man sich in den Zwischenschritten 2 Bit mehr aufbehält, gibt es dann noch Fehler.
Paul schrieb: > Selbst, wenn man sich in den Zwischenschritten 2 Bit mehr aufbehält, > gibt es dann noch Fehler. Ohne Rundungsbehandlung hat man immer Fehler. Ich würde eher untehalb des letzten Bits runden und einen statistischen Fehler mitnehmen, der sich wegrechnet.
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.