VHDL 1993: Wie maximalwert eines Integer ranges aus Signal bestimmen

[M. N. (bmbl2)]

Hallo,

ich habe eine Frage an die VHDL Experten, die sich mit Workarounds 
auskennen.

Ich möchte aus einem integer Signal herasubekommen, welchen maximalwert 
dieses haben kann:

In VHDL-2008 ginge das so:

...
architecture rtl of my_entity is
  signal sig    : integer range 0 to 31;
  signal is_max : std_logic; 
begin

is_max <= '1' when sig = sig'subtype'high else '0';

end architecture rtl;

Leider ist der VHDL Support von Synopsys so schlecht, dass der Design 
Compiler, selbst mit aktiviertem VHDL 2008 mode, das Attribut 'subtype 
nicht kennt.

Gibt es eine Möglichkeit anders an das Maximum des Signals zu kommen? 
Alternativ müsste ich anderen code sonst umbauen lassen, sodass das 
maximum als Konstante definiert wird, oder der integer Type separat als 
subtype definiert wird, sodass ich mit 'high an das Maximum komme.

[Gustl B. (gustl_b)]

Du könntest dir einen subtype definieren.

subtype int5_t is integer range 0 to 31;

Und dann

signal sig : int5_t;

is_max <= '1' when sig = int5_t'high else '0';

Dann ist is_max 1 wenn sig den Wert 31 hat.

[Rick D. (rickdangerus)]

Ich würde statt integer ja eher auf signed/unsigned setzen...

M. N. schrieb:
> sodass das
> maximum als Konstante definiert wird, oder der integer Type separat als
> subtype definiert wird, sodass ich mit 'high an das Maximum komme.
Genau so.

Das ergibt m.E. auch besser lesbaren Code:

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

entity max_integer is
end entity max_integer;

architecture academic_problem of max_integer is

    subtype sig_t is integer range 0 to 31;
    signal sig          : sig_t;
    constant sig_max    : sig_t := sig_t'right;
    signal is_max       : std_logic;

begin

    is_max <= '1' when sig = sig_max else '0';

    process
    begin
        wait for 50 ns;

        for i  in  0 to 31  loop
            sig <= i;
            wait for 10 ns;
        end loop;

        wait; -- forever
    end process;

end architecture academic_problem;

[M. N. (bmbl2)]

Rick D. schrieb:
> M. N. schrieb:
>> sodass das
>> maximum als Konstante definiert wird, oder der integer Type separat als
>> subtype definiert wird, sodass ich mit 'high an das Maximum komme.
> Genau so.
>
> Das ergibt m.E. auch besser lesbaren Code:

Okay. Dann geht das nur so. Das kann ich leider auch nicht machen, weil 
diese subtype definitionen von integer ranes in einem anderen Tool der 
Kette nicht richtig funktionieren.

    subtype sig_t is integer range 0 to 31;
    signal sig          : sig_t;

Warum weiß ich auch nicht. Der VHDL-Parser ist ähnlich schlimm.

Danke für die Überlegungen. Für das Jahr 2027 wünsche ich mir im 
Geheimen mal funktionierenden VHDL Support. Aber ich denke, wir werden 
die nächsten Jahre auf Verilog umschwenken, weil einfach nichts richtig 
funktioniert.

[Martin S. (strubi)]

Wenn dein Maximalwert 'all ones' ist, (2**n-1), brauchst du ja `integer` 
grundsaetzlich nicht zwingend in der Form und kannst es per unsigned und 
einer Hilfsfunktion a la `next_power_of_two(MAX_VALUE)` modellieren. 
Wenn die Synthese die allerdings auch nicht verdaut...

Fuer synthesefaehigen/portablen Code wuerde ich somit nur die 
numeric_std-Typen im Transfer empfehlen und die Bound-Checks in 
allenfalls verketteter Arithmetik nicht der VHDL-Engine ueberlassen, 
zumal die `integer` je nach Architektur schon mal bei 32 bit begrenzt 
sind.

Verilog ist zwar arithmetisch 'kaputt von Haus aus', aber das  implizite 
Verhalten ist so eindeutig, dass es in meiner Toolpraxis bisher immer in 
der Verifikation standgehalten hat.

[M. N. (bmbl2)]

Martin S. schrieb:
> Verilog ist zwar arithmetisch 'kaputt von Haus aus', aber das  implizite
> Verhalten ist so eindeutig, dass es in meiner Toolpraxis bisher immer in
> der Verifikation standgehalten hat.

Ja. Das ist leider so. IMHO ist VHDL die viel schönere Sprache. Aber bei 
uns in der Halbleiterei ist Verilog eigentlich Pflicht. Wir sind da so 
ein bisschen das gallische Dorf.

Martin S. schrieb:
> `integer` je nach Architektur schon mal bei 32 bit begrenzt
> sind.

Das ist das kleinste Problem.
Der Typ ist nur ein Integer, weil der späte für einen array Zugriff 
benutzt wird. Und arrays haben "integer ranges". Man hätte da auch einen 
unsigned oder so nehmen können und to_integer. Aber da entstehen wieder 
andere Probleme. Dann hätte der unsigned so breit gemacht werden müssen, 
um den maximalwert zu halten, der von mir nicht beeinflussbar leider in 
diesem integer steckt:

Da hätte man dann irgendwo

USE ieee.math_real.log2;
USE ieee.math_real.ceil;
...
CONSTANT NBIT  : INTEGER := INTEGER(CEIL(LOG2(REAL(MAXCOUNT-1)));

machen müssen. Da muss man Synopsys jetzt in Schutz nehmen. Das ginge 
tatsächlich. Aber dann fi*** micht die Cadence Palladium Synthese. Die 
kann das wieder nicht mit der generischen Fehlermeldung, dass 
"ieee.math_real" generell nicht synthetisierbar sei, obwohl nur 
Konstanten drin vorkommen.

[Martin S. (strubi)]

Ich dachte eher an sowas, was m. W. bei den meisten Grottentools noch 
durchgeht:

function bits_required(max_value : natural) return natural is
    variable value  : natural := max_value;
    variable bits   : natural := 0;
begin
    while value > 0 loop
        bits  := bits + 1;
        value := value / 2;
    end loop;

    if bits = 0 then
        bits := 1;
    end if;

    return bits;
end function;

M. N. schrieb:
> Der Typ ist nur ein Integer, weil der späte für einen array Zugriff
> benutzt wird. Und arrays haben "integer ranges". Man hätte da auch einen
> unsigned oder so nehmen können und to_integer.

Das ist ja eigentlich de-facto Standard fuer 
RAM/ROM-Synthesebeschreibung. Doof ist nur, wenn Maxwert < `all ones`, 
oder man kein RAM sondern einen Register-Selektor (Muxer) braucht, der 
fuer verbotene Werte (> Max) irgend eine Spezialbehandlung machen muss. 
Diesbezueglich habe ich in der Vgh keinen anderen Weg gesehen, als 
explizites Ausrollen mit case/when/others.

[M. N. (bmbl2)]

Martin S. schrieb:
> Ich dachte eher an sowas, was m. W. bei den meisten Grottentools noch
> durchgeht:

Oh. Das ist noch ne Idee. Sehr gut. Vielen Dank! Da habe ich den Wald 
vor lauter Bäumen nicht gesehen. Funktionen gehen meistens... Nicht 
immer aber meistens :)