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

Le 2014-10-27 23:44, Ray Andraka, Andraka Consulting Group, Inc a 
écrit :
> NaN has an explicit definition as well as a specific valid bit
> pattern in floating point.  There is no equivalent state in fixed
> point arithmetic.  All fixed point integer bit patterns map to an
> integer value.  As such, I have a lot of heartburn calling this
> NaN.  I think that what you really want is the addition of metavalues
> to the integer type.  My problem with that is twofold: a) it isn't
> just the to_integer function that is affected, it is all integer
> functions and operations.  In order for the metavalue to be useful,
> it needs to be propagated.  Otherwise you end up with exactly the
> same situation where you have a function that spits out a warning
> message but outputs an otherwise valid value.  My second reservation
> is adding a metavalue to the integer type involves a very significant
> processing overhead increase for every integer operation and function
> in order to detect and propagate the metavalue when appropriate. 
> Warnings do provide a reasonable way to alert the designer to an
> unknown value without forcing a burdensome structure (most simulators
> will include the simulation time with the warning, so it is easy to
> track it down...but it does require you to review the warnings). 

I will mention one function I use a lot :

   function safe_to_integer(u:std_logic_vector) return integer is
   begin
    if Is_X(u) then
       return 0;
     else
       return to_integer(unsigned(u));
     end if;
   end;

I am most usually bothered when the simulation starts
and std_logic  metavalues are propagating here and there.
My memories do not handle "U" or "X" as indices.
But there are already functions that detect these
conditions and you can test them. Instead of "return 0", report an 
error,
call a function, or whatever you need.

For me, adding a metavalue to the integer type is not a good solution,
there is not even a problem. I know it's verbose but it works.
These meta-data should remain in the types that create/handle them.
Furthermore NaN is not the same as "X" or "U" or "Z"...
so they could create semantic problems.

I haven't seen anybody mention this point so I thought I would be 
useful,
YG

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