Spartan3E und rechnen mit großen Zahlen

Kiigass Gast #2468947
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #2469006
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Uwe Gast #2469023
Lesenswert?
• ▲
▼ 
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).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #2469055
Lesenswert?
• ▲
▼ 
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Uwe Gast #2469072
Lesenswert?
• ▲
▼ 
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 ?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #2469111
Lesenswert?
• ▲
▼ 
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. <<<
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Uwe Gast #2469126
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Paul Gast #2469202
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
BB Gast #2538026
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren