große Dezimalwerte in VHDL zuweisen

[Tomse (Gast)]

Ich muss einem VHDL-Vektor einen Wert zuweisen , der 64 Bit auslastet 
und würde gerne die aus MATHCAD generierten Werte nehmen. Das sind 
positive Dezimalwerte.

Bei der Zuweisung bekomme ich aber schon beim INIT einen ÜBerlauffehler:

signal rtm_wert : std_logic_vector(63 downto 0) <= std_logic_vector 
(to_unsigned( 5030521883283424760,64));

Was könnte da falsch sein?

Wenn ich es mit CALC umrechne auf Bit und zuweise geht es:

signal rtm_wert : std_logic_vector(63 downto 0) := 
"100010111010000000000001111111111111111111100000000010111111000";

benutzt wird:

use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

[-gb- (Gast)]

Tomse schrieb:
> signal rtm_wert : std_logic_vector(63 downto 0) <= std_logic_vector
> (to_unsigned( 5030521883283424760,64));

:= statt <=

[Tomse (Gast)]

Kleine Korrektur, auch im CALC geht es auch nicht. Der Calc läuft da 
auch über. Die Werte scheinen zu groß zu sein. Der hier z.B. 
18445829279364155008. Da muss ich mal Rücksprache mit den Kollegen 
halten, ob die überhaupt stimmen.

Der automatische erzeugte Code in Verilog sieht so aus:

64'd 5030521883283424760
64'd18445829279364155008

[Tomse (Gast)]

-gb- schrieb:
> := statt <=
Da habe ich was falsches rauskopiert, es war kein Syntaxproblem.

So war es:

signal rtm_wert : std_logic_vector(63 downto 0) := std_logic_vector 
(to_unsigned( 5030521883283424760,64));

response:
** Error: D:\rtm_generator\src\rtm.vhd(37): near "5030521883283424760": 
(vcom-119) Integer value exceeds INTEGER'high.

[Simon L. (dfgh)]

Numerische (dezimale) Literale sind leider erstmal integer, bevor man 
sie in unsigned(mein int) stecken kann.

Mit den Vektorvarianten x"AFFEC0FFEEDEADBEEF" (x für Hex) geht es aber.

Wenn man große Zahlen unbedingt dezimal schreiben will, könnte man die 
Ziffern in ein Hexliteral gießen und die Umrechnung zur richtigen Zahl 
schnell mal als Funktion schreiben. Da du intialisierst kostet das ja 
keine Hardware.

[Tomse (Gast)]

Ja, könnte man, leider fehlt mir momentan der Ansatz, wie ich aus den 
gegebenen Dezimalwerten gültige Zahlen mache, die ich zuweisen kann.

Ich könnte ja HEX nehmen, aber die laufe auch irgendwie über.

Der größte Wert für z.B. 3FFF...F ist 9223372036854775807

D.h. der 18445829279364155008 kann gar nicht in 64 bit passen.

Ich frage mich was der soll. Kann jemand diese Veriloganweisung 
interpretieren? muss ich die 1 weglassen?

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

Tomse schrieb:
> der 18445829279364155008 kann gar nicht in 64 bit passen.
Warum nicht? Das ist (unsigned) FFFC_BFFF_DA22_FA00. Da ist also schon 
noch "Luft" bis FFFF_FFFF_FFFF_FFFF.

> Der größte Wert für z.B. 3FFF...F ist 9223372036854775807
Der höchste signed 64-Bit Wert 7FFF_FFFF_FFFF_FFFF entspricht der obigen 
Dezimalzahl. signed FFFF_FFFF_FFFF_FFFF wäre dann ja -1. Und signed 
1000_0000_0000_0000 sind -9223372036854775808.

Simon L. schrieb:
> Numerische (dezimale) Literale sind leider erstmal integer
Und leider ist integer'high noch immer nur 2^31-1.

[DurchDieGegendWandern.not_blind (Gast)]

Der TO sollte mal die konkrete Fehlermeldung des Tools hier wiedergeben, 
als die Experten stumpf raten zu lassen.

Wie in den Antworten zu sehen ist, kann es kein Überlauffehler sein, da 
der bspw  der Syntax falsch geschrieben ist.

Und natürlich ist zu klären, welches tool hier den Fehler schmeisst.

[Christoph Z. (christophz)]

Simon L. schrieb:
> Wenn man große Zahlen unbedingt dezimal schreiben will, könnte man die
> Ziffern in ein Hexliteral gießen und die Umrechnung zur richtigen Zahl
> schnell mal als Funktion schreiben. Da du intialisierst kostet das ja
> keine Hardware.

Interessanter Ansatz, gefällt mir aber nicht so, weil ich ein gültiges 
Hexliteral habe, das aber ohne Umrechnung (die man vergessen könnte 
hinzuschreiben) falsch ist.

Als Umweg aus dem Problem, das INT'high nur 2^31-1 ist, könnte man 
trotzdem mit Funktionen arbeiten aber vielleicht besser in der Form von 
unendlich genauen Decimals. Das wäre in VHDL am einfachsten ein Array 
vom Typ int jeweils mit range 0 to 9.

Dann überlädt man noch die Funktion to_unsigned mit einer eigenen für 
diesen neuen Arraytyp und es sollte klappen, ohne das es gross anders 
aussieht. Die Zuweisung müsste wohl dann etwa so gehen:
signal rtm_wert : std_logic_vector(63 downto 0) := std_logic_vector
(to_unsigned("5030521883283424760",64));

Hab ich etwas übersehen, das meiner Idee im Weg steht?

[Leierkastenopa (Gast)]

Christoph Z. schrieb:
> Hab ich etwas übersehen, das meiner Idee im Weg steht?

Ja, den test mit einem Synthesetool.
Die haben sich oft zickig, wenn man standard-Funktionen nach 
Gutsherrenart verbiegt aehm, overloaded. VHDL ist nicht C++.

[VHDL hotline (Gast)]

Lothar M. schrieb:
> Und leider ist integer'high noch immer nur 2^31-1

"Bald" nicht mehr.

https://vhdlwhiz.com/vhdl-2019/#long-integers

[Markus F. (mfro)]

Warum kein VHDL 2008?

Da schreibt man einfach

signal rtm_wert  : std_logic_vector(63 downto 0) := std_logic_vector(unsigned'(64d"5030521883283424760"));

und hat kein Problem mit "verkrüppelten" 32 Bit Integern.

[Tomse (Gast)]

Lothar M. schrieb:
>> der 18445829279364155008 kann gar nicht in 64 bit passen.
> Warum nicht? Das ist (unsigned) FFFC_BFFF_DA22_FA00. Da ist also schon
> noch "Luft" bis FFFF_FFFF_FFFF_FFFF.

Tja, da stehe ich wohl komplett auf dem Schlauch. Ich habe das in den 
CALC eingegeben und mich daran aufgehängt. Der rechnet aber auch signed, 
wie mir scheint und hat noch andere Probleme, weil er vorn abschneidet.

Wenn ich dort z.B. die o.g. Zahl eingebe, druckt er mir binär das aus
11001100.11001010.00110011.00110011.00010011.00110011.00111000.01100
da fehlen also Stellen.

In der kleinen Ansicht sieht man die führenden Nullen.

Wenn ich deinen HEX eingebe, geht es: er bringt halt nur einen negativen 
Wert.

Kennt jemand einen Rechner, der das nicht falsch macht?

Das andere Problem mit dem limitierten Integer habe ich verstanden. 
Hatte ich auch übersehen.

Das Dumme ist wie gesagt, dass die Zahlen aus MATHCAD eben in Real 
rauskommen und ich nur die Zahlen habe. Hex wäre super, das kann ich 
zuweisen.

[Markus F. (mfro)]

Tomse schrieb:
> Lothar M. schrieb:
>>> der 18445829279364155008 kann gar nicht in 64 bit passen.
>> Warum nicht? Das ist (unsigned) FFFC_BFFF_DA22_FA00. Da ist also schon
>> noch "Luft" bis FFFF_FFFF_FFFF_FFFF.

ich glaub', Lothar (oder sein Taschenrechner) hat sich da verrechnet.

Das ist tatsächlich (jedenfalls nach meiner Rechnung) 
FFFC_BFFF_D800_0680.
Recht hat er trotzdem.

[Tomse (Gast)]

Ja, ich denke, die Zahlen stimmen. Die Hinternisse sind offenbar INT im 
VHDL und im PC, die das limitieren. Interessante Erkenntnis.

Bleibt die Frage nach einem Window-Taschenrechner, der 64 Bit breite 
Dezimalwerte korrekt und direkt in HEX umrechnet. Den CALC kann ich 
nicht auf unsigned umstellen oder dazu bewegen mit dieser großen Zahl zu 
rechnen.

Müsste man erst splitten, nehme ich an. Z.B. 8 Bit wegnehmen und die per 
Hand in HEX umbauen.

[Samuel C. (neoexacun)]

Muss ja nicht zwingend ein Windows-kompatibler Rechner sein.

https://www.wolframalpha.com/input?i=18445829279364155008+to+hexadecimal

[Tomse (Gast)]

Markus F. schrieb:
> Da schreibt man einfachsignal rtm_wert  : std_logic_vector(63 downto 0)
> := std_logic_vector(unsigned'(64d"5030521883283424760"));
> und hat kein Problem mit "verkrüppelten" 32 Bit Integern.

VHDL 2008 ist die Lösung! Danke!

[Markus F. (mfro)]

Tomse schrieb:
> Ja, könnte man, leider fehlt mir momentan der Ansatz, wie ich aus den
> gegebenen Dezimalwerten gültige Zahlen mache, die ich zuweisen kann.

So zum Beispiel (die Routine ist signed und muss deswegen ein Bit mehr 
haben als 64):

library ieee;
use ieee.numeric_std.all;
use std.textio.all;

entity large_decimals is
    generic
    (
        BITS    : natural := 65;
        DEBUG   : boolean := false
    );
end entity large_decimals;

architecture sim of large_decimals is

    -- missing from numeric_std
    function "**"(num : signed; exp : signed) return signed is
        variable result  : signed(BITS - 1 downto 0);
        variable e : signed(BITS - 1 downto 0);
    begin
        result := num;
        e := exp;
        if e = 0 then return to_signed(1, BITS); end if;
        l : loop
            assert not DEBUG report "result=" & to_hstring(result) severity note;
            e := e - 1;
            if e = 0 then
                exit;
            end if;
            result := resize(result * num, result'length);
        end loop;
        return result;
    end function "**";

    function to_dstring(s : signed) return string is
        function to_dstring_recursive(s : signed) return string is
            variable digit : character;
        begin
            digit := integer'image(to_integer(s mod 10))(1);
            if s / 10 > 0 then
                return to_dstring(s / 10) & digit;
            end if;
            return to_string(digit);
        end function to_dstring_recursive;

        variable digit : character;
    begin -- to_dstring
        digit := integer'image(to_integer(s mod 10))(1);
        if s / 10 > 0 then
            return to_dstring_recursive(s / to_signed(10, s'length)) & digit;
        end if;
        return to_string(digit);
    end to_dstring;


    procedure int64_read(variable ln : inout line; num : out signed; good : out boolean) is
        constant dvals      : string := "0123456789";
        variable c          : character;
        variable maxdepth   : signed(BITS - 1 downto 0);

        --
        -- translate a single numeric ('0' - '9') into its integer equivalent.
        -- Return -1 if character isn't identified as valid numeric
        --
        function ival(c : character) return signed is
        begin
            for i in dvals'range loop
                if dvals(i) = c then
                    return to_signed(i - 1, BITS);
                end if;
            end loop;
            -- if character isn't numeric
            return to_signed(-1, BITS);
        end function ival;

        --
        -- check if character is a numeric.
        --
        function is_dec(c : character) return boolean is
        begin
            return ival(c) /= to_signed(-1, BITS);
        end function is_dec;

        --
        -- The recursive part of int64_read. Collects single digit's numerical values in
        -- string in a recursive descend until it hits a non-digit character.
        -- Then, on ascent of the recursive call, adds up all the collected digits
        -- multiplied by ther digit position's valence.
        --
        -- TODO: lacks any overflow checks.
        --
        impure function recursive_int64_read(depth : signed) return signed is
            variable num    : signed(BITS - 1 downto 0);
            variable c      : character;
        begin
            -- peek into the line buffer to see if there is another numeric character
            if ln.all'length > 0 and is_dec(ln.all(ln.all'left)) then
                read(ln, c);
                num := ival(c);
                assert not DEBUG report "digit = " & c severity note;
                return recursive_int64_read(depth + 1) + num * 
                                                         to_signed(10, BITS) **
                                                         (maxdepth - depth);
            else
                -- walk on, nothing to see here
                maxdepth := depth - 1;
                return to_signed(0, BITS);
            end if;
        end function recursive_int64_read;

    begin -- int64_read
        maxdepth := to_signed(0, maxdepth'length);
        -- skip leading white space
        if ln.all'length > 0 then
            skip_loop: for i in ln.all'range loop
                if ln.all(ln.all'left) = ' ' or ln.all(ln.all'left) = HT then
                    read(ln, c);
                else
                    exit skip_loop;
                end if;
            end loop;

            -- call recursive part
            num := resize(recursive_int64_read(to_signed(1, BITS)), num'length);
            -- error checking
            if maxdepth < 1 then
                good := false;
            else
                good := true;
            end if;
        end if;
    end int64_read;

begin   -- architecture sim
    p_initial : process
        variable l      : line;
        variable s      : signed(BITS downto 0);
        variable good   : boolean;
    begin
        l := new string'("18445829279364155008");
        
        int64_read(l, s, good);

        if good then
            write(output, "result= " & to_dstring(s) & " (" & to_hstring(s) & ")");
        else
            write(l, "error reading from string " & l.all);
            writeline(output, l);
        end if;
        wait;
    end process p_initiaL;
end architecture sim;

result= 18445829279364155008 (0FFFCBFFFD8000680)

[Christoph Z. (christophz)]

Tomse schrieb:
> Bleibt die Frage nach einem Window-Taschenrechner, der 64 Bit breite
> Dezimalwerte korrekt und direkt in HEX umrechnet.

Ich nehme gerne SpeedCrunch:
https://heldercorreia.bitbucket.io/speedcrunch/

Zum Rechnen kannst du binär und hex wie gewohnt eintippen. Potenz geht 
wie in C oder in Python beides (^ oder **), constanten etc. gibt es 
auch.

Die Resultate musst du auch nicht in HEX umrechnen, sondern zu schaltest 
einfach die Basis um, in der die Resultate angezeigt werden (das geht 
mit F4 bis F8).

Gibt es für übliche Betriebssysteme und läuft auch Portabel, wenn man 
nix installieren darf.

[Tomse (Gast)]

Werde ich probieren! Danke!

[Christoph db1uq K. (christoph_kessler)]

>SpeedCrunch
Danke für den Tip, hab es unter Ubuntu installiert, ging problemlos.

Beitrag "Re: Hilbert Transformation im uC berechnen"
da hatte ich auch breitere Berechnungen benötigt als sie LibreOfficeCalc 
erlaubt. Eine Zerlegung in Binärbrüche um ein IIR-Filter ohne 
Multiplizierer in einem CPLD unterzubringen.

Sollwert:                      0,161758498367701
LibreOfficeCalc aus Binärzahl: 0,161758423782885
mit Speedcrunch berechnet:     0,161758498288691
also fast 10 Stellen identisch, mit LibreOffice sind es nur 7. Der Rest 
kann ein Rundungsfehler sein, da nur die ersten 32 binären 
Nachkommastellen berücksichtigt sind.

Eingabe dazu in Speedcrunch (die Hilfefunktion ist gut verständlich):
dec(0b0,00101001011010010000000101000100)

[Tomse (Gast)]

Woraus definiert sich hier der "Sollwert"? Ist das die Realzahl und die 
anderen die rückgerechneten Werte aus der zwischenzeitlichen 
Transformation in Binär?

[Christoph db1uq K. (christoph_kessler)]

Ja genau, der Sollwert liegt dezimal vor, die anderen sind vom 
Binärbruch auf dezimal zurückgerechnet.

Ich habe einen Text von 2001, darin sind 8 Koeffizienten für ein 
IIR-Filter genannt. Die müssen noch quadriert werden, damit werden sie 
doppelt so breit. Die Zahl 0,161758498367701 ist der kleinste quadrierte 
Koeffizient.
Quadriert habe ich mit dem Gnome-Calculator, der rechnet mit bis zu 64 
Bit, kennt aber keine Binärbrüche im Gegensatz zum SpeedCrunch.

Normalerweise wird dann in einem DSP oder Mikrocontroller damit 
multipliziert. Ich habe aber einen anderen Text aus der Zeit, in dem ein 
"multiplierless" IIR-Filter beschrieben ist, das so in ein CPLD passen 
soll.
Dazu muss ich die 8 quadrierten Koeffizienten zu einer (hier auf 32 Bit 
gerundeten) Summe von Binärbrüchen umformen. Dann braucht man nur noch 
Addierer und Schieberegister, was (hoffentlich) weniger Platz im CPLD 
braucht als 8 Multiplizierer mit mindestens 16 Bit Breite, oder 
ersatzweise auch ein einziger Multiplizierer, der acht Berechnungen 
nacheinander durchführt.

[dfIas (Gast)]

Ist denn überhaupt eine so hohe Auflösung nötig? Was passiert, wenn man 
auf ein paar Bits verzichtet? Braucht die Anwendung diese Genauigkeit 
oder ist es der Rechentechnik geschuldet, damit keine störenden 
Artefakte entstehen? Man kennt solche Probleme z. B. bei 
Potenzreihenentwicklungen, die bei unzureichender Näherung schnell ins 
Oszillieren geraten.
Für Astronomie brauchte man sehr hohe Genauigkeiten, hieß es mal. Dafür 
wurden Programmiersprachen entwickelt, die das unterstützten. Aber ich 
vermute, dass man seinerzeit Auflösung und Dynamik nicht unterschieden 
hatte. Ein Sonnensystem, dass Millionen Lichtjahre entfernt ist, da 
kommt es doch wohl nicht mehr auf einen Zentimeter an.

[Christoph db1uq K. (christoph_kessler)]

Ich kann dazu nur den Artikel zitieren.

Beitrag "Re: Hilbert Transformation im uC berechnen"
das sind die beiden Texte, um 2001 als Zeitschriftenartikel und als 
Kapitel in einem Buch erschienen. Damals waren programmierbare 
Logikbauteile noch weniger komplex als heute, Multiplizierer in Hardware 
noch selten enthalten.

In den Diagrammen sind jeweils (nur berechnet, nicht gemessen) die 
exakte Kurve mit den auf vier dezimale Nachkommastellen gerundeten 
Koeffizienten als durchgehende Linie gezeigt, und gestrichelt die mit 
Binärbrüchen angenäherten, maximal auf die 6. binäre Nachkommastelle 
gerundet. Wobei ich nicht weiß, wie die Binärzerlegung genau gemacht 
ist.

Die Abweichungen kleiner als 1/10000 dB im Durchlass sind uninteressant, 
aber eine Seitenbandunterdrückung von 55 oder nur 50 dB wären mit dem 
Spektrumanalysator schon deutlich messbar.