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

>From: "Alsop, Thomas R" <thomas.r.alsop@intel.com>

>initial
>begin
>  int s = 4;
>  unique case (4)
>    s++, s: $display("hello");
>    4: $display("world");
>  endcase
>end
>
>In which case the order of the case_item expressions becomes important.

Well, if you changed the s++ to ++s it would.  Otherwise the s++ will
match since the value is taken before the post-increment.  But I
understand your point.


>You are right that these are corner cases. They seem like really rare
>cases and as a designer if I code them like this, I deserve what I get.
>Do you really believe we have to iron these out in the LRM?  I also want
>optimized implementation because it's faster run time.  These types of
>issues should be caught in linting tools, not spec'd out.
>
>That said however I think the optimization could be spelled out.  That
>seems like the best solution.  Is that the argument we are making here?
>i.e. "the evaluation of case_item expressions shall start from the left
>hand side and move to the right and upon first match will cease further
>evaluation" and "all case_item's will be evaluated from top to bottom
>and after the first violation will stop..."   

We don't have to specify the exact ordering.  We can specify explicitly
that it is undefined instead.  But we should specify something.  That
way implementors know what they are allowed to do, and users know what
they are guaranteed.

Leaving it undefined may allow freedom for some optimizations that I have
not thought of.  However, I don't think this is a significant advantage.
It only matters in the case where there are side-effects.  If there are
no side-effects, the evaluation order is not visible, and implementations
are free to do it however they like, no matter what order the LRM
describes.

BTW, if we specify the ordering, it should be in terms of first-to-last
rather than left-to-right or top-to-bottom.  There is no requirement
that case item expressions be on the same line, or that case items be
on separate lines.  First-to-last covers all formatting possibilities.

Steven Sharp
sharp@cadence.com


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