RE: 4 State Logic Proposals

Hi Per,

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

I agree.

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

My thoughts were: (a) if the modeler does not intend to send X or Z
values from SW->HW, and (b) we agree that it is bad practice to send
X or Z from SW->HW, then why not force the modeler to only use 2-state
types in that direction?  This was an attempt at finding a "happy
medium".

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

Sorry for the confusion.  After re-reading Shabtay's email in it's
entirety, yes, this was a modification.  Since we've gotten responses
that users want to see 4-state types in both directions, our proposal
remains what is written in Shabtay's email.

Regards,
Jason

> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
> Bojsen
> Sent: Thursday, October 13, 2005 6:08 PM
> To: itc@eda.org
> Subject: 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
>