Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Multiple factors create challenges for debug, including when values are unknown or “X”. An X is one of the many logic values defined by the various logic standards, VHDL, Verilog, SystemVerilog, and others. The X predicts uncertainty on a logic signal in a design or verification environment logic simulation. The reason it brings uncertainty into the logic simulation is that an X could represent a 1, 0, or Z, hence the value of X is unknown. Making matters more complicated, the X’s uncertainty is different in RTL vs Gate simulation. By default, RTL logic simulators optimistically allow Xs to be logically blocked. A classic example is the case where a mux select signal has an X. What determines if the X will propagate is how it is modeled. Refer to the below table, originally published in the DVCon 2013 paper titled “I’m Still In Love with My X!” authored by Sutherland HDL.
Notice how the modeling determines if the simulator allows a multiplexor to pass a 0, a 1 or an X. Note that in actual silicon, the signal values are always a 1 (high voltage) or a 0 (low voltage).
So why care about this optimism?
Optimism can hide a potential design flaw. In the table image, if the Sel input were unconnected, the silicon circuit would electrically behave unpredictability. If a 1 is expected on the output but a 0 appears instead, the actual silicon circuit might be unstable and would need to be reset several times in order to get the desired value of 1.
Gate-level simulations correlate to silicon values more because they tend to use mechanisms (or logic tables) in the technology logic cells that allow Xs to pass. This propagation of Xs allow users to catch undesired behaviors prior to manufacturing silicon.
In addition to blocking Xs due to optimistic propagation behavior, as in the case of RTL simulations, there are scenarios where Xs should not propagate. Take the simple example in the figure below:
Regardless of the X value at the output of block A, the logic itself should always produce a 0 at the output of the AND gate. In this case, the logic structure modelling/simulation is too pessimistic. While debugging such an X on the output of that logic structure would be a waste of time for an engineer, it would be very useful to know that this type of structure exists in the design.
Why are Xs hard to find?
No matter how the X is propagated in RTL or gate-level simulations, nearly all Xs are difficult to debug. Why is that? First, it is possible that there are many root causes or sources of Xs. For example, an X could be resulting from a logic gate with an X input (not driven), a memory or flip-flop which is uninitialized to a known value, or a flop that has a violation of a setup or hold time. The below figure provides a simple example: it is very common to not only have one X at the same time but multiple Xs as in the case of this AND gate. The Xs on inputs i1 and i2 together cause the X at the output o1.
When multiple Xs occur on the inputs the user needs to select one of them as the starting point for debugging the X, then repeatedly trace backwards to the drivers or fan-in signals of the signal of interest until the earliest X value or root cause can be found. When the interesting signal or the root cause signal is not the only one cause of the X value, then the user would choose the other input X to trace its root cause. The second root cause might be the same root cause as the previous error or another source. This is one key reason why debugging Xs is difficult, frustrating and time consuming.
Also, Xs typically propagate through the design over a few thousand RTL statements or levels of gate logic before they reach an observation point, debug entry point or output port. Of course, this depends on the type of environment it’s deployed in; block level, chip level or SoC. A single root cause may also propagate to multiple observation points. In addition, these root causes and observation point cones of logic may be intertwined. All these things also make tracing Xs very difficult. The below image illustrates the concept of the X propagation and overlapping of Xs on the outputs. Input A propagates only to output Z1, and input B propagates only to output Z3, but inputs A and B both propagate to output Z2.
This process of tracing requires several iterative actions which are very tedious. It also requires an understanding of the types of sources/root causes. For instance, a memory array that has not been reset or assigned values may be intended. It may be the address that is incorrectly pointing to the uninitialized array. Tracing to that array to understand the address logic is still key. With this stated, is there a way to automate the tracing of Xs to the root causes and once the root cause is determined, also provide the classification or reason for those Xs? Such automation would save a significant amount of engineering effort to enable the user to work more efficiently.
Synopsys Verdi’s XRCA Component
The Synopsys Verdi Regression Debug Automation's XRCA component is one of the most advanced root cause analysis tools that does just that. XRCA is the industry's leading X tracing and root cause analysis engine. XRCA not only automatically scans X signals in an FSDB and traces the X signals to the root causes, but it also handles large amounts of X signals in batch to reduce debugging time. Additionally, it generates a well-categorized report for the root causes and classifications. The reports are loaded in the RCA Manager in Synopsys Verdi to observe the results and the tracing paths.
XRCA is the best tool for debugging X signals at the bring up of gate level simulations and X signal debugging from regressions. XRCA also supports gate level netlist tracing, RTL level tracing, Synopsys VCS X-propagation tracing, X from Low Power components, and X-pessimism detection in addition to many other root cause classifications.
To learn more about Next-Generation Verdi and all its debug technologies, visit www.synopsys.com/debug
Continue Reading
