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

Understood.  As a user, I would be fine with unique case only checking the
values of case item expressions without executing any code.  Thus, once the
first matching case item expression is found, subsequent case item
expressions that potentially modify values are only evaluated for overlap to
the extent possible without executing the expression.  This would catch just
about any overlap in case item expressions that would show up in practical
synthesizable RTL code.  As long as the standard clearly defines what must
be checked for overlap, and what is left up to tools, I'm happy.

As I said before, I think we should keep the actual evaluation order of
unique case the same as a regular case statement, and keep the checking for
overlap simple and intuitive.
 
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 Steven Sharp
> Sent: Monday, November 19, 2007 12:40 PM
> To: stuart@sutherland-hdl.com; sv-bc@server.eda.org; 
> shalom.bresticker@intel.com
> Subject: RE: [sv-bc] FW: Manti 1345, 1711: unique if/case
> 
> 
> >From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> 
> >Is there a sane case where i++ would be used as a unique case_item
> >expression? Is there a justification for making the tool 
> give it special
> >treatment, e.g., "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?"
> 
> We have been using i++ in our examples because it is short and easy to
> follow.  That might make this "temporary evaluation" idea 
> seem deceptively
> easy.  But in general, we need to deal with function calls that could
> execute arbitrary amounts of procedural code, theoretically capable of
> changing the value of every variable in the design, forcing every net,
> launching an arbitrary number of subprocesses, etc.  I don't 
> think this
> idea of throwing away the side effects is feasible in general.
> 
> Steven Sharp
> sharp@cadence.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.