X-Propagation Methodology Note

Getting Started

Engineers should enable X-prop only on code that is part of the actual design, which,
is generally intended to be synthesized into gate-level representation. One of the
benefits of running X-prop simulations is to avoid behavior mismatches between the
RTL simulation and the actual hardware, it’s reasonable to enable X-propagation
semantics on the modules that will be synthesized to hardware. Other types of non-
synthesizable or test-bench code should normally be excluded from X-prop
simulation. One exception may be simulation models written in a higher level than
RTL that are still accurate enough to correctly model the ambiguity due to X values.
The X-prop configuration file should be used to designate the modules/hierarchies
that are to be excluded. The configuration file provides 3 ways to exclude blocks from
X-prop: by module, by tree, and by instance. Exclusion by module only applies to the
particular module, while exclusion by tree or instance affects the particular module or
instance and all of its sub-modules.

Xprop log file

Before simulating, users should inspect the Xprop log-file generated during
compilation. At the end, the log file summarizes one key metric: the instrumentation
percentage. The percentage should be close to one hundred percent. If the percentage
is significantly lower than 100%, then the design code should be inspected to
determine the reasons why code was excluded from instrumentation. A low
instrumentation percentage often indicates that sizeable test-bench (non-
synthesizable) code was included in the partition designated for X-prop
instrumentation. If this is the case, it is best to exclude them before proceeding with
the simulation.

Key Design Signals

Generation of clock and reset signals requires extra attention for Xprop simulation.
This is because in traditional RTL simulation, a flip-flop will (optimistically) store
incoming data when a clock toggles from 0àX. But, with X-prop enabled, the same
flip-flop may not appear to work because X-prop semantics more accurately model
the ambiguity of the transition. X-prop handles ambiguous edges by merging the two
behaviors: retaining the previous value and storing the new value. This type of
ambiguous edge is typically found in gated clocks, so it may be worthwhile to
examine them to ensure they are producing clean edges (0à1 and 1à0) before
debugging other test failures. Typically, this type of failure is characterized by longer
lasting reset sequences – if the reset sequences are not given enough time to clean out
the X’s, the design may not be properly reset.

Debugging Test Failures

Once X-prop is enabled, traditional RTL debugging techniques can be used to debug
test failures and identify the problem. Debugging RTL-code is a fairly routine process
today, and several debug tools that do this reasonably well are available. Debugging
simulation failures at the RTL level is a much easier task than at the gate-level, due to
the fact that the code is much closer to the actual functional intent of the circuit. A
typical debug process is as follows:

 Regression failure
 Re-run with dumping enabled
 Go-To point of test failure (assertion, monitor,…)
 Trace back mismatching signal to origin
 Identify root cause

There are other flows that engineers use to debug regression failures. One common
technique is to compare the dump file of a working (golden) regression and a failing
regression, in order to look for differences near the point of failure. Another common
technique is to find the earliest passing regression, and then examine all the
intervening code-checkins to identify the offending checkin. All of these techniques
are applicable with X-prop enabled; however, because X-prop uses widely different
simulation semantics (compared to traditional RTL), they must be used judiciously.
Several common mistakes, detailed below, are to be avoided.
Engineers should *not* compare waveforms corresponding to different simulation
semantics: with and without X-prop. This often leads to extraneous and wasted debug
cycles that fail to pinpoint the source of a problem. Consider, for example, that in
legacy (non X-prop) mode, it may take 10 cycles to reset a device, whereas in X-prop
mode it may take 100 cycles to reset the same device; this is due to ambiguous clock
transitions or unclean reset signal. Comparing the waveforms of the two simulations
will quickly reveal that the two simulations are not cycle accurate with respect to each
other; they may be functionally similar traces, but over vastly different time spans.
Identifying all the intervening mismatches and finding the common similarities is a
daunting ask that will often not lead to a problem area – it will only highlight the two
simulation semantics.

Another important caveat is that some industrial debug tools can automatically trace
back signal changes across many logic levels to some origin that caused the signal
change. These debug tools are inextricable tied to the RTL simulation semantics, and
unless they also understand X-prop semantics, they will fail to understand how some
X’s propagate through the RTL and subsequently fail. Currently, some manual
intervention may be required when using such debug tools.

Bottom up vs. Top Down

Enabling X-prop on an entire (i.e., chip-level) design whose components have not
been previously verified with X-prop is likely to fail due to the larger number of X’s
simulated and their longer persistency. It will typically take many long iterative cycles
to find, bypass, or fix all the issues. Hence, it is worth considering a divide- and-
conquer approach: enable X-prop only on a certain block at a time, find and fix and
design issues in that block, and then move on to the next block. The downside to this
methodology is that this there is no guarantee that if all blocks run clean, the entire
chip would be X-prop clean. However, it’s typically easier to debug the environment
when only considering the issues of a small block (enabled for X-prop).

Scrubbing IP’s

If IP’s are used then it is probably worthwhile to scrub these clean with the X-prop
simulator. This is facilitated if the IP is delivered with block-level tests that can be
independently run with X-prop. This approach also makes the chip-level simulations
easier to debug, without wasting precious debug cycles.

Assertions – Self-Checking vs. Reference Models

The recommended debug methodology is to ensure that the design includes enough
assertions or test-bench monitors that will catch deviations from correct functionality.
Starting with the assertion message, one can trace back to the origin of the faulty
signal. Hence, a self-checking methodology is preferred over reference-model
schemes in which the reference model lacks accuracy with respect to X’s. All too
often the reference model is simply the waveforms (or dumped state) of a higher-level
model that dos not model X’s with enough fidelity to the actual hardware. As
mentioned above, comparing the results of different simulation semantics is likely to
uncover the simulator differences, and not the actual design problems. If a reference
model is to be used then it must either exhibit enough fidelity to the actual hardware
to yield meaningful results, or it must abstract much of the low-level details to avoid
debugging inconsequential differences.