Like the name suggests, X propagation means propagating an X at the input of some logic to its outputs. Synopsys VCS Xprop can do so smartly, in many cases avoiding X optimism, making simulation behave closer to real hardware.

Xprop has three modes: xmerge, tmerge, and vmerge. Xmerge simply assigns X to outputs whenever any of the inputs are X. This behaviour is similar to what would be observed in gate level simulations, but can sometimes be even more pessimistic. With tmerge, when an input is X, the simulator will traverse both code paths assuming the input is 0 and 1, and compare the results. If the results are the same, the determinate result is assigned to the output. If the results differ, X is assigned to the output to do X propagation. Vermge basically disables Xprop, allowing classic Verilog X optimism.

Consider the if…else statement again from part 1 of the series:

always_ff @(posedge clk) begin
  if (cond)
    c <= a;
  else
    c <= b;
end

Let’s also add a gate level implementation of this multiplexer for comparison.

The truth table of Xprop Tmerge and Xmerge is as follows. You can see that Tmerge closely resembles actual hardware behaviour (though not always; depending on how the statement is implemented in gates, the last row may return X in gates).

a	b	cond	Classic Verilog Simulation	Gate Level Simulation	Actual Hardware	Xprop Xmerge	Xprop Tmerge
0	0	X	0	0	0	X	0
0	1	X	1	X	0/1	X	X
1	0	X	0	X	0/1	X	X
1	1	X	1	X	1	X	1

Xprop does similar X propagation on sequential logic with ambiguous clock transitions. Recall from part 1 of this series that Verilog normally treats ambiguous clock transitions as valid clock transitions (for example, 0->1, 0->X, 0->Z, X->1, Z->1 are all considered posedge), which can trigger sequential logic when real hardware may not. With Xprop enabled, an indeterminate clock transition will corrupt the outputs of sequential logic triggered by that clock.

Xprop can be even more useful with low power simulations, where powered off logic will drive X’s on outputs to indicate it is off. One of the ways that unisolated paths can be detected is to ensure these X’s can propagate to somewhere visible by your test environment.

Enabling Xprop takes relatively little effort. You simply need to provide some additional options to VCS, and an Xprop configuration file. The configuration file lists the module name, module hierarchy, or instance name to turn Xprop on or off. From the VCS User Guide:

vcs -xprop[=tmerge|xmerge] [-xprop=xprop_config_file] [-xprop=unifiedInference] source_files

A sample Xprop configuration file is as follows:

merge = tmerge
tree     {testbench}                             {xpropOff}; // marks a module name and its submodules
instance {u_testbench.u_dut_top}                 {xpropOff}; // marks an instance name
instance {u_testbench.u_dut_top.u_subsystem_top} {xpropOn};
module   {my_sram_module}                        {xpropOff}; // marks a module name

In a recent project I worked on, after turning on Xprop and debugging the resulting X’s, two design bugs were immediately found. The first bug was a list of flip-flops without reset that fed into the control path, causing a block to hang and not respond after reset. The block simulated fine without Xprop due to X optimism (in fact, block level verification was already complete). But once Xprop was enabled, it did not respond after reset until all the control path flip-flops were fixed and properly reset. The second bug was an incorrectly coded arbiter that could select an out of range bit out of a bus. Without Xprop, the arbiter returned 0 when the index was out of range of the bus width. With Xprop enabled, the arbiter assigned X to the output when the select became out of range and the bug surfaced.

One caveat when using Xprop is it can falsely score code coverage, as the simulator does in fact execute multiple branches of code when an X input causes divergent code paths. To work around this issue, since Xprop generally catches reset and testbench issues that are pervasive throughout an environment, you may be able to run only a small subset of tests with Xprop enabled to catch X optimism bugs, and collect code coverage with the remaining tests with Xprop disabled. Xprop may also not solve all your X optimism woes. X-Propagation: An Alternative to Gate Level Simulation discusses some false negatives from actual designs that Xprop stumbled on. Lastly, Xprop is not guaranteed to propagate X’s in your entire design and you should take a look at the Xprop reports to see which parts of your design it was able to instrument.

Xprop is a relatively easy way to make Verilog simulations behave closer to actual hardware. Provided that all block verification environments are Xprop clean, you will likely see diminishing returns using it at a cluster or full-chip environment. However, given the relatively low effort to setup and debug Xprop, it is definitely a simulator option that is recommended for any block level verification environment.

What are your experiences with using xprop in your simulations, especially in low power simulations with UPF? Have you found bugs you otherwise wouldn’t have? Leave a comment below!

The post SystemVerilog and Verilog X Optimism – Hardware-like X Propagation with Xprop appeared first on Verilog Pro.

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!

The post SystemVerilog and Verilog X Optimism – What About X Pessimism? appeared first on Verilog Pro.

X’s can be created intentionally or unintentionally. The most common occurrence of X is in uninitialized registers or memories; X is used to represent the unknown value of these memory elements prior to a reset. Other conditions that can generate X include signals that are being simultaneously driven to different logic values by different drivers, to indicate logic that is shutdown in low power simulations, out of range bit selects and array indices. Some designers assign X to signals to show that they are “don’t care” values, as a hint to the synthesis tool so it can assign either 1 or 0 to the signals during logic optimization. To aid debug, some designers also assign X to signals in code paths that are impossible to reach, causing the simulator to flag erroneous execution of these paths by corrupting signals to X. Intentionally assigning X to signals is a controversial practice, however, and may be flagged by linting tools.

Verilog X optimism refers to how simulations may incorrectly exhibit determinate behaviour even when inputs to logic are X and have indeterminate value. It can be dangerous and can mask real RTL bugs.

The first example of Verilog X optimism is a simple if…else statement:

always_ff @(posedge clk) begin
  if (cond)
    c <= a;
  else
    c <= b;
end

Verilog (and SystemVerilog) LRM states that when the condition of an if…else statement is X, the condition is interpreted as false, and the code following the else statement must be executed.

A very real potential design bug is imagine if cond is directly generated from the contents of a memory, for example a combinationally generated error signal from a SECDED decoder, the always block is trying to set an error interrupt to 1 using the decoder error signal as cond. In simulation, the memory contents are X prior to being written. The X can propagate through the decoder to cond, causing the else statement to be executed, assigning 0 to the error interrupt. Contrast this with real silicon behaviour, where upon power on, the memory contents are truly unknown and will likely immediately trigger a SECDED decoder error. cond is true, and the interrupt fires.

The second example of Verilog X optimism is a case statement:

always_ff @(posedge clk) begin
  case (cond)
    1'b0 : c = a;
    1'b1 : c = b;
  endcase
end

X logic value in the select input actually causes c to retain the value of the previous clock, a completely different behaviour than the desired multiplexer.

A third example of Verilog X optimism is how Verilog and SystemVerilog treats transitions to X or Z. The following are all valid logic transitions that will trigger a posedge operator

• 0->1, 0->X, 0->Z, X->1, Z->1

A 0->X or X->1 transition may or may not be a real posedge transition in silicon. But in simulation, the simulator will behave as though a positive edge on the clock has occurred, latching data into any registers triggered by posedge.

This post described three different Verilog and SystemVerilog constructs that can cause simulation and synthesis mismatch due to Verilog X optimism. Some material for further reading are X-Optimism Elimination during RTL Verification and I’m Still In Love With My X!.

In part 2 of the series, Are You A Pessimist? Mitigating Risk of SystemVerilog and Verilog X Optimism, I will describe several ways to avoid X optimism in simulation, and uncover design bugs that may be masked by Verilog X optimism.

The post SystemVerilog and Verilog X Optimism – You May Not Be Simulating What You Think appeared first on Verilog Pro.