RE: 4 State Logic Proposals

Hi Jason,

Per> I would certainly argue that [sending X or Z from SW to HW] is a
Per> bad practice. This is why I'd like to make this an error.

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

Right.  But even if we fully support 4-state as an option, transactors
that actually rely on transporting X or Z values would only work on
implementations that do support the full 4-state behavior.

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

I think you were missing the point of what Russ was asking for.  Russ
was not asking for support for transporting X and Z in any direction.
He was asking for the 4-state value *types* to be allowed by SCE-MI
both on the hardware side and software side.  This is to make it easier
for IP vendors and users who are used to using 4 state types on the
hardware side to port their models to SCE-MI 2.0.  They would not
have to rewrite their code to use 2 state types.

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

I am still confused.  Did you actually present another modification to
Shabtay's 4-state support proposal?  Shabtay specifically mentioned
the point about the undefined behavior being part of the standard.  You
seem to be supporting to make usage of 4-state types or at least X and
Z in the SW to HW direction errors.  Is this true?  The phrase `allowed'
makes me think so.  So what is Cadence's proposal now?

Per