X-optimism occurs when an unknown X value is incorrectly resolved to a known value in RTL simulation. Optimism issues can be 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, many clock cycles after the optimism. X-optimism issues also show up in a gate-level netlist or FPGA-based prototypes, but debug is difficult due to limited visibility in FPGAs, and netlist designs are less familiar post-synthesis. Trying to find an X-optimism bug in an FPGA model 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 prior to simulation, ensuring efficient and accurate simulations. Fixing optimism issues in RTL streamlines getting netlist simulations or FPGA-based prototypes, up and running faster and reduces costly iterations.
X’s can 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 the example shown in figure 1 below. If the “input” signal is an X value, this means that “input” could 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 value. However, in simulation, the output “D” would always show as a 1 value. It is called “optimism” because the unknown was resolved as a known value. This can cause functional bugs to be missed in RTL simulations, though in netlist the X would always be properly propagated.
Ascent XV-RTL Optimism Static Analysis
Ascent XV provides a totally static solution that is used prior to RTL simulation to ensure that simulation is free of X-optimism issues that cause inaccurate simulation. It is also used to monitor or model potential optimism points in simulation should you choose not to fix the issues. 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, versus all constructs in the design. Figure 2 below shows the flow, with the tasks done by Ascent XV on the left, outputs in the middle, and user actions on the right.
The first step of the flow is to read in the design and specify the clocks and resets. Reset 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 an accurate reset analysis.
To analyze X-optimism, you must first identify all X-sources that cause X-optimism. Next, trace where those X-sources can propagate and cause X-optimism issues. The third step is the reporting of the results in a complete and concise manner to enable fixing the issues. Once the analysis is complete, you can also choose to use SimPortal.
Minimizing X-sources is key to eliminating X-optimism issues. Structural analysis ensures that all potential sources of X’s are included. The built-in formal analysis minimizes noise and ensures accuracy. X-sources identified by structural analysis include such things as unconnected module input ports, bus contention, operations with an unknown result like reading from a non-existent RAM address, and out of range 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 minimizes noise by accurately modeling what happens in real hardware, thereby minimizing uninitialized flops and latches as X-sources.
X-propagation analysis traces where the X-sources can propagate. Ascent XV will trace the propagation of each X-source through the design, noting where it can cause X-optimism and what signals might exhibit optimistic values.
Ascent XV’s reporting of X-optimism is designed to be concise and to guide the user through understanding first where the X-sources in the design are, and secondly where they can propagate. This enables first eliminating as many X-sources as possible, and then managing the remaining X-propagation issues. Also, Ascent XV has automatic waivers that reduce noise.
The first section of the report shows the results of the X-source analysis, and for each X-source a summary of the propagation analysis. 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 did not occur.
Once as many X-sources are eliminated as is practical, review of the X-propagation analysis section is needed. This section 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 groups both the signals that might have X-optimistic values together with the control signals to which an X can propagate and cause the optimism. Only those constructs to which an X can propagate are analyzed, and only the control signals to which an X can propagate are listed. The presentation of information helps to 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, either from an asynchronous reset, a synchronous reset, or via data propagation of known values. The reset section also shows the initialized value and time of initialization based on the clock specifications.
Once the X-optimism analysis is complete, Ascent XV can generate SimPortal files to address unresolved issues. SimPortal files 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 example is to monitor whether inputs to the device have X’s, and also to report when an output has an X. Another type of checker will check that X’s do not occur on clocks and resets, as this can also cause optimism.
Ascent XV- RTL Optimism uses static analysis to eliminate X-optimism issues before you get to simulation, so simulations can run faster with X-accuracy. Its hardware accurate reset analysis uncovers where X’s exist after initialization, and ensures accurate analysis of potential X-propagation. Noise reduction techniques that have improved over 5 years of usage result in precise, compact, and non-redundant reporting of potential X-optimism. The prioritization of X’s that need to be eliminated, reset optimization to ensure that there are no uninitialized flops that can drive control logic, and the 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 proven 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. Ascent XV can be used to eliminate X-sources in the design, identify where those X’s 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.