SystemVerilog Unique And Priority – How Do I Use Them?

Improperly coded Verilog case statements can frequently cause unintended synthesis optimizations or unintended latches. These problems, if not caught in pre-silicon simulations or gate level simulations, can easily lead to a non-functional chip. The new SystemVerilog unique and priority keywords are designed to address these coding traps. In this article, we will take a closer look at how to use these new SystemVerilog keywords in RTL coding. The reader is assumed to have knowledge of how Verilog case statements work. Those who are not familiar can refer to my previous post “Verilog twins: case, casez, casex. Which Should I Use?“

The SystemVerilog unique and priority modifiers are placed before an if, case, casez, casex statement, like this:

unique if (expression)
  statements
else
  statements

priority case (case_expression)
  case_item_1: case_expression_1
  case_item_2: case_expression_2
endcase

With the if…else statement, the SystemVerilog unique or priority keyword is placed only before the first if, but affects all subsequent else if and else statements.

SystemVerilog Unique Keyword

The unique keyword tells all software tools that support SystemVerilog, including those for simulation, synthesis, lint-checking, formal verification, that each selection item in a series of decisions is unique from any other selection item in that series, and that all legal cases have been listed. In other words, each item is mutually exclusive, and the if…else or case statement specifies all valid selection items.

It is easier to illustrate the effects of SystemVerilog unique using a case statement. unique case causes a simulator to add run-time checks that will report a warning if any of the following conditions are true:

1. More than one case item matches the case expression
2. No case item matches the case expression, and there is no default case

To illustrate how SystemVerilog unique affects simulation of case statements, let’s look at a wildcard casez statement:

always @(irq) begin
  {int2, int1, int0} = 3'b000;
  unique casez (irq)
    3'b1?? : int2 = 1'b1;
    3'b?1? : int1 = 1'b1;
    3'b??1 : int0 = 1'b1;
  endcase
end

You may recognize that this code resembles the priority decoder example from my previous post “Verilog twins: case, casez, casex. Which Should I Use?” However, by adding the SystemVerilog unique keyword, the behaviour is now completely different.

Firstly, by adding the SystemVerilog unique keyword, the designer asserts that only one case item can match at a time. If more than one bit of irq is set in simulation, the simulator will generate a warning, flagging that the assumption of irq being one-hot has been violated. Secondly, to synthesis tools, the unique keyword tells the tool that all valid case items have been specified, and can be evaluated in parallel. Synthesis is free to optimize the case items that are not listed.

Read the second point again, it is paramount! In a unique case statement (without a default case), outputs after synthesis from any unlisted case item is indeterminate. In simulation you may see a deterministic behaviour, maybe even an output that looks correct (along with an easy-to-miss warning), but that may not match what you see in silicon. I have personally seen a chip that did not work because of this coding error.

Back to the example, because of the unique keyword, synthesis will remove the priority logic. Thus, this code example is actually a decoder with no priority logic. Eliminating unnecessary priority logic typically results in smaller and faster logic, but only if it is indeed the designer’s intention.

The SystemVerilog unique keyword can be applied similarly to an if…else statement to convey the same uniqueness properties. For a unique if statement, a simulator will generate a run-time warning if any of the following is false:

1. If two or more of the if conditions are true at the same time
2. If all of the if conditions (including else if) are false, and there is no final else branch

SystemVerilog 2012 adds the keyword unique0 which, when used with a case or if statement, generates a warning only for the first condition above.

SystemVerilog Priority Keyword

The priority keyword instructs all tools that support SystemVerilog that each selection item in a series of decisions must be evaluated in the order in which they are listed, and all legal cases have been listed. A synthesis tool is free to optimize the logic assuming that all other unlisted conditions are don’t cares. If the priority case statement includes a case default statement, however, then the effect of the priority keyword is disabled because the case statement has then listed all possible conditions. In other words, the case statement is full.

Since the designer asserts that all conditions have been listed, a priority case will cause simulators to add run-time checks that will report a warning for the following condition:

1. If the case expression does not match any of the case item expressions, and there is no default case

A priority if will cause simulators to report a warning if all of the if…if else conditions are false, and there is no final else branch. An else branch will disable the effect of the priority if.

When to Use Them

SystemVerilog unique and priority should be used especially in case statements that infer priority or non-priority logic. Using these keywords help convey design intent, guide synthesis tools to the correct result, and adds simulation and formal verification assertions that check for violation of design assumptions. One suggestion from “full_case parallel_case”, the Evil Twins of Verilog Synthesis is to code intentional priority encoders using if…else if statements rather than case statements, as it is easier for the typical engineer to recognize a priority encoder coded that way.

SystemVerilog unique and priority do not guarantee the removal of unwanted latches. Any case statement that makes assignments to more than one output in each case item statement can still generate latches if one or more output assignments are missing from other case item statements. One of the easiest ways to avoid these unwanted latches is by making a default assignment to the outputs before the case statement.

The unique and priority keywords should not be blindly added to any case and if statements either. Below is an example where the priority keyword will cause a design to break. The hardware that is intended is a decoder with enable en. When en=0, the decoder should output 4’b0000 on y.

logic [3:0] y;
logic [1:0] a;
logic       en;

always_comb begin
  y = '0;
  priority case ({en,a})
    3'b100: y[a] = 1'b1;
    3'b101: y[a] = 1'b1;
    3'b110: y[a] = 1'b1;
    3'b111: y[a] = 1'b1;
  endcase
end

The logic will synthesize to something like this:

Here the priority keyword indicates that all unlisted case items are don’t cares, and can be optimized. As a result, the synthesis tool will simply optimize away en, which results in a different hardware than what was intended. A simulator will report a warning whenever en=0, which should raise an alarm warning that something is wrong. The unique keyword will have the same result here.

Conclusion

SystemVerilog unique and priority help avoid bugs from incorrectly coded case and if…else statements. They are part of the SystemVerilog language which means all tools that support SystemVerilog, including those for simulation, lint-checking, formal verification, synthesis, all have to implement the same specification of these keywords. Using these keywords help convey design intent, guide synthesis tools to the correct result, and adds simulation and formal verification checks for violation of design assumption.

In this post I have purposely tried to avoid discussing the Verilog pragmas full_case and parallel_case to write a more stand-alone discussion of the SystemVerilog unique and priority keywords. Those who are interested in the historical development of these keywords from Verilog full_case and parallel_case can refer to “full_case parallel_case”, the Evil Twins of Verilog Synthesis.

Do you have other experiences or examples of when to use or not use unique and priority? Leave a comment below!

References

• “full_case parallel_case”, the Evil Twins of Verilog Synthesis
• SystemVerilog Saves the Day—the Evil Twins are Defeated! “unique” and “priority” are the new Heroes
• SystemVerilog’s priority & unique – A Solution to Verilog’s “full_case” & “parallel_case” Evil Twins!

Quiz and Sample Source Code

Now it’s time for a quiz! How will each of the following variations of case statement behave when the case expression

1. matches one of the non-default case items
2. does not match any non-default case item
3. contains all X’s (e.g. if the signal comes from an uninitialized memory)
4. contains all Z’s (e.g. if the signal is unconnected)
5. contains a single bit X
6. contains a single bit Z?

Case statement variations:

1. Plain case statement
2. Plain case with default case
3. Casez
4. Casez with default case
5. Casex
6. Casex with default case
7. Unique case
8. Unique case with default case
9. Unique casez
10. Unique casex

Stumped? Download the executable source code to find out the answer!

[lab_subscriber_download_form download_id=7]