Re: resolved integers (was RE: [vhdl-200x] Update to proposal for arbitrary integers)

Hi all,

On 14 October 2014 21:29, Jim Lewis <jim@synthworks.com> wrote:

>  Addressing how to choose a final value, one can
> * Pick maximum, pick minimum, pick the sum of values, pick first or last
> value (not symmetric)
>
> Addressing what should be done if there is more than one active value, one
> first has to arbitrarily pick a non-driving value.  If you think back to
> wired-or buses, then picking 0 as a non-driving value becomes obvious.  One
> policy would be to require all signals to be given an initial (default)
> value of 0, 0.0, or 0  ns, as is appropriate for the type and then if there
> is more than one 0, issue an error and/or failure message.
>
> I have been using resolution functions for integer, real, and time for
> quite some time now (since 2006).    I have been using ones that signal an
> error if more than one value is non-zero and pick the last value.  I don't
> think last value is a good policy and intend to replace it with maximum.  I
> have also played around with using a summing resolution function (this is
> the original example that I saw that helped me see how resolution functions
> could work for type integer), however if you have a set of ranged values,
> then summing could produce a value out of range (hence, if you had a
> failure, it would make it harder to continue and get debugging information
> out of your session).
>
> Yes, this hits the point exactly. Often, determining what should be done
when there are multiple values to be resolved varies across different
applications. While zero would appear logical for use as an initial (or
undriven) value for some applications, other applications may deem zero as
a valid integer value and probably unsuitable for such use. I like the
maximum and minimum resolution functions, and they can be very useful in
many situations. But please allow me to describe a situation where an
undriven / invalid value for an integer would be favorable.

Say for an application, we need to make sure there is only one driver at
any one time (in fact, I find this situation rather common). In this
scenario, any two or more multiple drivers driving the bus (doesn't matter
whether or not the driving values are the same or different), should result
in an assertion error. Let's assume we would like to write our testbench in
this manner. Here, the resolution functions maximum, minimum, or any others
that allow resolving 2 or more drivers would not be suitable for this
application. We would like to have a check within our resolution function
to make sure that there is only one driver driving a valid integer value,
while all the other drivers should release the bus. If I were using
std_ulogic_vector or numeric_std's signed / unsigned, I could easily use
the "not is_x()" check - to be safer, I implemented an "is_LH01()" check in
my resolution function (assuming std_ulogics):

-- is_LH01 check
function is_LH01(s:std_ulogic) return boolean;

-- resolution function
function resolved(s:std_ulogic_vector) return std_logic is
    variable err: boolean;
    variable result: std_ulogic := 'Z';
begin
    for i in s'range loop
        if is_LH01(s(i)) then           -- if a driver is found,
            if is_LH01(result) then    -- check if there was no previous
driver.
                result := 'X';
                report "Multiple drivers detected." severity failure;
                err := true;
            else result := s(i);
            end if;
        end if;
    end loop;
    return result;
end function resolved;

The problem with this is that this approach works only for std_ulogics and
numeric_stds (unsigned / signed). I was figuring out a way to do the same
thing with integers and booleans, but couldn't come up with a clean
solution. :(


> On 10/14/2014 5:09 AM, Martin.J Thompson wrote:
>

I agree – if you want an ‘undriven value’, then it has to be
separate.  The simulator could track it in whatever softwarey way suits,
say via an internal variable with a bit for each resolved integer object
which needs to be tracked.  In synthesis, a resolved integer could an extra
bit to signifiy its “drivenness†.



Or either level of tool could allocate a value outside of the valid range
for the integer in question (to use internally as a flag), which could be
accessed through the language via some suitable abstraction.



At this stage, I would propose that Daniel could write up a requirement on
the Twiki for what he would like to happen (without implementation details
at this stage?) and we can add it to the future discussions...


Martin, you've explained my intent pretty clearly. Allocating a value (or
just an internal flag) for use by the language was what I had in mind as
well (i.e. the NaN example). I'm not sure if NaN is something strictly
reserved for the "float" type, or whether it is possible to reuse the value
(or flag) for integers (or other types) as well?

I could do a short write-up on the Twiki - probably just scrubbing whatever
I mentioned in this email. Hopefully, this will give an idea of the intent
and requirements on this proposal, and would stir up more interesting
discussions and explore possible implementation solutions.

Cheers,
Daniel

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