Zahlenbereich bei Addition

R. K. schrieb:
> Ich könnte natürlich den Bereich des AdcInBufxDS auf +-200000 setzen,
> doch dies scheint mir unschön.

Du wirst nicht darum herumkommen, aber so schlimm ist das in Tat und 
Wahrheit ja nicht. Das bedeutet nichts anderes als Deinen "signed" Wert 
um 3 Bit aufzubohren (19 statt 16 Bit).

Also verstehe ich die korrekt:

Die Rechnung funktioniert auf der Registergrösse der Operanden und nicht 
des Resultats.
Ich muss die "AdcInBufxDS" mit dem grossen Bereich initialisieren, damit 
die Rechnung korrekt funktioniert. Den "NextDataInDecxS" kann ich jedoch 
auf den kleinen Bereich setzen.

Du kannst schon vor der Addition jeden Wert durch 8 teilen. Dauert zwar 
ein Moment länger, aber ich glaube nicht dass die Routine hier 
zeitkritisch ist.

Moritz A. schrieb:
> Du kannst schon vor der Addition jeden Wert durch 8 teilen. Dauert zwar
> ein Moment länger, aber ich glaube nicht dass die Routine hier
> zeitkritisch ist.

und den rest auch aufsummieren, zum schluss dividieren und dazuzählen, 
dann ist es sogar genau.

So müsste es gehen:

1

    SumxD           <= AdcInBufxDS(9) + AdcInBufxDS(8) + 

2

                       AdcInBufxDS(7) + AdcInBufxDS(6) + 

3

                       AdcInBufxDS(5) + AdcInBufxDS(4) + 

4

                       AdcInBufxDS(3) + AdcInBufxDS(2) + 

5

                       AdcInBufxDS(1) + AdcInBufxDS(0);

6

    NextDataInDecxS <= SumxD(18 downto 3); -- /8

NextDataInDecxS ist dann wieder ein 16-bit-signed.

Simulieren müsste Aufschluss geben.

Clemens S. schrieb:
> Moritz A. schrieb:
>> Du kannst schon vor der Addition jeden Wert durch 8 teilen. Dauert zwar
>> ein Moment länger, aber ich glaube nicht dass die Routine hier
>> zeitkritisch ist.
>
> und den rest auch aufsummieren, zum schluss dividieren und dazuzählen,
> dann ist es sogar genau.

Da er achtelt statt zehntelt ist es mit der Genauigkeit hier offenbar 
sowieso nicht so kritisch, daher habe ich den Rest großzügig liegen 
gelassen.

Moritz A. schrieb:
> Da er achtelt statt zehntelt ist es mit der Genauigkeit hier offenbar
> sowieso nicht so kritisch, daher habe ich den Rest großzügig liegen
> gelassen.

Das eine hat mit dem anderen nichts zu tun. Du verlierst nicht mehr an 
Genauigkeit, wenn Du leicht anders skalierst, falls in der 
darauffolgenden Rechnung die absolute Amplitude keine Rolle spielt.

Genau, die Division "/8" ist lediglich eine Skalierung, da es bei der 
späteren Berechnung nicht wirklich auf die absolute Amplitude ankommt 
ist dies vertretbar. Und die Division durch 8 (Ja ich schreibe Division, 
weil es ja nicht wirklich eins reiner shift ist, wegen des signed) ist 
viel einfacher als eine Division durch 10.

Bezüglich Verarbeitungszeit sehe ich überhaupt kein Problem. Ein 
FIR-Filter (also hier das Moving Average Filter) hat nunmal eine 
Verzögerung der "halben Ordnung" dies kann auch durch ein Piplining 
nicht verbessert werden. Oder sehe ich dies etwa falsch?

Die Ungenauigkeit durch die Division ist vertretbar und macht eine 
spätere Implementation auf einem günstigen ASIC-CPLD einfacher.

Peter K. schrieb:
> Das eine hat mit dem anderen nichts zu tun. Du verlierst nicht mehr an
> Genauigkeit, wenn Du leicht anders skalierst, falls in der
> darauffolgenden Rechnung die absolute Amplitude keine Rolle spielt.

Stimmt, mittlerweile hat der morgendliche Kaffee auch gewirkt :)

R. K. schrieb:
> Oder sehe ich dies etwa falsch?

Der Pipelining-Aufwand kommt dann noch oben drauf. Eine "billigere" 
Lösung wäre die Summe zu speichern und jeweils den neuen Wert addieren 
und den ältesten zu subtrahieren. Du kommst so mit 2 Addern aus 
(vergibst Dir aber die Möglichkeit, die Taps in Zukunft zu gewichten).

> Und die Division durch 8 ist viel einfacher als eine Division durch 10.

Falls Du es trotzdem mal genau brauchst: Division durch eine Konstante 
ist nicht so schlimm, das kannst Du immer auf eine Division durch 2^N 
und eine Multiplikation reduzieren...

Moritz A. schrieb:
> Du kannst schon vor der Addition jeden Wert durch 8 teilen. Dauert zwar
> ein Moment länger, aber ich glaube nicht dass die Routine hier
> zeitkritisch ist.
In Hardware ist eine Division durch eine Zweierpotenz einfach ein 
festes Umverdrahten. Das braucht überhaupt keine "Rechenzeit"...

Eine Division durch 10 könnte man auch mit einer Multiplikation mit 410 
und anschließendem Abschneiden der unteren 12 Bits hinreichend genau (1 
Promille Fehler) hinbekommen...

Nicolas S. schrieb:
> Wo kriegt man eigentlich solche Näherungen her?

Ist überhaupt kein Voodoo, Du willst durch 10 teilen, sprich mit 0.1 
multiplizieren. Jetzt gehst Du wie folgt vor:

1. Multiplizieren mit 2^N * 0.1
2. Weglassen der hintersten N Bits (i.e. teilen durch 2^N)

Den Fehler errechnest Du zu

3. Err = 0.1 / (ganzzahlgerundet(2^N*0.1) / 2^N)

So und jetzt musst Du nur noch N bestimmen, so klein wie möglich 
(Aufwand), so gross wie nötig (Fehler).

Nicolas S. schrieb:
> Aber wo lernt man solche Tricks?

Du hast ihn soeben hier gelernt...
...ich meinerseits vor ein paar Jahren bei der Arbeit. Solches Zeugs 
pushst Du Dir nicht gezielt in den Kopf, da kommt situationsbezogen 
immer wieder was dazu.