Are Designers’ X-Analysis Needs Different From Verification Engineers?

The propagation of unknown (X) states has become a more pressing issue with the move toward billion-gate SoC designs. Besides the sheer complexity of these designs, the common use of complex power management schemes increase the likelihood of an unknown ‘X’ state in the design translating into a functional bug in the final chip.

This article describes a methodology that enables design and verification engineers to focus on the X states that represent a real risk, and to set aside those which are artifacts of the design process.  The benefits are to reduce project time, particularly that spent in simulation, and with reset optimization to reduce routing and power requirements.

X Proliferation

Billion gate designs have millions of flip flops to initialize. Many of the IP blocks used in such designs also have their own initialization schemes.

It is neither practical nor desirable to wire a reset signal to every single flop. It makes more sense to route resets to an optimal minimum set of flops, and initialize the rest through the logic, but this is a significant RTL coding challenge.

The analysis of any system with such a reset and initialization scheme is bound to throw up many Xs. The issue is in knowing which ones matter, since dealing with unnecessary Xs wastes time and resources. However, missing an X state that does matter can increase the likelihood of late-stage debug, cause insidious functional failures and ultimately, respins.

Today’s power schemes further complicate the analysis of X issues. Blocks that are subject to power management have additional flops to retain state across power-state transitions, and any analysis of their reset structures must be undertaken dynamically. Interaction between blocks in different power states must also be considered.

Two simulation phenomena work against us in this respect.

X-optimism is primarily associated with RTL simulation, and is caused by the limitations of HDL simulation semantics. It occurs when a simulator converts an X state into a 0 or a 1, creating the risk that an X causes a functional failure to be missed in RTL simulation.

X-pessimism is primarily associated with gate-level simulation of netlists (though it can also occur in RTL simulation). As its name suggests, it happens when legitimate 0s or 1s are converted into an X state. This can lead to precious debug resources being directed toward unnecessary effort. Additionally, after synthesis has done its work, debug at the gate level is more challenging than in RTL.

Methodology Principles

Any methodology to handle X issues efficiently must focus on solving the problem in RTL, using tools and methodologies that can be applied to RTL simulation. Gate-level simulation is slow and will tend toward X-pessimism. Any real bugs uncovered at the gate level will be more difficult and time-consuming to fix than in RTL.

Assuming a focus on RTL, the next desirable feature of the methodology would be that it addresses the different skills and requirements of design versus verification engineers.

Real Intent has discussed X issues with customers and while both types of engineer share the same overall concerns – avoiding X-propagated functional bugs and catching them as early as possible – they have different perspectives.

Many design engineers now work with strict guidelines aimed at achieving X-accurate coding. This is a delicate task that requires further automation, but it can catch a good number of X issues early. The designer’s priority is to know where the X-prone regions of the RTL may be.

In contrast, a verification engineer typically thinks about controlling the amounts of X-optimism and X-pessimism at each stage of the verification flow.

Finally, the methodology needs to accept that there is no single practical technology that will deliver the quickest and most accurate X-analysis in all cases. For example, formal analysis techniques such as model checking and symbolic simulation can be a big help, but they face capacity challenges (such as memory usage).

A successful methodology to handle X propagation must therefore combine several techniques, balanced to deliver thorough results in the best available turnaround time.

Methodology

 Figure 1 shows the methodology Real Intent has developed based on our Ascent XV tool suite.

The methodology tries to capture relevant X issues as early as possible in the design flow, and has separate phases that are design-centric and verification-centric.

Design-centric flow

The first thing a designer wants is to minimize the number of X-sources that exist. The methodology first identifies where Xs might originate. Appropriate structural analysis looks at the characteristics of the RTL to identify potential sources. Lint tools can flag hazards such as explicit X-assignments, signals within a block that are used but not driven, out of range assignments, and flops that don’t have a reset signal, to name a few.

However, structural analysis cannot determine whether a real X-issue exists, and does not include any sequential analysis. The Ascent XV methodology uses sequential formal analysis to determine the baseline list of uninitialized flops, and then suggests additional flops, that if reset, would lead to complete initialization.

The creation of the hazard report is therefore augmented by using formal techniques to result in a more precise list. The designer can then manage and respond to this list as appropriate.

Designers also want to identify which X-sources can propagate to X-sensitive constructs.This portion of the flow uses automation to trace X-source propagation through X-sensitive constructs. It then presents the results in a hazard report, which is focused on relevant constructs using a number of static techniques in the simulation context.

Verification-centric flow

Customer conversations revealed that verification engineers tend to focus on X-optimism and X-pessimism in their efforts to manage X-propagation.

In the Ascent XV methodology, X-accurate modeling is used to address both, and existing simulation checkers then help to detect functional issues. This is done in a way that does not touch the user’s code and is easily integrated.  The performance overhead of the X-accurate simulation is strictly controlled.

Once an issue is discovered, the verification engineer needs further information to isolate the cause. For this, it is useful to know which signals were sensitive to X-optimism and which control signals had Xs.

The methodology uses the simulator’s assertion counters to track statistics for these signals. Monitors can then print a message the first time a signal is flagged as sensitive to X-optimism, which is useful for determining its root cause.

An important constraint here, though, is that the monitor does not slow simulation to a crawl by offering a print every time a flag is raised. The aim is to provide a readout so that the verification engineer knows where to use waveform analysis and trace a signal back to its source.

This X-accurate modeling can be used at both the RTL and netlist levels though, again, the emphasis is on undertaking appropriate simulation at as high a level as possible.

Conclusion

Pragmatism and balance is as important as the power of the technologies used in addressing X-propagation in today’s complex designs.

The methodology outlined here targets a specific but important problem. It aims to ensure, through its use of tools such as Ascent XV, that design and verification engineers can focus their resources on avoiding and fixing bugs, minimizing design turnaround time.

Further information

A more detailed discussion of the Real Intent methodology discussed here and the various technologies available to combat X-propagation can be found here.

There’s more on Real Intent’s Ascent XV X design and verification system here.