RE: [sv-bc] Mantis 1345: 10.4: "illegal" unique if/case issues

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Feb 23 2006 - 23:12:56 PST
I haven't yet studied Greg's mail in detail, but 2 short comments:

1. "How often does someone use a variable in a case item expression"?

Answer: Frequently. A common coding style is

case(1'b1)
a: ...
b: ...
c: ...
...
endcase

Frequently used with parallel_case directive.


2. Regarding side-effects, I was thinking along the same lines as
Steven, I think. Define unique assuming no side-effects exist. State
explicitly something like, "If side-effects exist, results may be
indeterminate."

Shalom


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Steven Sharp
> Sent: Friday, February 24, 2006 3:49 AM
> To: sharp@cadence.com; Greg.Jaxon@synopsys.com
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Mantis 1345: 10.4: "illegal" unique
> if/case issues
> 
> 
> >From: Greg Jaxon <Greg.Jaxon@synopsys.com>
> 
> >Brad has often
> >suggested that SV prohibit side-effects here altogether, which
> would
> >probably not be practical for testbench uses;
> 
> Can you give an example?  I think we can allow side-effects in
> the
> case expression, just not in the case item expressions.  Since
> >99%
> of the time these are constants anyway, I don't see how this is
> impractical.  How often does someone use a variable in a case
> item
> expression, much less something that could have a side effect,
> like
> an increment or assignment operator or impure function call?
> 
> They certainly don't belong in anything synthesizable.  And
> since
> my understanding was that unique case was intended for
> synthesis,
> I don't think we should be worrying too much about them in
> testbenches anyway.  Let's keep in mind what they are intended
> for, instead of just focusing on the construct itself.
Received on Thu Feb 23 23:13:13 2006

This archive was generated by hypermail 2.1.8 : Thu Feb 23 2006 - 23:14:31 PST