Because X doesn’t always mark the exact spot

Digital hardware has a habit of deciding – based on the bias and behavior of transistors – to drive outputs to a 0, or a 1, or if commanded a high-impedance Z state. SystemVerilog recognizes a fourth state: X, the “unknown” state a simulator has trouble inferring.

Simulators have a choice. Under X-optimism, they can convert the unknown X to a known 0 or 1 based on either a coding construct or using some heuristic. The next stage sees only a resolved output, correct or not, and runs with the result for better or worse. Alternatively, the simulator can choose to propagate the X, but that leads to X-pessimism where more X values show up unnecessarily and the problem cascades out of control.

Several common sources lead to X values in a simulation. There are uninitialized flip-flops and latches, bad re-initialization exiting a low power mode, explicit assignments gone haywire, and a whole host of more hardware-centric issues like bus contention and signal opens. On top of being difficult to simulate, X-propagation also makes debug difficult, because an observed error often is sourced several stages of logic away and multiple clock cycles earlier.

Both X-optimism and X-pessimism are problematic and can cause simulation to either miss a real issue, or unleash an artificial set of unresolved issues which must be hunted down. In recent years, SemiWiki readers have heard from Real Intent, Jasper Design Automation, and Tachyon Design Automation regarding their X-propagation tools and ways to mitigate X-issues.

The paper from Real Intent eloquently describes a simple-sounding yet difficult to achieve objective: “Ideally, the coding should be X-accurate, meaning that it should correct for X-optimism by propagating the X value, but without X-pessimism.” As that paper continues, achieving X-accurate code looks easy until the number of paths in the control-flow graph increases, requiring a level of automation with reporting and code generation to implement mitigation.

On that backdrop, Aldec ups the stakes in the X fray with two observations: X values are very likely to exist somewhere in a design despite best efforts in code automation, and tracking them down should be a lot easier than pawing through waveform diagrams. The new release of Riviera-PRO 2013.10 adds a visual X-issue debugging component to its suite of capabilities including X-aware code reviews, X-assertion checks, and X-aware RTL and gate-level simulation.

The Cause Finder tool is based on the idea that X doesn’t always mark the exact spot where the problem started, and helps trace back the X-propagation to the possible source by traversing the design logic back in time.

Cause Finder is integrated into the Riviera-PRO suit and accessible from Dataflow and other windows, and is enabled with cross-probing to other debugging views. This helps users target the debugger to the source of the X, with breakpoints and watches to see the point in code where the problem started.

Rather than deploy complex tools to try to automate out X-issues in code, requiring an entire code based to be analyzed and refactored in problem areas, Aldec has taken a simple yet effective visual approach to help isolate them in SystemVerilog code quickly. For more on the latest release of Riviera-PRO 2013.10 including Cause Finder and its other capabilities, visit:

AldecRiviera-PRO Advanced Verification Platform

More articles by Don Dingee…

lang: en_US