Lisa Piper, Senior Technical Marketing Manager at Real Intent
Lisa Piper is currently a Senior Technical Marketing Manager at Real Intent. She has extensive experience in simulation-based verification, acceleration and formal verification. Prior to Real Intent, Lisa worked at Lucent Microelectronics and AT&T Bell Labs. She has a BSEE from Purdue … More »
Correcting Pessimism without Optimism – Part One
September 24th, 2015 by Lisa Piper, Senior Technical Marketing Manager at Real Intent
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis because gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Ideally, the output of the RTL simulations will match the output of gate-level netlist simulations on the same design after synthesis. And why wouldn’t they? Besides the obvious things that are being verified in your gate-level simulations, there are also unknown values (X’s) that were not seen in RTL due to X-optimism, and additional X’s in the gate-level simulations due to X-pessimism. Part one of this article focuses on the issues of X-pessimism at the netlist level and why the current solutions are inadequate.
X-pessimism and X-optimism Defined
The presence of X’s can cause both X-optimism in RTL simulations and X-pessimism in netlist simulations. X-optimism can result in the failure to detect functional bugs at RTL. X-pessimism typically makes it hard to get netlist simulations up and running quickly.
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 X value, even though in real hardware the value will be deterministic, e.g., a 1 or 0. Figure 1 shows a very simple example. When the value of in1 and in2 are both 0, the simulation value at the output is 0, as it would in hardware. But when the “input” value is an 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. This behavior is called X-pessimism because the known value simulates as an unknown. More specifically, we say it is 1-pessimistic because the output should have been a value of 1.
X-optimism is the opposite, when an unknown value is simulated as if it is a known value in hardware. Consider the example shown in figure 2 below. If the “input” signal is an X value, that means that “input” could be either a 0 or a 1 value in real hardware because real hardware does not have an 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, although in netlist the X would always be properly propagated.
The examples above are very simplistic. In real designs the logic cone of the “cloud” is often very complex, with the selected output being driven by a logic expression and the “input” also being a logic expression. In this case, sometimes the output X value is a result of pessimism and sometimes it is simply the propagation of an X that was optimistic in RTL. One can be artificially corrected without harm, but the other could be a bug lurking to be discovered. Refer to “X-Propagation Woes – A Condensed Primer” for more details.
Commonly Used Quick Fixes
There are three approaches that we hear being used for addressing X-pessimism, all with downsides. The approaches are 1) eliminating all X’s in the design, 2) artificial random initialization of uninitialized flops, and 3) manual drudgery.
The first common approach for eliminating all X’s is to add a reset to all memory elements. This eliminates the most common source of Xs – uninitialized flops. However, synchronous resets sometimes can cause pessimism issues to be introduced during the synthesis process. Also, other sources of X’s do exist in a design, such as explicit X-assigns for flagging illegal states, bus contention, and out of range references, among others. A more significant issue is that extra resets eat into power, size, and routing budgets. Resettable flops are larger, more power hungry, and require additional routing resources. Resetting all flops is practical only for smaller designs, and does not address all sources of X.
The second common approach is to artificially randomize the initialization of uninitialized memory elements at time 0. The issue with this approach is that while it will help simulations, it will not necessarily match real hardware. It also does not address all sources of X in a design. X-optimism bugs that were masked in RTL likely will be artificially masked again in netlist simulations. This risk of missing a bug that was masked by optimism in RTL and artificially removed at netlist could result in a critical bug being missed. These days, with the high costs of manufacturing and – heaven forbid – recalls, the downside for a failure can be very expensive.
The third approach is to manually analyze the root cause of all X-differences between the outputs of RTL and gate-level simulation, and then determine the correct value and time to force and release pessimistic nodes. This can be very difficult to do because a gate-level design is a transformation of an RTL design into something that is more complex, has a different structure, and has unfamiliar signal names. It can be very time consuming to chase down those pessimistic X’s in the netlist simulation. The issue is exacerbated when there is a mixture of X differences from both optimism and pessimism, with pressure to get it fixed as soon as possible and not accidently miss a real bug. For large designs, this effort can take months.
Existing approaches fall short because they do not address pessimism caused by X’s from all sources, they can mask issues in the gate-level simulations due to X-optimism in RTL simulations, and they are insufficient to handle the largest SoC designs.
In part two we will look at how the Ascent XV tool correctly addresses X-safe verification.
2 Responses to “Correcting Pessimism without Optimism – Part One”