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

>From: "Stuart Sutherland" <stuart@sutherland-hdl.com>

>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 don't think you should expect checking from synthesis, except for
obvious errors.  I think you should expect them to believe your unique
modifier and generate parallel logic.  They will expect you to have run
simulation to determine whether your unique modifier was correct, and
remove it if you got a violation and actually needed priority logic.  In
other words, I expect synthesis to treat it like parallel_case, and
simulation to help verify that it really was parallel.

Perhaps someone with more synthesis knowledge can comment.

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

Here you are talking about the effects of executing the code associated
with the case item.  We did discuss that way back, and determined that
the case item expressions must be checked before the case item statement
is executed.  It is easy to demonstrate why.

Your case statement could be in a sequential block, and be the next-state
logic for a state machine.  In some unusual situation, someone might use
the current state in the case item expressions (instead of the usual
situation of using it in the case expression).  The case is decoding the
current state, and all the checking must be done with the current state.
If you execute the case item statement, which updates to the next state,
and then go back to checking case item expressions, you would be checking
some of the expressions with the next state.  If the current state selects
one case item, and the next state selects a different case item, that is
perfectly reasonable, and is not a violation.

This has already been fixed in the LRM.  What we are discussing now is
side-effects just from evaluating the case item expressions.

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

Let's not lose sight of what the rules were designed to detect.  They are
not designed to detect this kind of "likely" coding error (which is actually
likely to be valid).  They are designed to catch one specific kind of
definite coding error: logic that was intended to give the same result with
parallel decode as with priority decode, but does not.  Multiple matching
expressions on the same case item is still a valid parallel decode.  

As Thomas said, the result of the case expression comparisons for the same
case item will be ORed together.  If two of them match, that is fine.
If you have to ensure that only one matches, that may complicate your
selection logic.  The synthesis tool will probably optimize it back to
the simpler logic anyway, but meanwhile you had to work harder and write
something more complex.


Steven Sharp
sharp@cadence.com


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