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

Hi, All -

I believes Brad's recommendations are flawed. Reasons below.

At 10:42 AM 3/30/2005, Brad Pierce wrote:
>Cliff,
>
> >I have even seen one source recommend using either "priority"
> >or "unique" with ALL  RTL case-statements and if-else-if-statements

I strongly disagree. Let me elaborate my reasons by addressing your 
recommendations with an example. Consider the following very efficient 
(coding and synthesis) 4-to-1 decoder:

module decode4
   (output reg [3:0] y,
    input      [1:0] a,
    input            en);

   always_comb begin
     y = '0;
     case ({en,a})
       3'b1_00: y[a] = '1;
       3'b1_01: y[a] = '1;
       3'b1_10: y[a] = '1;
       3'b1_11: y[a] = '1;
     endcase
   end
endmodule

>And that's a good recommendation.  Here's my recommendation for
>SystemVerilog case statements --
>
>   1) Always use 'priority' or 'unique'.


module decode4
   (output reg [3:0] y,
    input      [1:0] a,
    input            en);

   always_comb begin
     y = '0;
     priority case ({en,a})
       3'b1_00: y[a] = '1;
       3'b1_01: y[a] = '1;
       3'b1_10: y[a] = '1;
       3'b1_11: y[a] = '1;
     endcase
   end
endmodule

I know I am skipping your next recommendations, but stay with me. This 
model fails to produce the correct synthesis results (en is optimized out 
of the design).


>   2) Always cover all reachable 2-state values.

module decode4
   (output reg [3:0] y,
    input      [1:0] a,
    input            en);

   always_comb begin
     y = '0;
     priority casez ({en,a})
       3'b1_00: y[a] = '1;
       3'b1_01: y[a] = '1;
       3'b1_10: y[a] = '1;
       3'b1_11: y[a] = '1;
       3'b0_??: y    = '0;
     endcase
   end
endmodule

Now it passes synthesis and simulation but is more verbose and uses the 
slightly more dangerous casez statement (many engineers still use the very 
dangerous casex statement when testing don't cares).

Consider what this guideline requires for FSM designs. Onehot and output 
encoded FSM designs become terribly complex and probably very 
synthesis-inefficient if you ask engineers to cover all 2-state values. See:

www.sunburst-design.com/papers/CummingsSNUG2003SJ_SystemVerilogFSM.pdf
www.sunburst-design.com/papers/CummingsSNUG2000Boston_FSM.pdf
(Other FSM papers on my web page)

Now that engineers are going to use enumerated types for testing in case 
statements, how does your recommendation apply?


>   3) Always use a default X assignment.


I semi-agree with this recommendation (for synthesis efficiency reasons), 
but there are many companies that strongly discourage the use of 
X-assignments, period. Just search the Boston and San Jose SNUG archives 
for the past two years and you will see the papers and experiences. Many 
companies fear the X-optimism and X-pessimism issues related to X-assignments.

module decode4
   (output reg [3:0] y,
    input      [1:0] a,
    input            en);

   always_comb begin
     y = '0;
     priority casez ({en,a})
       3'b1_00: y[a] = '1;
       3'b1_01: y[a] = '1;
       3'b1_10: y[a] = '1;
       3'b1_11: y[a] = '1;
       3'b0_??: y    = '0;
       default: y    = 'x;
     endcase
   end
endmodule

Now I have followed your guidelines on this simple little decoder, and it 
will work. It is needlessly verbose, but it will work.

If you tackle a large FSM design with multiple states and multiple outputs, 
your guidelines are going to become very intrusive.


>Is the 'priority' keyword redundant if you remember to follow
>rule 3?  Yes, but so are line breaks and indentation.


Line breaks and indents add to the readability of the code. Extra verbiage 
adds to the confusion-factor for someone reviewing the code ("why did Joe 
add these extra lines and assignments? Couldn't this work without the extra 
code?")

BTW - If you are wondering about the pre-case y = '0; assignment, default 
assignments before a case statement have traditionally yielded superior 
synthesis results and they guarantee the removal of latches. A case 
statement that includes "priority," coverage of all 2-state conditions and 
a default-X does not guarantee latch removal if the designer made a 
mistake. See below.

module addrDecode1d
   (output reg         mce0_n, mce1_n, rce_n,
    input      [31:30] addr);

   always_comb begin
     // {mce1_n, mce0_n, rce_n} = '1; // would remove latches
     priority casez (addr)
       2'b10: {mce1_n, mce0_n} = 2'b10;
       2'b11: {mce1_n, mce0_n} = 2'b01;
       2'b0?:           rce_n  = 1'b0;
       default: {mce1_n, mce0_n, rce_n} = 'x;
     endcase
   end
endmodule


>A fourth recommendation, to enforce rule 3 and to self-document
>which variable is assigned by the case --
>
>      `define PRIORITY_CASE(expr, lhs, assign) \
>             priority case (expr) default lhs assign 'x ;
>
>For example,
>
>       `PRIORITY_CASE(expr, o, <=)
>          2'b00: ...
>          ...
>        endcase
>
>Likewise,
>
>      `define PARALLEL_CASE(expr, lhs, assign) \
>             unique case (expr) default lhs assign 'x ;


I really dislike this! Are you using continuous procedural assignments (the 
assign keyword inside of a case statement) in these macro definitions?? We 
deprecated these and they are not synthesizable.

Also, what happens when you start building large combinational case 
statements for FSM designs? I don't view all long concatenations as being 
very self-documenting.

And finally, the `PRIORITY_CASE is still deceptive. Case statements and 
if-else-if statements are already priority statements if there is overlap 
in the tested conditions. They are never priority statements if there is no 
overlap in the tested conditions. "priority" adds the full_case 
capabilities. It tells tools that all expected cases have been defined. 
Issue a warning or error if I ever feed an unexpected expression to the 
case statement (which you will now never see because the "default" will 
cancel all checking for unexpected cases).

If engineers followed your guidelines #2 and #3 (which I do not recommend), 
they would never need nor benefit from the use of the "priority" keyword.

We find ourselves in strong disagreement on these recommendations but I do 
believe this discussion is healthy, because like I say, there are some very 
bright people who do not really understand the new "priority" keyword and 
who are making bad recommendations (IMO). No disrespect intended (really, 
quite the contrary. I have high regard for your capabilities and opinions).


>-- Brad

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