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

As we see it here, a unique is identical to full-case except
that the compiler does not issue a warning (unlike full-case)
that a user might get different simulation and synthesis results.

- Krishna.


Clifford E. Cummings wrote:
> 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
> 
> 
> 
> 


-- 
Krishna
408-215-6152