ieee.ceil() is not locally static

[Galactic-Explorer]

Description The ieee.ceil() function is not locally static thus it cannot be used in the condition of of case statement.

Expected behaviour To be able to use the function to manipulate constants for use in case statement conditions.

How to reproduce? MWE is provided

entity ent is
end ent ;

architecture behaviour of ent is
    signal test : natural := 2;
begin
    process
    begin
        case (test) is
            when natural(ceil(1.2)) => null;
        end case;
        wait;
    end process;
end behaviour; 

ghdl -a ent .vhd 
ent .vhd:19:13:error: choice is not locally static
            when natural(ceil(1.2)) => null;

Context

• OS: Windows 11 Msys2 environment
• GHDL 4.1.0 (tarball) [Dunoon edition] Compiled with GNAT Version: 13.2.0 llvm 18.1.4 code generator Written by Tristan Gingold.

Copyright (C) 2003 - 2024 Tristan Gingold. GHDL is free software, covered by the GNU General Public License. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[tgingold]

Correct. But this is according to lrm 1076-2008. Only the operations defined in STD_LOGIC_1164, NUMERIC_BIT, NUMERIC_STD, NUMERIC_BIT_UNSIGNED, or NUMERIC_STD_UNSIGNED of library IEEE can be static.

[Paebbels]

@tgingold is there any technical reason why it's limited to a handful of named builtin packages? ... and why math_real, math_complex, ... is not listed?

I wanted to get rid of this list in VHDL-2019, but it was rejected.

Currently, any user defined package has this problem, that user defined operations are excluded from some use cases.

[tgingold]

Yes, some of them would be useful, but:

• for math_real, there is no formal definition of the functions (accuracy, rounding, ...). So not sure it is a good idea.
• even for many functions, the semantic of them is not well defined: what is the static evaluation of an assertion ?

[Xiretza]

what is the static evaluation of an assertion ?

That one is easy at least - it's a compile error just like static assertions in many other languages. A very useful feature to have.

[tgingold]

Even at note severity level ? But it's nowhere in the LRM.

[Paebbels]

Yes, some of them would be useful, but:

• for math_real, there is no formal definition of the functions (accuracy, rounding, ...). So not sure it is a good idea.
• even for many functions, the semantic of them is not well defined

But the definition would be consistent within the same tool and from call to call. The missing consistency is more a problem of portability, right?

[tgingold]

@Paebbels I don't think there is any warranty on the consistency.