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

I have read part way through all the email generated on this line of thought and have some contributions to add.

Type bit, integer, and real have no resolution and correctly so as they do not support a value structure that indicates driving strength.
For the library standard types they are simply driven, always!

For driving strength we have a package, std_logic_1164

For resolved integers and reals the same line of thought would extend to having a package for   res_integer   and res_real  and in those
Package the resolved integer and resolved real types would be defined.

Trying to extend resolution to the existing real and integer types creates break in the logic behind the language design.  For simple designs you need
Integers, reals, bits, bit_vectors, …   There is also a need for resolved types and the language provides the structure for that but it need to be a new and unique type.

Best and good designs,
Joanne

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of David Bishop
Sent: Tuesday, October 14, 2014 7:46 AM
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Update to proposal for arbitrary integers

On 10/13/2014 10:29 PM, Daniel Kho wrote:
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.
A "NaN" is a very specific value for a floating point number.   An exponent of all "1" (which means infinity) and a fraction which starts with a "1".     Since all of the bits in an integer are valid, I don't know how you would do an invalid number.   You can't just pick one because somebody will need to use 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.
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2014.0.4765 / Virus Database: 4040/8384 - Release Date: 10/13/14


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