Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Addressing the problem of X unknowns in simulation

Posted: 18 Nov 2014 ?? ?Print Version ?Bookmark and Share

Keywords:unknown? Verilog RTL? coding? simulation? X-optimism?

As we transition towards billion-gate SoC designs, especially power-managed SoC designs, the propagation of unknown ("X") states has become a more pressing issue. 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 optimisation. 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 initialise. Many of the IP blocks used in such designs also have their own initialisation 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 initialise 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 initialisation 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 re-spins.

Today's power schemes further complicate the analysis of X issues. Coming out of a suspended state, initialisation 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 behaviours are working against designersX-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 towards 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.

1???2?Next Page?Last Page

Article Comments - Addressing the problem of X unknowns...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top