48Bit BCD Code in Binärcode wandeln

[MemY (Gast)]

Hallo Leute,

ich habe ein kleineres Problem mit einer Konvertierungseinheit. 
Kompilieren lässt sich der Code, jedoch erscheint während der Simulation 
folgende Fehlermeldung:

# ** Warning: NUMERIC_STD.TO_UNSIGNED: vector truncated
#    Time: 0 ps  Iteration: 1  Instance: /gray_or_bcd_2_binary_tb/dut

Kann mir da jemand weiterhelfen?

Mein Code + TB ist im Anhang.

Vielen Dank schonmal vorab!

Gruß MemY

[Alexander F. (alexf91)]

Für deinen Fehler habe ich jetzt nichts spezielles, aber ich vermisse 
gray_2_b_out und bcd_2_b_out in der Sensitivity-List vom Prozess 
BCD_OR_GRAY.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Alexander F. schrieb:
> Für deinen Fehler habe ich jetzt nichts spezielles, aber ich
> vermisse gray_2_b_out und bcd_2_b_out in der Sensitivity-List vom
> Prozess BCD_OR_GRAY.
Und ich vermisse low_bcd und high_bcd (die übrigens völlig 
unnötigerweise im Prozess sind, die wären besser concurrent 
aufgehoben)...

Oder noch besser die sechs Zeilen hier:

  low_bcd(11 downto 0) <= l0;
  low_bcd(23 downto 12) <= l1;
  high_bcd(11 downto 0) <= h0;
  high_bcd(23 downto 12) <= h1;


  bcd_2_b_out(23 downto 0) <= low_bcd(23 downto 0);
  bcd_2_b_out(47 downto 24) <= high_bcd(23 downto 0);

Durch diese ersetzen:

  bcd_2_b_out <= h1 & h0 & l1 & l0;

Stichwort: Concatenation

Aber dein eigentliches Problem dürfte von den arithmetischen Operationen 
(Addition, Multiplikation) kommen, denn das Ergebnis der Rechnungen kann 
ein zusätzliches Übertragsbit ergeben, das dann abgeschnitten wird.

Übrigens glaube ich noch nicht, dass die BCD nach Binär Wandlung 
funktioniert. Es sei denn, du hast es im Vektor GRAY_OR_BCD_IN mit 4 
dreistelligen zusammengefügten BCD-Zahlen zu tun...

[berndl (Gast)]

was mir noch so aufgefallen ist:
* Du arbeitest z.T. mit nicht initialisierten Signalen und Variablen
* Verwendung von Variablen in nicht getakteten Prozessen: Du bringst da 
sequentielle Abhaengigkeiten (noch mehr als ohnehin im process) rein die 
dich bei komplexeren Sachen einholen werden. Warum nicht 'concurrent' 
und evtl. 'generate' loops?

[MemY (Gast)]

Lothar Miller schrieb:
> Übrigens glaube ich noch nicht, dass die BCD nach Binär Wandlung
> funktioniert. Es sei denn, du hast es im Vektor GRAY_OR_BCD_IN mit 4
> dreistelligen zusammengefügten BCD-Zahlen zu tun...

Hm.. im Vektor GRAY_OR_BCD_IN sind 12 BCD Zahlen enthalten:


GRAY_OR_BCD_IN[47..44]: hoechstwertigste BCD Zahl
GRAY_OR_BCD_IN[43..40]
GRAY_OR_BCD_IN[39..36]
.
.
.
GRAY_OR_BCD_IN[3..0]: niederwertigste BCD Zahl


Lothar Miller schrieb:
> Aber dein eigentliches Problem dürfte von den arithmetischen Operationen
> (Addition, Multiplikation) kommen, denn das Ergebnis der Rechnungen kann
> ein zusätzliches Übertragsbit ergeben, das dann abgeschnitten wird.

Glaube ich auch, gibt es da eine geschicktere Methode?

Gruß

[Schlumpf (Gast)]

die Variablen lO,l1,... müssen doch nur 10 Bit breit sein, da der 
zugewiesene Wert nur maximal 999 werden kann, oder sehe ich das falsch?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MemY schrieb:
> Hm.. im Vektor GRAY_OR_BCD_IN sind 12 BCD Zahlen enthalten:
Womit dann 1 Wert von 0..999999999999 darstellbar ist, oder womit 4 
unabhängige Werte von 0..999 dargestellt werden?

[MemY (Gast)]

Lothar Miller schrieb:
> Womit dann 1 Wert von 0..999999999999 darstellbar ist

Ja, im Prinzip ein Wert 1 BCD Wert aus dem Wertebereich von 
0..FFFFFFFFFFFF

[MemY (Gast)]

Sorry! Natürlich 1 BCD Wert aus dem Wertebereich von 0..999999999999.

[Lattice User (Gast)]

MemY schrieb:
> Sorry! Natürlich 1 BCD Wert aus dem Wertebereich von 0..999999999999.

Dafür braucht es dann 37 Bit Ausgabe.
Der einfache parallele Ansatz wird zum Resourcengrab.

Ausserdem programmiere das erst mal zu Fuss (d.h. ohne zuhilfenahme von 
Libraryfunktionen) in C. Aber nein, man kann das C Programm dann nicht 
einfach nach VHDL übersetzen, aber ohne zu verstehen wie man die Aufgabe 
in Teilaufgaben zerlegt hast du in VHDL keinen Chance.

Übrigens für GRAY funktioniert das ohnehin nicht. GRAY_OR_BCD ist also 
falsch.

Wo kommt die Eingabe her, und wie schnell muss es sein?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MemY schrieb:
> Sorry! Natürlich 1 BCD Wert aus dem Wertebereich von 0..999999999999.
Deshalb kannst du eben nicht einfach 4 mal 3 Zehnerstellen nach binär 
wandeln und die 4 Ergebnisse einfach binär aneinander ketten. Probiere 
das einfach mal mit der BCD Zahl 0000001000 aus (= dezimal 1000). Dein 
Ergebnis ist Hex 000000001000, das richtige wäre Hex 0000000003E8...

[MemY (Gast)]

Lattice User schrieb:
> Wo kommt die Eingabe her, und wie schnell muss es sein?

Die BCD Daten kommen von einem Sensor. Fuer die Auswertung habe ich 
schon ein paar Takte zeit. Allerdings auch nicht all zu viele ;-)

[MemY (Gast)]

Lothar Miller schrieb:
> Dein
> Ergebnis ist Hex 000000001000, das richtige wäre Hex 0000000003E8...

Mit diesem Ansatz ist zumindest in der Theorie die Umwandlung BCD -> 
Binaer korrekt.

BCD2Binary: process (GRAY_OR_BCD_IN)
variable zwergeb : unsigned(47 downto 0) := (others => '0');
begin
  zwergeb := unsigned(GRAY_OR_BCD_IN(3 downto 0))*1;  
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(7 downto 4))*10;  
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(11 downto 8))*100;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(15 downto 12))*1000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(19 downto 16))*10000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(23 downto 20))*100000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(27 downto 24))*1000000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(31 downto 28))*10000000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(35 downto 32))*100000000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(39 downto 36))*1000000000; -- 1000000000: Max. moegl. Wert
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(43 downto 40))*10000000000;
  zwergeb := zwergeb + unsigned(GRAY_OR_BCD_IN(47 downto 44))*100000000000;
  bcd_2_b_out <= zwergeb;
end process;

Jedoch sind die letzten beiden Multiplikationen, aufgrund des 
Wertebereichs der Integer, nicht zulaessig. Fehlermeldung:

GRAY_OR_BCD_2_BINARY.vhd(62): near "10000000000": (vcom-119) Integer value exceeds INTEGER'high.
GRAY_OR_BCD_2_BINARY.vhd(63): near "100000000000": (vcom-119) Integer value exceeds INTEGER'high.

Kann man dies umgehen? Oder muss ein komplett anderer Ansatz gewaehlt 
warden?

[MemY (Gast)]

Hat keiner eine Idee?

[Hagen R. (hagen)]

48Bit BCD in 2x24Bit BCD splitten, mit kleineren Konstanten 2x24Bit BCD 
umrechnen in binär, beide Binärwerte am Ende zusammenbauen, dabei den 
einen Wert um X Bits linksshiften. Ist Trivialwissen aus der 
Grundschule.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MemY schrieb:
> Jedoch sind die letzten beiden Multiplikationen, aufgrund des
> Wertebereichs der Integer, nicht zulaessig.
> Kann man dies umgehen?
Rechne mit unsigned Vektoren. Die kannst du beliebig lang machen...

> Oder muss ein komplett anderer Ansatz gewaehlt warden?
Das schon eher, denn dir wird 1. mit diesen Mosntermultiplizierern das 
FPGA zu klein und 2. das Design insgesamt zu langsam werden...

MemY schrieb:
> Fuer die Auswertung habe ich schon ein paar Takte zeit. Allerdings auch
> nicht all zu viele ;-)
Wenn du 12 Takte Zeit hast, dann könntest du einfach die 12 BCD-Stellen 
nacheinander über 1 Multiplizierer jagen und aufsummieren...

Pseudocode (mit links = BCD12, rechts = BCD0)

Sum = BCD(12);
Sum *=10;
Sum += BCD(11);
Sum *=10;
Sum += BCD(10);
Sum *=10;
Sum += BCD(9);
:
:
:
Sum *=10;
Sum += BCD(0);

Und jetzt kommt der Trick: das Ganze nicht einfach so hintereinander 
schreiben, sondern einen Takt einführen, der dann den Index 
weiterschaltet:

Warte_auf_Takt
wenn index =12 dann 
                summe = bcd(index);
                wenn start dann index = 11;
                
wenn index >0 dann 
                summe *=10; 
                summe += BCD(index);
                index --;

wenn index =0 dann 
                summe += BCD(index);
                index = 12;

[MemY (Gast)]

Lothar Miller schrieb:
> Wenn du 12 Takte Zeit hast, dann könntest du einfach die 12 BCD-Stellen
> nacheinander über 1 Multiplizierer jagen und aufsummieren...

Ja, 12 Takte haette ich auf jeden Fall zeit! Ich werde mir dein 
Pseudocode anschauen - Danke!

[Schlumpf (Gast)]

Hagen Re schrieb:
> Ist Trivialwissen aus der
> Grundschule.

Ist das so? Mir erschließt sich dein Vorgehen gerade nicht.

verkürztes Beispiel mit 16 Bit BCD:
BCD: 2073
Zerlegt:
BCD 20 = Hex 14 = Binär 0001 0100
BCD 73 = Hex 49 = Binär 0100 1001

Und wie baust du jetzt die beiden Zahlen zusammen und shiftest, dass das 
korrekte Ergebnis Hex 819 oder Binär 0000 1000 0001 10001 rauskommt?

[P. K. (pek)]

> Und wie baust du jetzt die beiden Zahlen zusammen und shiftest, dass das
> korrekte Ergebnis Hex 819 oder Binär 0000 1000 0001 1001 rauskommt?

Come on, so schwierig ist es nun auch wieder nicht:

X = 3 *    1 +
    7 *   10 +
    0 *  100 +
    2 * 1000

  = 0x0819

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

P. K. schrieb:
>> Und wie baust du jetzt die beiden Zahlen zusammen und shiftest, dass das
>> korrekte Ergebnis Hex 819 oder Binär 0000 1000 0001 1001 rauskommt?
> Come on, so schwierig ist es nun auch wieder nicht:
> X = 3 *    1 +    7 *   10 +   0 *  100 +    2 * 1000  = 0x0819
Das ist mein Verfahren. Aber: eine Addition ist kein Schieben. Mir 
ist das mit dem Schieben auch nicht klar...  ;-)

MemY schrieb:
> Lothar Miller schrieb:
>> Wenn du 12 Takte Zeit hast, dann könntest du einfach die 12 BCD-Stellen
>> nacheinander über 1 Multiplizierer jagen und aufsummieren...
> Ja, 12 Takte haette ich auf jeden Fall zeit! Ich werde mir dein
> Pseudocode anschauen - Danke!
Wenn du deinen Code dann fertig hast, kannst du ja mal mit meinem Code 
vergleichen:
http://www.lothar-miller.de/s9y/archives/89-BCD-nach-Binaer-wandeln.html

[MemY (Gast)]

Lothar Miller schrieb:
> http://www.lothar-miller.de/s9y/archives/89-BCD-na...

Dein Code ist natuerlich sehr elegant geloest! Habe nun den „BCD nach 
Binaer Wandler“ für meine Applikation implementiert und anhand deines 
Codes optimiert. Die Simulation bringt korrekte Ergebnisse!

Vielen Dank an dich Lothar, aber auch an die anderen!

Gruß MemY

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

MemY schrieb:
> Dein Code ist natuerlich sehr elegant geloest!
Es gibt nichts, was nicht noch besser ginge... ;-)
Die Multiplikation in dieser Zeile:

         tmp <= resize(tmp*10 + unsigned(BCD(idx*4-1 downto idx*4-4)),tmp'length);

Kann durch eine zusätzliche Addition ersetzt werden:

         tmp <= resize(tmp*8 + tmp*2 + unsigned(BCD(idx*4-1 downto idx*4-4)),tmp'length);

Der Synthesizer erkennt, dass tmp*8 und tmp*2 keine wirklichen 
Multiplikationen sind, und kann diese Operationen durch ein simples 
Umverdrahten erledigen. Kurz: es ist kein Multiplizierer nötig, das 
Design kann schneller getaktet werden...

[MemY (Gast)]

Lothar Miller schrieb:
> Kurz: es ist kein Multiplizierer nötig, das
> Design kann schneller getaktet werden...

Das ist natuerlich nochmal etwas besser ;-)

[Hagen R. (hagen)]

Lothar Miller schrieb:
> MemY schrieb:
>> Dein Code ist natuerlich sehr elegant geloest!
> Es gibt nichts, was nicht noch besser ginge... ;-)
> Die Multiplikation in dieser Zeile:
>

>          tmp <= resize(tmp*10 + unsigned(BCD(idx*4-1 downto 
> idx*4-4)),tmp'length);
>

> Kann durch eine zusätzliche Addition ersetzt werden:
>

>          tmp <= resize(tmp*8 + tmp*2 + unsigned(BCD(idx*4-1 downto 
> idx*4-4)),tmp'length);
>

> Der Synthesizer erkennt, dass tmp*8 und tmp*2 keine wirklichen
> Multiplikationen sind, und kann diese Operationen durch ein simples
> Umverdrahten erledigen. Kurz: es ist kein Multiplizierer nötig, das
> Design kann schneller getaktet werden...

simples Umverdrahten -> übertragen in mathe = multplikation zur Potenz 
mit Basis 2 -> shiften.

Du kannst also den 48Bit BCD in zb. 2*24Bit zerlegen, dann so rechnen 
wie oben und beide Zwischenresultate wieder in ein Resulat 
zusammenbauen. Dabei entstehen Additionen und Multiplikationen zur basis 
2, was man im FPGA durch Verdrahtung lössen kann und deine Konstanten 
werden in den Teilberechnungen kleiner, PEK hat es oben schon erkannt.

[Schlumpf (Gast)]

P. K. schrieb:
> Come on, so schwierig ist es nun auch wieder nicht:
>
> X = 3 *    1 +
>     7 *   10 +
>     0 *  100 +
>     2 * 1000

Aha... dass das so funktioniert, weiss hier glaub jeder. Aber damit hast 
du ja nicht wirklich neue Erkenntnisse herbeigebracht.

Lothar Miller schrieb:
> Das ist mein Verfahren. Aber: eine Addition ist kein Schieben. Mir
> ist das mit dem Schieben auch nicht klar...  ;-)

Mir ist auch nicht klar, was er damit gemeint hat:

Hagen Re schrieb:
> 48Bit BCD in 2x24Bit BCD splitten, mit kleineren Konstanten 2x24Bit BCD
> umrechnen in binär, beide Binärwerte am Ende zusammenbauen, dabei den
> einen Wert um X Bits linksshiften. Ist Trivialwissen aus der
> Grundschule.

[P. K. (pek)]

Schlumpf schrieb:
>> Come on, so schwierig ist es nun auch wieder nicht:
>>
>> X = 3 *    1 +
>>     7 *   10 +
>>     0 *  100 +
>>     2 * 1000
>
> Aha... dass das so funktioniert, weiss hier glaub jeder. Aber damit hast
> du ja nicht wirklich neue Erkenntnisse herbeigebracht.

Nein, natürlich nicht. Nur hatte weiter oben jemand Mühe mit dem Wissen 
aus der Grundschule:

Schlumpf schrieb:
> Hagen Re schrieb:
>> Ist Trivialwissen aus der
>> Grundschule.
>
> Ist das so? Mir erschließt sich dein Vorgehen gerade nicht.

Und wenn man dieses Wissen geeignet darstellt erschliesst sich manchem 
das vorgehen dann doch, z.B. dass die Multiplikation mit der Konstanten 
10 nicht wirklich eine Multiplikation ist, sondern die noch weiter oben 
erwähnte Shift-Geschichte.