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

From: Jim Lewis <jim@synthworks.com>
Date: Tue Oct 14 2014 - 12:19:08 PDT
Hi Daniel,
> 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.
Correct, if one of your devices was actively driving 0, then the resolution function would not detect it.  For me I am not trying to emulate tristates with integers, but instead I am using a single 
record as a point to point communication channel (where some fields are in, some out, and some inout).  If a BFM needs more than one source of stimulus, it needs a separate communication channel for 
each.  The reason is simple, it is the BFM that needs to decide which channel to pull from and not a resolution function.  For example, when an interrupt is pending to my CPU model, it pulls stimulus 
from the interrupt handler channel, otherwise it pulls stimulus from the normal CPU channel.

So basically, I have to validate the correct communication between the stimulus source and the BFM with non-zero values, and then during the test, use any value.

> 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):
I understand the mechanics of what you want and the answer is simple, use a record:

type DrivingStateType is (NOT_DRIVING, DRIVING) ; -- you could extend this for other applications
type extended_integer is record
   state : DrivingStateType ;
   arg    : integer ;
end record extended_integer ;

Now write a resolution function for your extended_integer:
type extended_integer_array is array (natural range <> ) of extended_integer ;

function resolved (arg : extended_integer_array) return extended_integer is
   variable result : extended_integer := (NOT_DRIVING, 0) ;
begin
   for i in arg'range loop
     if arg(i).state = DRIVING then
       if result.state = DRIVING then
         report "multiple drivers" severity failure ;
       end if ;
       result.state := DRIVING ;
       result.arg := maximum(arg(i).arg, result.arg) ;
     end if ;
   end loop ;
end function resolved ;

If we changed the language and added state information to every integer, the result would be both a storage burden and application slow down of all integers.

Your other complaint might be, it is harder to assign to an extended_integer than an integer.  I just posted a proposal for implicit conversion functions and it may help with this (at least in the 
future).

Cheers,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis                                  Jim@SynthWorks.com
VHDL Training Expert                       http://www.SynthWorks.com
IEEE VHDL Working Group Chair
OSVVM, Chief Architect and Cofounder
1-503-590-4787
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Oct 14 12:19:40 2014

This archive was generated by hypermail 2.1.8 : Tue Oct 14 2014 - 12:19:53 PDT