RE: [sv-bc] FW: Manti 1345, 1711: unique if/case

Comments below. -Tom

>-----Original Message-----
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>Behalf Of Stuart Sutherland
>Sent: Monday, November 19, 2007 8:50 AM
>To: sv-bc@server.eda.org
>Subject: RE: [sv-bc] FW: Manti 1345, 1711: unique if/case
>
>
>>From another user's perspective, I expect **simulation** to evaluate
>unique
>case in the same order in which the case item expressions are listed,
and
>execute the first matching case item branch.  What I want to know from
>unique case is a non-fatal error (I'll settle for a warning, but would
>prefer an error) if the tool determines that additional case item
>expressions were also true.  That tells me there is a coding error that
I
>need to fix.  Side effects from which branch executes first don't
matter,
>because as soon as multiple branches were true at the same time, I know
>there is a bug in my code.
>
[Alsop, Thomas R] My understanding is that while "case items" are unique
"case item expressions" may not be unique. Please correct me if I am
wrong. Multiple case item expressions can be true at the same time and
do not dictate a warning or error message as they may be coded as such.
I agree that we should evaluate them in order and Steven agrees with
this. However, once the first match is made we should not evaluate any
further.

>I expect similar checking and errors from synthesis compilers, but that
>synthesis would either make this a fatal error, or implement priority
>encoded logic and tell me that it did so, even though the case
statement
>had
>indicated it was unique.
>
[Alsop, Thomas R] Synthesis compilers should make the "case item
expression" priority encoded and should not on multiple matches.  "case
items" should become one-hot muxes.  

>I vaguely recall discussion way back in the development of the
Accellera
>3.0
>spec that the concern about side effects was not that these side
affects
>must be executed, but rather what should a tool do if it first proved
only
>one case item expression was true, and then the execution of that
branch
>resulted in another case item expression becoming true.  I see this as
a
>non-issue, that can be either be ignored, or specified that a tool
**may**
>check for such side effects, but is not required to check.
>
[Alsop, Thomas R] The side effect issue you are mentioning Stu is
resolved if we evaluate the "case item expressions" in order.
Evaluation should be done in the order listed as you mentioned.

>Finally, regarding multiple case item expressions in a comma-separated
case
>item (I think I am using the correct terminology), I expect simulation
to
>evaluate them in the order listed, and unique case to tell me if more
than
>one item is true, as if they had been in separate case items.  Even
though
>any true expression in the list will cause the same branch to execute,
>having multiple true expressions is most likely a coding error.
>
[Alsop, Thomas R] As a coder this is a feature to me.  A comma separated
list means to me multiple options or an "OR" of these expressions that I
can choose from, so it's not even a priority encoding for synthesis,
it's just a logical "OR". 

>I other words, lets keep the required checking of "unique" simple, but
>allow
>tools to do more sophisticated checking (e.g. looking for side effects)
if
>they so choose.  As for execution order, the LRM should say that the
>execution of a unique case statement is the same as a regular case
>statement, but with additional checking of the case item expressions
>**before** a branch is executed.
>
[Alsop, Thomas R] While I agree on keeping things simple, one I think
this simplifies and optimizes what implementations are doing and two, it
removes discrepancies from different implementations.  We are having
lots of issues taking the exact same SV or verilog code and moving it to
another implementation.  What's a race condition in one, is not in the
other.  Or what is a branch taken for one case statement in one
implementation is not in another.  

>Just my two cents worth on this topic...
>
>Stu
>~~~~~~~~~~~~~~~~~~~~~~~~~
>Stuart Sutherland
>Sutherland HDL, Inc.
>stuart@sutherland-hdl.com
>503-692-0898
>
>
>> -----Original Message-----
>> From: owner-sv-bc@server.eda.org
>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
>> Sent: Monday, November 19, 2007 7:44 AM
>> To: Gordon Vreugdenhil
>> Cc: sv-bc@server.eda.org
>> Subject: RE: [sv-bc] FW: Manti 1345, 1711: unique if/case
>>
>> Gord,
>>
>> Thanks.
>>
>> Again I will ask why the LRM has to make an effort to support such a
>> unique case (not a pun). The uniqueness violation aside, no
>> one has yet
>> provided a justification for side-effects in case_item
>> expressions in a
>> unique case. I also suggest that statically determinable uniqueness
>> violations indicate a problem and therefore optimizations
>> don't interest
>> me in such situations anyway. Plus those should be rare situations
and
>> not worth investing in their optimization. And if
>> predictability is some
>> important, then would it not be more important than optimization?
>>
>> Regards,
>> Shalom
>>
>> > Consider the following:
>> >
>> >     unique case (expr)
>> >         1   : ... /* action 1 */
>> >         i++ : ...
>> >         1   : ... /* action 2 */
>> >
>> > I may want to optimize the statically determinable non-unique
>> > cases and not have to walk through things.  So effectively I
>> > may want something that looks like:
>> >     case (expr)
>> >         1   :  /* warn */ /* action 1 */
>> >         i++ : ...
>> >
>> > I don't think that would be valid in the approaches that
>> > you've been discussing and I would object to making such
>> > optimizations illegal.
>> >
>> > I do agree that requiring a top-down ordering could be
>> > required but only until encountering a case that warns.  So
>> > once you issue a warning, no further evaluation is required
>> > and whether evaluation of case items which are between the
>> > first match and the match which conceptually causes the
>> > warning is implementation defined.
>> >
>> > I think that gives us a reasonable approach -- if you have a
>> > well-formed unique case, then you get top-down predictability.
>> > Only when you have an ill-formed case, do you lose some
>> > predictability.
>> > While I agree with Steven that I don't want to penalize *all*
>> > side-effects, I don't mind penalizing an ill-formed unique
>> > case with side-effects.
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>>
>
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.