RE: [sv-bc] illegal priority if

From: Clifford E. Cummings <cliffc_at_.....>
Date: Fri Jan 13 2006 - 16:19:50 PST
Hi, All -

Interesting discussion but perhaps you would like a user's take on 
unique/priority. I have a full paper dedicated to the topic:

www.sunburst-design.com/papers/CummingsSNUG2005Israel_SystemVerilog_UniquePriority.pdf

Key notes:
case === case // duh!
priority case === case // synthesis full_case
priority case with default === case
unique case === case // synthesis full_case parallel_case
unique case with default === case // synthesis parallel_case

Now synthesis, simulation and formal tools all have the same 
information about the design, something that was lacking with the // 
synthesis full_case parallel_case pragmas.

Unique case removes priority encoders from synthesis and warns me 
during simulation if I match more than one case item (basically a 
built-in assertion that there was no priority encoder, has been proven wrong).

IMO - "priority" as a keyword sucks!! "allcases" or "fullcase" would 
be more descriptive keywords. Case statements are already "priority" 
but not all case statements are "fullcase" where we assert that all 
possible cases have been defined (so synthesis can treat other 
possibilities as don't cares). Too late to fix this keyword now (aaargh!)

Add either case-default or a final else to and if-else statement and 
fullcase testing is disabled (same as adding a case-default to a case 
statement with // synthesis full_case).

I can now do unique and all-possible-cases testing on if-else 
statements, which did not exist in Verilog simulation and synthesis.

SV3.1a called the run-time violations "errors." But Steve Sharp 
convinced us that due to indeterminate statement ordering, a 
simulator could not guarantee that all run-time violations were 
indeed errors, so we settled for "warnings." I think my paper still 
refers to the SV3.1a errors.

I consider unique/priority to be valuable case-statement / 
if-statement modifiers with built-in assertions.

I am not opposed to cleaning up any of the LRM descriptions.

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
Received on Fri Jan 13 16:19:59 2006

This archive was generated by hypermail 2.1.8 : Fri Jan 13 2006 - 16:20:57 PST