RE: 4 State Logic Proposals

From: Jason Rothfuss <rothfuss_at_.....>
Date: Thu Oct 13 2005 - 15:33:09 PDT
Hi John, see below:

John Stickley wrote:

>> Allowing only 2-state types to be passed from HW->SW removes the need
> 
> johnS:
> I think this was a typo - you mean SW->HW here right ?

Yes, this is a typo.  Thanks for catching it.


>> for coercing 4-state values into 2-state values, and promotes a
>> better modeling style. 
>> 
>> This approach would be fairly simple to enforce:
>> 
>>   export "DPI-C" function callme;
>>   function void callme;
>>           input  logic [31:0]  badarg;   // This would be an error 
>>           input  bit   [31:0]  goodarg;  // This would OK
>>           output logic [31:0]  goodarg1; // This would OK
>>           output bit   [31:0]  goodarg2: // This would OK
>>           begin 
>>           end
>>   endfunction
> 
> johnS:
> What if we said that 'badarg' is not an error but just a forced
> coercion to 2-state ? 

I'm ok with that.  
 
> I guess the only hole I see in this revised version of your
> proposal is that if X or Z values are passed from HW by a
> simulator that supports 4-state, the C-models may behave
> differently than the same models running on a simulator that
> only supports 2-state. But this may be OK.

If HW passes a value that is X/Z for a platform that supports 4-state,
but passes 0/1 for a platform that only supports 2-state, neither is
wrong.  Both pass the current value that is in HW.  It is up to the user
to develop a model that does not require seeing X or Z values coming
from hardware.  In my opinion, it is good practice to do this anyway.

> In former case a C model might flag errors, or warnings for
> undefined's it sees and in the later case, the same C model
> would not see X or Z values and therefore happily process the 0's and
> 1's that it does see. 
> 
> I guess in that sense the model would be portable, just
> behavior would be different right ?

Yes, the model should be portable even though behavior may be different.
It would be the users' responsibility to ensure portability by not
writing a model that relies on seeing unknowns.  

Regards,
Jason
Received on Thu Oct 13 15:34:34 2005

This archive was generated by hypermail 2.1.8 : Thu Oct 13 2005 - 15:35:27 PDT