RE: [sv-bc] Re: issue 324 for asymmetric casex

New proposal uploaded to address these comments.

http://www.eda.org/svdb/bug_view_page.php?bug_id=0000324

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven
> Sharp
> Sent: Tuesday, April 05, 2005 6:40 PM
> To: sv-bc@eda.org; Brad.Pierce@synopsys.com
> Subject: Re: [sv-bc] Re: issue 324 for asymmetric casex
> 
> 
> >I would like to withdraw this proposal entirely, and see if we can't
> >put together something that would do a better job of avoiding
mismatches.
> 
> I hope I didn't discourage you with my comments.  This is just a
bigger
> thing to specify than it might appear at first glance.  However, it
> sounds like you are concerned that it may not do the job it is
intended
> to do.
> 
> >The inside operator doesn't seem to be the right one for the job.
> 
> There is an elegance to using something based on inside, since it
> implies both the asymmetric compare and the ranges.  On the other
> hand, we may want to extend the other kinds of cases to allow ranges
> too.  At that point, this won't seem as elegant.  The thing that
> will distinguish this kind of case will just be the asymmetric
> wildcarding.
> 
> >I need to think it through more, but perhaps an asymetric
case-wildcard
> >as proposed earlier (with no ranges) except that
> >
> >    1) The case items must be literals
> 
> This might be overly restrictive.  Admittedly, non-constant case
> items are less important once you have made the case asymmetric.
> For synthesis you would presumably require the case item expressions
> to be constants (not literals), but simulation doesn't require it.
> We can optimize a lot better with constants, but already have to
> handle non-constants for case, casex and casez, so this isn't any
> worse.
> 
> >    2) An x or z in a case item would match only a 0 or 1 in the
> >       case expression.
> >
> >That is, a don't-care in the case item would mean I don't care if the
> >case expression has a 0 or 1 in that bit, but it must be an actual
bit,
> >not an x or z.
> 
> I remember seeing a request for this kind of overly pessimistic
> wild-card treatment in an enhancement request.  It doesn't make sense
> to me.  It is not consistent with the meaning of 4-state logic.  The
> intent does not seem to be matching the actual behavior of logic.  It
> seems to be "I don't want X's, or don't understand them, so make
> sure my simulation doesn't work even if the real logic would."
> 
> This does not match the usual design philosophy for 4-state logic in
> Verilog.  An X means a value is either 0 or 1, but we cannot deduce
> which one it is under these circumstances.  If a case item has a
don't-
> care for a bit where the case expression has an X, it should match.
If
> the X were 0 it would match, and if the X were 1 it would match.
Since
> it will match regardless of whether the X is 0 or 1, we should treat
it
> as matching.  Verilog generally tries to model this accurately, unless
> it is too expensive to do so (as with arithmetic operations).  In this
> case, it is the same cost to do it accurately as to do it
pessimistically.
> 
> To put it another way, if there is a don't-care on a bit in a case
> item expression, it means that the bit is not an input to the decode
> logic that selects that case item.  Its value has no effect on the
> result of that decode.  Why would it matter if the bit is X or Z?
> 
> Not letting a don't-care match an X will *cause* mismatches between
> pre/post-synthesis simulation, not avoid them.
> 
> [Somebody might suggest unusual situations where an X or Z would not
> be treated consistently as a 0 or 1 by the logic, but if that were a
> concern we need to redesign the rest of the Verilog 4-state logic
> operations too.]
> 
> Steven Sharp
> sharp@cadence.com