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

I see two ways of achieving this:


1)      Define (in the language) an "undriven" value for a new resolved integer type, along with an 'X' type of value.  This would allow only one non-undriven driver to resolve to a value, and resolve to X if more than one driver was not driving "undriven".  I guess an alternative to new values would be to attaché something like a 'drive_strength attribute to every basic type (off, weak, strong?) and use that to resolve. I'm not sure I like that idea, but it would allow resolved versions of any type. Anyway, either of those solutions would require a language change.

2)      Define a resolved integer type with "largest-wins" behaviour.  Jim Lewis (I think) has already done this to help with validation work.  No language changes required.  We could potentially standardise this type in a package.  If you define universal_integer'low as an undriven value you get nearly the same behaviour as above.­

I would propose the latter, as it gives (almost?) all the benefits without requiring a lengthy language change.  You can do it today, and if and when an arbitrary sized universal integer comes along, it can just "scale up".

Cheers,
Martin

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jakko Verhallen
Sent: 14 October 2014 08:40
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Update to proposal for arbitrary integers

It is not that easy, since currently an integer (or real) has only 'driving' values, unlike std_ulogic.
Std_ulogic implies a driving value and strength, which can easily be resolved.

I do see advantage indeed here, as currently only bits and std_logics can be corrupted using power intent based simulations.

Jakko

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Scott Hoy
Sent: Tuesday, October 14, 2014 9:31 AM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: RE: [vhdl-200x] Update to proposal for arbitrary integers

Why not come up with a way to define a resolved integer type to handle this type of thing?  A resolved real type would be handy as well.  This is what the resolved type of std_logic does to std_ulogic - correct?  Why not extent resolve types or resolution functions to cover all root types?

Regards,

Scott D. Hoy
E-mail: sdhoy@verizon.net<mailto:sdhoy@verizon.net>


________________________________
From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Monday, October 13, 2014 10:29 PM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: 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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

Please consider the environment before printing this e-mail



--
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.