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

First, evaluating what the value of i++ **will be** does not have to mean
actually changing i, does it?  Couldn't a tool just do the evaluation in a
temporary space for evaluating uniqueness, and throw the result away if that
branch is not the one to be executed?

Second, I would think that i++ would not need to be evaluated at all for
determining uniqueness, since it is a post-increment operation.  It would be
++i that needs to be temporarily assessed.

Third, this side effect propagates further if another case item also used
and/or modifies i, but I think it should be left optional as to how much
effort tools put into chasing down the ripple effects of such side effects.
The required checking for uniqueness, in my opinion, should be the current
value of each case item expression before the execution of any case item
expressions or case branches.

Fourth, there is precedence for simulation (or other tools) not being
required to cause side effects, even if real hardware would.  One example is
that the evaluation of the logical && and || operators are permitted to
short circuit, thus not necessarily executing expressions that cause side
effects.  It is reasonable and intuitive for case statements, whether unique
or not, to have a similar behavior.

Is a list of four thoughts more than two cents worth? :)

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 Gordon Vreugdenhil
> Sent: Monday, November 19, 2007 8:58 AM
> To: Bresticker, Shalom
> Cc: sv-bc@server.eda.org
> Subject: Re: [sv-bc] FW: Manti 1345, 1711: unique if/case
> 
> 
> 
> Bresticker, Shalom wrote:
> > Sorry, now I am confused.
> > 
> > Essentially what was proposed by Steven and Tom (and I do 
> not object) is
> > to specify an order allowing only short-circuiting. Then there is no
> > special consideration of side-effects, and whatever happens happens,
> > according to the rules. 
> 
> 
> The impact of the current suggestions is that for the example that I
> originally suggested the optimization I want is illegal.
> 
>       unique case (expr)
>           1   : ... /* action 1 */
>           i++ : ...
>           1   : ... /* action 2 */
> 
> Given the current suggestion, one MUST evaluate "i++" if
> you are reporting a unique violation.  I do not want to
> require that evaluation.
> 
> Gord.
> 
> 
>  > Is it a problem to say that a tool does not have
> > to check whether there are side-effects, but caveat emptor 
> if you use
> > them? (Or in other words, you deserve whatever you get.) I don't see
> > what your objection is anymore.
> > 
> > Regards,
> > Shalom
> > 
> >> -----Original Message-----
> >> From: owner-sv-bc@server.eda.org 
> >> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> >> Sent: Monday, November 19, 2007 6:36 PM
> >> To: Bresticker, Shalom
> >> Cc: sv-bc@server.eda.org
> >> Subject: Re: [sv-bc] FW: Manti 1345, 1711: unique if/case
> >>
> >>
> >>
> >> Bresticker, Shalom wrote:
> >>> 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.
> >> Oh, I'm certainly fine with disallowing side effects in 
> >> unique case completely.  If we want to go that route, the 
> >> whole issue is moot.
> >>
> >>> I also suggest that statically determinable uniqueness violations 
> >>> indicate a problem and therefore optimizations don't 
> interest me in 
> >>> such situations anyway.
> >> Someone could easily have duplicates due to edge case 
> >> parameterization, etc. that is never actually reachable in a 
> >> particular configuration of the circuit.
> >>
> >>  > 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?
> >>
> >> Yes, which is why I'm willing to give up optimizations in any 
> >> cases at all.  The current suggestions already restrict 
> >> previously valid optimizations.
> >>
> >> Gord.
> >>
> >>
> >>
> >>> 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.
> >> --
> >> 
> --------------------------------------------------------------------
> >> Gordon Vreugdenhil                                503-685-0808
> >> Model Technology (Mentor Graphics)                gordonv@model.com
> >>
> >>
> >> -- 
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> > 
> ---------------------------------------------------------------------
> > 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.
> 
> -- 
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> -- 
> 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.