Fix X-pessimism in netlists with practical techniques

Most functional verification is done before the RTL is handed off for digital synthesis. Gate-level simulations take longer and are hard to debug, but still needed to verify some circuit behavior. Ideally, the output of the RTL simulation will match the output of gate-level netlist simulation after synthesis. But that is not typically the case. Besides the obvious things verified in your gate-level simulations, there are always unknown values (Xs). Some will not be seen in the RTL due to X-optimism, but there will be additional Xs in the gate-level simulations due to X-pessimism.

X-optimism in RTL and other generic issues around unknown states are discussed in more detail in the paper ‘X-Propagation Woes – A Condensed Primer‘. Some basic familiarity with the concept is assumed here.

This paper focuses on X-pessimism at the netlist level. It discusses some current techniques and their limitations, and then describes a more efficient X-pessimism strategy based on Real Intent’s Ascent XV.

What is X-pessimism?

X-pessimism occurs in gate-level designs when an X signal at the input of some digital logic causes the simulation output to be an unknown value, even though in real hardware the value will be deterministic (i.e., 1 or 0). X-pessimism makes it hard to get netlist simulations up and running quickly.

Figure 1 shows a simple example. When the values of in1 and in2 are both 0, the simulation value at the output is 0, as would happen in hardware. But when the ‘input’ value is an unknown X, and the values of in1 and in2 are both 1, the simulation value at the output is X in simulation but is 1 in real hardware. Specifically, we say it is 1-pessimistic because the output should have been a value of 1 (as the example suggests, ‘0-pessimistic’ is also possible).

Figure 1: X-pessimism where an X results when the values of in1 and in2 are both 1 (Real Intent)

Unlike Figure 1, the logic cone of the cloud in real designs is often very complex. The selected output can be driven by a logic expression and the input can also be a logic expression. In such cases, the output X value is sometimes a result of pessimism but at others simply the propagation of an X that was optimistic in RTL. One can be artificially corrected without harm, but the other could be a major bug. Refer to “X-Propagation Woes – A Condensed Primer”² for more details.

Common ‘quick fixes’

Three techniques are frequently used to address X-pessimism:

1. Eliminate all Xs.
2. Perform artificial random initialization of uninitialized flops.
3. Manual analysis.

All have major drawbacks. Let’s take a more detailed look at each.

The first step toward eliminating all Xs is to add a reset to all memory elements. This gets rid of the most common source of Xs: uninitialized flops. However, synchronous resets can lead to pessimism issues being introduced during synthesis. Also, there are other significant X-sources this does not address. These include explicit X-assigns for flagging illegal states, bus contention, and out-of-range references.

But the greater issue with eliminating all Xs is that the necessary resets eat into power, size, and routing budgets. Resettable flops are larger, consume more power, and require additional routing resources. The technique is practical only for smaller designs.

The second approach artificially randomizes the initialization of uninitialized memory elements at time 0. This helps in simulation but does not necessarily match real hardware. It also, again, does not address all X-sources. X-optimism bugs that were masked in RTL will probably be artificially masked again in the netlist simulation. Missing such a bug can lead to very expensive late-stage repair.

The third approach is to manually analyze the root cause of all X-differences between the outputs of the RTL and gate-level simulations, determine the correct values and time, and then force and release pessimistic nodes. This can be difficult.

A gate-level realization transforms RTL into something that is more complex, has a different structure, and has unfamiliar signal names. It takes a lot of time to chase down pessimistic Xs in netlist simulations, particularly where there is a mixture of Xs attributable to either optimism or pessimism – and you do not initially know which. The process can take months for large designs and even then it is easy to overlook bugs because of deadline pressures.

In summary, these established approaches do not address pessimism caused by Xs from all sources. They mask issues in the gate-level simulations due to X-optimism in RTL simulations. They cannot handle larger SoC designs.

Ascent XV–Netlist

If a node is determined to be 1- (or 0-) pessimistic, that means its real circuit value is 1 (or 0) but simulation will produce an X. A pessimistic simulation value can be corrected by forcing a 1 (or 0) on the node until the conditions for pessimism no longer hold – that is, the node represents the deterministic value real hardware would see. After forcing, the node must be immediately released.

But not all Xs should be arbitrarily forced to a known value, only those that result from pessimism.

Ascent XV-Netlist from Real Intent makes your gate-level simulation hardware-accurate by correcting pessimism as appropriate. It statically identifies potentially pessimistic nodes, then uses that information to create SimPortal files that augment the simulation to correct X-pessimism on-the-fly.

Undertaking static analysis before simulation significantly reduces the number of nodes that must be analyzed during simulation itself. Also, X-analysis during simulation can be reduced to a table look-up when the potentially pessimistic node has an X-value. The SimPortal files monitor potentially pessimistic nodes in the design as you go, independent of the testbench.

A bottom-up hierarchical static analysis can also be done at the block level. When all the blocks are integrated for full-chip simulation, this proves a very scalable approach. The SimPortal has been designed to minimize compile time and memory overhead. You can control the verbosity at simulation time, and choose to drop back to simple monitoring or even turn off both correction and monitoring at any point in time.

The Ascent XV X-pessimism flow and methodology has two main components and is shown graphically in Figure 2.

1. Run static analysis to determine which data input values can cause monitored nodes to exhibit pessimism. Generate design-specific SimPortal data files.
2. Run SimPortal simulation to find out which nodes experienced the input combinations that cause pessimism.

Figure 2: Ascent XV X-Pessimism Flow and Methodology (Real Intent)

This methodology takes another complex issue out of fixing X-pessimism. In RTL, Xs can hide functional bugs due to X-optimism. These bugs will be brought to light in netlist gate simulations. Unfortunately because Xs also cause X-pessimism in netlist simulations, you then need the time and insights to determine whether a mismatch is due to X-optimism, X-pessimism, or something else.

Ascent XV-Netlist eliminates Xs caused by X-pessimism, removing the major source of simulation RTL and netlist simulation differences and thereby the need for manual analysis and filtering.

A full breakdown of Ascent XV’s features and advantages is shown in Figure 3.

Figure 3: The Ascent XV solution (Real Intent)

Summary

Xs exist in all designs and it is difficult to prevent them occurring for practical reasons. Simulation results may differ because of Xs hidden in the RTL simulation by X-optimism, or present in gate-level simulation due to X-pessimism.

Pessimism can be fixed by overriding the simulator because you know that real hardware will always resolve to a deterministic value. The challenge is confirming that an X value is a result of X-pessimism and not simply X-propagation. Only then can you force it to the right value at the right point in time so that the simulation matches that for real hardware.

Ascent XV-Netlist Pessimism corrects X-pessimism on-the-fly so the simulation is hardware accurate. Ascent XV cuts the time required to get gate-level simulations started by an order of magnitude. Its ease-of-use and capacity, make it the only practical solution for large SOCs.

Author

Lisa Piper is Senior Manager of Technical Marketing at Real Intent.