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

Hi, Stu. 

> >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. 

The problem is side-effects in the case_item expressions. The results
can differ even if only one such expression matches.

But again, there should never be side-effects in case_item expressions
in code intended for synthesis. And if there are, the I think the user
probably expected the top-down order anyway.

> 
> 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.
> 
> 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.

We discussed that in Mantis 1304, and decided that all case_item
checking must be done before executing the branch, because of that very
problem, and it probably does not even require a side-effect to cause
it.

> 
> 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.

The LRM says differently. The LRM says that uniqueness is violated if
more than one case_item matches, not if more than one case_item
expression matches. This was Mantis 2036, and we passed that
clarification.
> 
> 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.
> 
> Just my two cents worth on this topic...
> 
> Stu

Regards,
Shalom
---------------------------------------------------------------------
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.