RE: 4 State Logic Proposals

Hi Jason,

> 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.

> 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?

> Allowing only 2-state types to be passed from HW->SW removes the need
> for coercing 4-state values into 2-state values, and promotes a better
> modeling style.

That's true, but Russ will not be satisfied.

> With this proposal, there is no "undefined" case, since 'logic' data
> types are only supported as outputs in exported DPI functions, and as
> inputs in imported DPI functions.

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?

Thanks,
Per