In simulation, X-Propagation has been used to track how unknown states or signals move through a design at RTL. These “Xs” can cause areas of a design to malfunction once the design has been synthesized into its corresponding netlist. Despite all the advantages that today’s simulation provides, there are still occasional discrepancies in the simulated design of a netlist, and this is where the question of using the new X-Pessimism removal app comes into play.
When a design is powered up, it’s unknown what state any of the registers are in. It doesn’t matter if it’s a cold start or a proper power-up—the system doesn’t necessarily know the states of individual gates. Resets or retentions can be used to set predictable values, but resetting every flop in a complex design is too silicon-expensive in terms of area and timing. Thus, it is easier to reset only the critical flops that need reset, like control registers during the boot-up sequence. The remaining non-resettable flops are ones that could propagate Xs in gate-level simulation.
Ideally, the new X-Pessimism removal app allows a verification engineer to eliminate unknown states in certain regions of a design, letting them ensure a system will function properly regardless of how it starts up or shuts down.
Let’s say a signal and its inverted output are given to an AND gate.
Figure 1: Simulation vs. Hardware
X is a fictional value that a signal can take in simulation—but in real hardware, a signal can’t be unknown; it will be either 1 or 0. If you want to simulate how a design behaves regardless of the input from a certain area, for example, using Xs to represent these incoming signals makes a lot of sense. In real life, though, these signals have to be at a certain value. This is where X-propagation as a representation of unknown signals moving through a system breaks down—it is, at the end of the day, just a representation.
However, that representation can be made more accurate with certain assumptions. During normal X-propagation, a gate receiving an X will always pass an X as an output since it can’t be assumed that the X is any certain value. In the above example, though, this isn’t true—since the inputs are any value A and the inverse of that value, an AND gate will always return 0. This is where X-Pessimism steps in. In situations where the result of a logic gate is deterministic, an X can be cleared from the simulation by assigning the deterministic value to the output. This allows a simulation to more closely mimic real hardware by injecting the behavior that real hardware would have in certain logic situations.
Xcelium has a library designed to handle these situations. When used during simulation, these deterministic values are injected into the simulation in zero time and tracked via a Verilog file. The time these values are deposited is controlled by the TCL file. The X-Pessimism library handles it from there, identifying gates with deterministic outputs and assigning the correct deterministic output to them, overwriting areas that would be otherwise marked with X.
Keep in mind that X-Pessimism doesn’t support all primitives—only AND, OR, XOR, NAND, NOR, XNOR, BUF, and COMBINATIONAL UDP are supported. All other primitives and continuous assignments are treated as cutoff points. However, the basic primitives are more than enough to help a verification engineer better understand how a design will work in silicon, vastly improving simulation quality.
For more information on X-Pessimism, check out the RAK on it here.