How to expose X-optimism issues in ASIC and FPGA design

By Lisa Piper |  No Comments  |  Posted: February 29, 2016
Topics/Categories: EDA - Verification  |  Tags: , , , , ,  | Organizations:

Static analysis offers a powerful way of identifying potential X-optimism problems before simulation. The article defines the issue and describes an established solution.

X-optimism occurs when an unknown X value is incorrectly resolved to a known value in RTL simulation. Optimism is difficult to detect and debug because the X is no longer visible once the optimism occurs. The functional issue may not show up at an output for many clock cycles after the optimism.

X-optimism issues can also show up in a gate-level netlist or FPGA-based prototype, but debug is difficult in FPGAs, and netlist designs are less familiar post-synthesis. Trying to find an X-optimism bug in an FPGA model really is like looking for a needle in a haystack due to limited visibility. In netlist simulations the design hierarchy is flattened, signal names changed, and there is a danger that the X under consideration will be mistaken for a pessimistic node and forced to a known value that hides a functional issue.

Real Intent’s Ascent XV uses static analysis to identify potential X-optimism issues at RTL so they can be fixed before simulation, ensuring efficient and accurate runs. Fixing optimism in RTL streamlines the process of getting netlist simulations or FPGA-based prototypes up and running and reduces costly iterations.

X-optimism defined

How do Xs cause X-optimism in RTL simulations? X-optimism occurs when an unknown value is simulated as though it is a known value in hardware.

Consider Figure 1. If the ‘input’ signal is an X value, this means it can be either a 0 or a 1 value in real hardware (because real hardware cannot have a X value). So in real hardware, signal ‘D’ might also be a 0 or a 1. However in simulation, ‘D’ will always show as a 1. We call this ‘optimism’ because the unknown gets resolved as a known value. This can cause functional bugs to be missed in RTL simulations, though in a netlist the X will be properly propagated.

Figure 1. X-optimism example (Real Intent)

Figure 1. X-optimism example (Real Intent)

Ascent XV-RTL optimism static analysis

Real Intent’s Ascent XV is a totally static solution used before RTL simulation to ensure that a design is free of X-optimism issues that could generate inaccuracies. It is also used to monitor or model potential optimism points in simulation should you choose not to fix the issues when they are first flagged.

The advantage of the Ascent XV approach is that the static analysis identifies the select few constructs that need to be monitored or modeled for X-accuracy, rather than wasting time addressing all constructs in the design. Figure 2 below shows the Ascent XV flow. Tasks done by Ascent XV are on the left, outputs in the middle, and user actions on the right.

Figure 2. Ascent XV Optimism Flow (Real Intent)

Figure 2. Ascent XV Optimism Flow (Real Intent)

The first step in the flow is to read in the design and specify the clocks and resets. Resets and clocks are used to determine X-sources from uninitialized flops and latches. Ascent XV will automatically generate this design-specific specification. Ascent XV supports complex reset scenarios, such as phased resets. Clocks can also be configured for a delayed start. Support of complex reset scenarios is key to accurate reset analysis.

To analyze X-optimism, you must first identify all the potential X-sources. Next, you must trace where those X-sources can propagate and cause X-optimism issues. Then, the third step is to generate a complete and concise report of the results so that you can fix any issues. Once that analysis is complete, you can also choose to use the SimPortal feature (this is explained in more detail below).

X-source analysis

Minimizing its possible sources is fundamental to eliminating X-optimism. Structural analysis ensures that all potential sources of Xs are included. Built-in formal analysis minimizes noise and ensures accuracy.

X-sources identified by structural analysis include such frequently troublesome elements as unconnected module input ports, bus contention, operations with unknown results (like reading from a non-existent RAM address), and out-of0range bit selects and array indices. Formal analysis is then used to identify uninitialized flops and latches in the design, taking into account the design resets and the propagation of known values. Reset analysis counters noise by accurately modeling what will happen in real hardware, thereby minimizing the number of uninitialized flops and latches that can become X-sources.

X-propagation analysis

X-propagation analysis traces where the X-sources can propagate. Ascent XV traces the propagation of each X-source through the design, noting where it can cause X-optimism and what signals might exhibit optimistic values.

X-optimism reporting

Ascent XV’s reporting of X-optimism is designed to be concise, guiding the user through an understanding where the X-sources in the design are and, then, where they can propagate. This allows the designer to eliminate as many X-sources as possible, and better manage remaining X-propagation issues. In addition, Ascent XV has automatic waivers that reduce noise.

The first section of an Ascent XV report shows the results of the X-source analysis, and a summary of the propagation analysis for each X-source. The X-source section identifies the type of X-sources. X-sources are prioritized and sometimes automatically waived based on the propagation analysis. A VCD waveform trace can be viewed that shows the initialization process. This can be very useful for determining why initialization has not occurred.

Once as many X-sources have been eliminated as is practical, the subsequent X-propagation analysis section needs to be analyzed. This shows where X-optimism can potentially occur so it can be addressed either via X-accurate coding or SimPortal monitoring and modeling.

Constructs with X-accurate coding can be automatically waived to minimize unnecessary analysis. The reporting of X-propagation collects both the signals that might have X-optimistic values and the control signals to which an X can propagate and cause optimism. Only constructs to which an X can propagate are analyzed, and only control signals to which an X can propagate are listed. Presenting the information like this helps the user determine whether it is best to code for X-accuracy or simply monitor.

A third section of the report provides reset analysis information, indicating how initialized flops became initialized (causes include an asynchronous reset, a synchronous reset, or data propagation of known values). The reset section also shows the initialized value and time of initialization based on the clock specifications.

SimPortal simulation

Once the X-optimism analysis is complete, Ascent XV can generate SimPortal files to address unresolved issues. These are side files that are integrated into an existing simulation environment. Ascent XV’s SimPortal simulation add-ons allow for selective dynamic monitoring and/or automatic X-accurate correction during RTL simulation. The most common use-case monitors whether inputs to the device have Xs, and also reports when an output has an X. Another type of checker can determine that Xs do not occur on clocks and resets, another cause of X-optimism.


Ascent XV- RTL Optimism uses static analysis to eliminate X-optimism issues before you enter simulation, so it can be run faster with X-accuracy. Its hardware-accurate reset analysis uncovers where Xs exist after initialization, and ensures accurate analysis of potential X-propagation.

Noise reduction techniques that have been progressively refined during five years of the tool’s use result in precise, compact, and non-redundant reporting of potential X-optimism.

Features such as the prioritization of Xs that need to be eliminated; reset optimization to ensure that there are no uninitialized flops that can drive control logic; and root cause analysis of each optimism point, together streamline debug to eliminate potential X-optimism issues before handing off the RTL.

Ascent XV-RTL Optimism has been shown to catch missed X-optimism issues in real designs, and is much more efficient than a later debug of issues in hardware or in netlist simulations. It can be used to eliminate X-sources in the design, identify where those Xs create an optimism risk, and can correct pessimism at the netlist. Ascent XV is a total X-Verification solution that leverages static analysis to ensure efficient and accurate simulations.

About the author

Lisa Piper is senior manager of technical marketing at Real Intent.

Also check out the preview for Real Intent’s activities at DVCon in San Jose this week.

Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors