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