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.