RE: 4 State Logic Proposals

Please see my comments below:

>> This proposal assumes the following two things:
>> 1) The purpose of having a hardware platform that supports 4-States
>> is to monitor X's or Z's in the DUT coming from the hardware side.
> 
> That seems reasonable enough.
> 
>> 2) A transactor developer or modeler would not need the ability to
>> send X's or Z's from a BFM proxy to a BFM.
> 
> I would certainly argue that doing this is a bad practice.
> This is why I'd like to make this an error.

If assumption (2) is false, then this proposal will not work.

>> The revised proposal from Cadence is to allow 4-state TYPES in one
>> direction, from HW->SW, and 2-state TYPES from SW->HW.
> 
> Ok, but this does not give Russ what he wants as I assume you are
> aware. Russ wants the 4-state types to be supported in both
> directions.  This is to support IP vendors and other users
> that uses these types without forcing them to rewrite their C
> sides for SCE-MI.  The usage of the 4-state types does not
> imply that X and Z values are passed.
> 
> For your proposal to be compatible with what Russ is asking
> for you need to modify it to state that 4-state *types* are
> supported in both directions, but only 0 and 1 can be passed
> from the SW side to the HW side.  Do you agree?

Russ, can you confirm that you want the ability to send X's or Z's from
SW->HW?  If this is the case, then my proposal will not work.

> Shabtay said that usage of 4-state values X and Z and 4-state
> types in the SW->HW direction is left as undefined behavior
> in SCE-MI.  Are you now contradicting him?

In this proposal, there would be no need for undefined behavior if only
2-state types are allowed in the SW->HW direction.

Regards,
Jason