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

Hi Andy,
One of the goals of my resolution function was to make sure there is only
one valid driver at any time. If I were to have the resolution function sum
up all drivers, and if the design wrongly has two or more drivers driving
different values at the same time, then the resolution function would,
incorrectly, resolve to the summed value, which is not the intent of the
resolution function.

If I were to use 0 as the undriven value, but also have 0 as a valid
integer value (e.g. I may want my design to settle to a zero value during
initialisation or IDLE state), then how could I tell which driver is the
one driving? Since we must have only 1 driver at any time, i.e. it would be
incorrect if the design were to have all drivers driving 0 at the same
time. Let's assume that the design specification dictates that only one
driver would drive 0 (or any other valid integer value) at any time, while
all other drivers must release the bus to an undriven state.

Jim,
Perhaps your suggestions and proposals on "Implicit Numeric Conversions"
could work for me. But sorry I haven't yet gone through your proposals in
detail so I wouldn't know for sure. I hope I could spend some time this
week to study them.

Cheers, Dan


On 17 October 2014 09:55, Jones, Andy D <andy.d.jones@lmco.com> wrote:

>  You don’t need to reserve an unused number, just make the bus resolve to
> that number if everyone drives it.
>
>
>
> For an integer resolution function, you can use 0 as the undriven value,
> and the resolution function just sums the drivers. If more than one driver
> is on (non-zero), have the resolution function assert a warning, and report
> the non-zero values if you like. The only thing that won’t catch is if all
> but one driver are intending to drive 0, and one mistakenly does not.
>
>
>
> Andy
>
>
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Daniel Kho
> *Sent:* Monday, October 13, 2014 9:29 PM
> *To:* vhdl-200x@eda.org
> *Subject:* EXTERNAL: 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* <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, and is
believed to be clean.