SystemVerilog and Verilog X Optimism – What About X Pessimism?

In my previous post about SystemVerilog and Verilog X Optimism – You May Not Be Simulating What You Think, I discussed what is Verilog X optimism, and some coding styles that are prone to Verilog X optimism bugs. So how do you avoid potential bugs that Verilog X optimism can introduce?

One technique that has been discussed in literature is to not use X’s at all, but make the values of flip-flops and memories at the beginning of simulation determine, and randomly assign 0’s and 1’s to them. This would have to be done using a tool as doing so manually would be impractical. The problem with this approach is how would you know whether you have covered the state space that could cause a problem? The number of possible states is of course 2ⁿ, which is likely impractical to cover. This technique could be interesting though if, for example, you want to know whether a particular X on an un-reset flop can cause a design problem. You could setup two simulations assigning 0 and 1 to the X, and verify that they both produce the same result.

Another option is you could swing to the opposite end of the spectrum, and attempt to make constructs X pessimistic. With this principle, you would code RTL in such a way that X’s will propagate through logic, thus guaranteeing all ambiguities will propagate to downstream code. However, being pessimistic, simulations may yield X where there is really no uncertainty in actual silicon behaviour.

Looking at our X optimistic if…else again, first we can try making it more pessimistic by adding a “default” statement to fallback on. Consider this coding style for an if…else statement:

always_comb begin
  if (sel)
    y = a;
  else if (!sel)
    y = b;
  else
    y = 'x;
end

This coding style does swing to the opposite end of the spectrum of X-pessimism. Even if a and b have the same value, an X on sel causes the output y to become X.

Similarly, we can modify the X optimistic case statement to propagate X from case selection expression to outputs:

always_comb begin
  case (sel)
    2'b00:   y = a;
    2'b01:   y = a;
    2'b10:   y = a;
    2'b11:   y = a;
    default: y = 'x;
  endcase
end

This coding style does address Verilog X optimism in case statements, but not in wildcard case statements like casex and casez. Both of these coding styles can be processed by synthesis tools without problems. However, some linting tools may flag X assignment, and it is sometimes a controversial practice.

A different way to address if…else X optimism is with the conditional operator:

condition ? expression_if_true : expression_if_false

expression_if_true is executed if condition evaluates to true, and similarly, expression_if_false is executed if condition evaluates to false. But additionally, if condition evaluates to unknown, then for each bit in the value of expression_if_true that differs from expression_if_false (or if the bit is X or Z) then X is assigned to that bit. The caveat, however, is if condition is multi-bit, then any bit in the condition that is a 1 causes the entire condition to be evaluated as true. Therefore, the conditional operator does propagate X to downstream logic, provided the condition is a single bit expression. While this works for simple expressions, it quickly becomes unwieldy to code complex nested if…else statements using this technique.

Stuart Sutherland in his paper I’m Still In Love With My X! recommends a method of trapping X’s with assertions. This method can be applied to any conditions that include input ports to a module to trap X’s at inputs. Quoting from the paper:

`define assert_condition (cond) \
  assert (^cond === 1'bx) \
  else $error("%m, ifcond = X")

always_comb begin
  `assert_condition(sel)
  if (sel)
    y = a;
  else
    y = b;
end

always_comb begin
  `assert_condition((a,b,c,d))
  `assert_condition(sel)
  case (sel)
    2'b00 : out = a;
    2'b01 : out = b;
    2'b10 : out = c;
    2'b11 : out = d;
  endcase
end

Since SystemVerilog assertions are ignored by synthesis tools, this code can be synthesized without modification.

If you’d like to learn more, I’d recommend the very comprehensive paper I’m Still In Love With My X!. In the next post in the series, I will discuss using proprietary simulator features like Synopsys VCS xprop to address X optimism.

What are your experiences with Verilog X optimism or X pessimism? How do you ensure your simulation is as accurate as possible? Leave a comment below!