RE: [sv-bc] FW: interpretation of priority if-else or case statement

Hi, All -

This is the first time I have heard this argument favoring the "priority" 
keyword. Allow me to rebut and then if he chooses, Stu can have the final word.

At 08:25 AM 3/29/2005, Stuart Sutherland wrote:
>Antara,
>
>I must disagree with Cliff on the value of the "priority" keyword.  It is
>true that SIMULATION will always evaluate a case statement in the order of
>case items, and an if...else...if series in the order of the if conditions.
>The Verilog 1364 semantics require this for simulation.  However, synthesis
>compilers can, and often do, optimize the order of these decisions, perhaps
>removing all priority completely (making them parallel evaluations.

To me this is a silly argument and not correct. True that simulation must 
test the case items or else-if items in the order presented, but if there 
is no overlap in the items, the simulation behaves exactly as if there is 
no priority (because the items are mutually exclusive). Only if there is no 
overlap in the simulation syntax will synthesis tools infer parallel logic. 
Synthesis tools have always matched simulation behavior. If there is 
simulation priority, there is synthesis priority. If there is no simulation 
priority, there will be no synthesis priority.

The priority keyword does nothing to the priority-nature of the synthesized 
result (my paper shows examples to prove this to be true). If you add 
"priority" to a case statement, Synopsys tools report "user" (or user-added 
switch) to the full-case report.

Adding priority merely informs simulation, synthesis and formal tools that 
all expected cases have been accounted for and that any other possible case 
is not expected and can be optimized away. We have informed the simulator 
to watch for and report unexpected cases, we have informed the synthesis 
tool that all unexpected cases can be used as don't cares when calculating 
the optimal sum-of-products. We have informed the formal tool that only the 
cases listed are valid and no other cases are expected; hence, flag an 
error if it can be formally proven that an unexpected case is possible.

As I point out in my paper:

- "priority" WITH case-default or if-statement else == regular 
case-statement or if-else-statement (no full_case and no parallel_case)
- "priority" with NO case-default or if-statement else == full_case
- "unique" WITH case-default or if-statement else == parallel_case (no 
priority encoder)
- "unique" with NO case-default or if-statement else == full_case 
parallel_case (no priority encoder)

Note that the "priority" keyword had nothing to do with priority encoders, 
but it did impact synthesis optimization. The coding style alone made a 
difference with priority encoders, until we added the "unique" keyword.

AT MOST, "priority" made an optimization difference and in the absence of 
default clauses, run-time-flagged the existence of unexpected cases.

In my already stated opinion, the "priority" keyword sucks! But we are 
stuck with it. Engineers should not be taught to use the priority keyword 
to get a priority encoder. Engineers should be taught that the priority 
keyword was just a very bad label to be used to assert that the 
case-statement or if-else-if statement had all cases fully defined.

My apologies to the user-community for not recognizing this back when I 
first joined the Superlog working group (predecessor to SystemVerilog). We 
might have fixed the problem back then had I done a more careful analysis 
of the "priority" functionality. Back then I was similarly confused, as was 
Antara in his recent email question.

>The
>priority keyword clearly documents that the designer expects a multiple
>branch decision to be evaluated in a specific order.

No it does not and as already mentioned, synthesis tools treat "priority" 
like full_case. Try it with the Synopsys tools and you will continue to see 
the full_case reports when you use this switch. The parallel_case report 
determines if you are going to get a priority encoder, not the full_case 
report.

>This documentation is
>more than a comment, it is part of the language.  Synthesis and formal
>verification tools can utilize the priority keyword to ensure that the
>designer's intent is realized in implementation.

Which is why this switch still has great value. It is a "safe" full_case 
switch that is recognized to have a common meaning by all tools, unlike the 
full_case comment-switch which gave different information to the synthesis 
tool than was given to a simulator. As you quoted me in your paper, I 
always say, "The full_case and parallel_case switches are always most 
dangerous ... when they work!!"

>I feel "priority" is both
>valuable, essential, and an appropriate choice of keywords.

Valuable - yes
Appropriate - no - misleading - yes

>Just my opinion...

And mine too   ;-)
In my opinion, this needs to be properly taught or engineers are going to 
think that they should use "priority" to build priority encoders. Wrong!

>Stu

Regards - Cliff

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training