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

Responses to comments by Krishna Garlapati, Steve Sharp and Uma Polisetti 
below -

At 11:09 AM 3/29/2005, Krishna Garlapati wrote:
>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.
>--
>Krishna
>408-215-6152

Hi, Krishna -

I strongly disagree.

As stated in my earlier email and as demonstrated 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)

As defined in the SV standard, "unique" does a run-time check to ensure 
that a case expression cannot match more than one case item (equivalent to 
parallel_case in Verilog and enforced by the syntax of VHDL), and it also 
does a run-time check to make sure the case expression matches at least one 
of the case-items (full_case equivalent, no test needed if a case-default 
is included in the code, and again enforced by the syntax of VHDL, which is 
why almost all VHDL case statements require an "others" clause).

"priority" behaves exactly like full_case, right down to being ignored if a 
case-default is added to the case statement (because then all possible 
cases will match at least one case item or the default).

There are still a lot of people who think full_case (and hence "priority") 
will remove all latches. This too is false and examples are given in my paper.

full_case and parallel_case were truly the "evil twins" and "priority" 
(although poorly named) and "unique" are the safe alternatives, but you 
still have to understand how they impact simulation and synthesis, so if 
poorly taught, engineers will be in deep doo-doo, and this thread has 
clearly shown that there are some bright people with dire misunderstandings 
about how these modifiers/assertions work.

I strongly suggest that people reference my Israel-SNUG paper regarding 
this topic, which is FREELY available on my web site at 
www.sunburst-design.com/papers

At 11:35 AM 3/29/2005, Steven Sharp wrote:
> >In my already stated opinion, the "priority" keyword sucks! But we are
> >stuck with it.
>
>Note that "priority" is also one of the keywords most likely to appear
>in legacy Verilog designs as an identifier, causing the design to fail
>to compile under SystemVerilog.
>
>Steven Sharp
>sharp@cadence.com

*sigh* t'is true. Using "all_possible" or "full_case" would have been more 
descriptive and less likely to collide with existing designs.

Unfortunately, "priority" has already made it into many designs. I have 
even seen one source recommend using either "priority" or "unique" with ALL 
RTL case-statements and if-else-if-statements, a recommendation I have 
debunked in my Israel-SNUG paper (doing so would eliminate a very powerful 
and useful synthesis coding style).

At 11:47 AM 3/29/2005, Uma Polisetti wrote:
>Hi all,
>
>As a user, I know we have "priority" used as a signal. But that doesn't
>bother me much because the users already gave up several of their
>favorite names such as bit, sequence etc...
>
>What bothers me most is that, priority is misleading. I didn't realize
>until now, that it is not what it means. Verilog already gives enough
>rope to kill the users. It seems like SystemVerilog is giving even more...
>
>Thanks,
>Uma

*sigh-again* t'is true again. For those who really understand the meanings 
of "priority" and "unique," most agree that "unique" is both descriptive 
and appropriate for the functionality it performs (actually more 
descriptive than parallel_case). The same people tend to agree that 
"priority" is a horrible keyword that is just plain deceptive. I guess it 
gives trainers and paper-writers, like myself, the opportunity to conduct 
more training and write more papers   :-)

I would rather have a better keyword and pass on the extra training slides 
and extra paper-verbiage.

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