The sheer complexity and common use of power management schemes increase the likelihood of an unknown "X" state in the design translating into a functional bug in the final chip.
The propagation of unknown (“X”) states has become a more pressing issue with the move toward billion-gate SoC designs, especially power-managed SoC designs. The SystemVerilog standard defines an X as an “unknown” value used to represent the state in which simulation cannot definitely resolve a signal to a “1,” a “0,” or a “Z.”
Synthesis, on the other hand, defines an X as a “don’t care,” enabling greater flexibility and optimization. Unfortunately, Verilog RTL simulation semantics often mask the propagation of an X value, while gate-level simulations show additional Xs that will not exist in real hardware.
The sheer complexity and common use of power management schemes increase the likelihood of an unknown “X” state in the design translating into a functional bug in the final chip. This possibility has been the subject of two technical presentations at the Design and Verification Conference during the last couple of years: I'm Still in Love With My X! But, Do I Want My X to Be an Optimist, a Pessimist, or Eliminated? and X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist. Let’s look more closely at this issue and the requirements for a solution.
Billion-gate designs have millions of flip flops to initialize. Many of the IP blocks used in such designs also have their own initialization schemes. It is neither practical nor desirable to wire a reset signal to every single flop. It makes more sense to route resets to an optimal minimum set of flops that will initialize the remaining flops in the design. This approach poses a significant RTL coding challenge to ensure that it is the known values that propagate and not an unknown value that has been masked by optimism.
The analysis of any system with a complex initialization scheme is bound to identify many Xs. The issue is in knowing which ones matter, because dealing with unnecessary Xs wastes time and resources. However, missing an X state that does matter can increase the likelihood of late-stage debug, cause insidious functional failures, and, ultimately, necessitate respins.
Today’s power schemes further complicate the analysis of X issues. Coming out of a suspended state, initialization may occur via a reset signal, from retention flops, or by signal propagation. Besides the power schemes, the interaction between blocks must also be considered in any analysis, because it impacts what occurs on the inputs to the blocks.
Two simulation behaviors are working against designers -- X-optimism and X-pessimism. X-optimism is primarily associated with RTL simulation and is caused by the limitations of HDL simulation semantics. It occurs when a simulator converts an X state into a 0 or a 1, creating the risk that an X causes a functional failure that will be missed in RTL simulation.
X-pessimism is primarily associated with gate-level simulation of netlists. As its name suggests, it happens when legitimate 0s or 1s are converted into an X state. This can lead to precious debug resources being directed toward unnecessary effort. Additionally, after synthesis has done its work, debug at the gate level is more challenging than in RTL.
Some engineers point out that we have always had to deal with Xs, and nothing really has changed. In fact, today’s SoCs employ different power management schemes that wake up or suspend IP. When coming out of a low-power state, Xs that will propagate to X-sensitive logic must be cleared on reset or within a specific short number of cycles afterward.
The situation is now much more uncertain for designers who must determine whether all possible power scenarios are considered and whether all Xs will be cleared correctly. Simply throwing a switch on a simulator to make all of the control logic X-safe and eliminate the optimistic behavior is a possible solution, but there are drawbacks.