Re: [vhdl-200x] Update to proposal for arbitrary integers

Hi Martin,
Thanks for this. One thing that has been bothering me quite often these
days is that integers, booleans, bits (and possibly other types from the
std.standard package) do not have the concept of resolution.

While I support the idea of having a completely-unconstrained
universal_integer type, I still would like to have the ability to assign an
"invalid" or "undriven" value to an integer. Like this:

signal i: integer;
...
begin
    i <= NaN;

where NaN is an invalid value for an integer. I find myself needing the
ability to assign integers to an invalid / undriven state, during
initialisation/reset for example, or when I would want to have a driver
explicitly "release" the bus, while have another driver drive it.

In the past, I tried writing resolution functions for integers to do
exactly this, but found my solution inadequate as I need to reserve a valid
integer, e.g. x"ffff_ffff" to act as my invalid/undriven integer. I find
that when writing such resolution functions, I do need checks against an
undriven state. For std_logic, we already have the function "is_x" (and I
also have my own "is_01") which we could use when resolving std_ulogic type
signals. But for integer and boolean types, I can't think of a way to do
the same thing as an "is_x" function would for std_logic. My dirty hack was
just to reserve a very large integer to act as my invalid value.

My opinion is that it would be great if we can do similar things with
integers, booleans, and bits. It is often easier to design using these
datatypes than with std_logic(_vector).

What do you think?

Best regards,
Daniel

On 10 October 2014 19:07, Martin.J Thompson <Martin.J.Thompson@trw.com>
wrote:

>  Hi all,
>
>
> After the discussions in the last telecon, I have updated the Arbitrary
> Integers page:
>
>
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers
>
>
>
> In summary, the proposal is to
>
>
>
> ·         Expose universal_integer as a completely unconstrained integer
> type, (and possibly make INTEGER a constrained subtype of this.  Each tool
> will constrain the INTEGER to the range it currently provides for backwards
> compatibility.)
>
> ·         Create universal_integer’high and ‘low
>
> ·         Allow logical and shift operations on universal_integers
>
> ·         Question: should conversions between UNIVERSAL_INTEGER and
> INTEGER be implicit or explicit?
>
>
>
> Any comments you have will be gratefully received as always :)
>
>
>
> Thanks,
>
> Martin
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.