Low Power Verification – “X” Marks the Spot

Understanding X values can mean the difference between a working chip and a functional disaster.

popularity

Welcome to a new discussion on a range of topics we think will be interesting to folks who design and verify SoCs. Though the name of this blog denotes two top attributes of SoCs—IP implementation and the pervasive need for low power (LP), we certainly may go far beyond the scope of these topics in upcoming posts. We’ll start with a topic on the LP side, and going forward we’ll alternate with IP. We also will regularly bring in guest bloggers from a wide range of backgrounds and responsibilities, and we hope you’ll find our discussions useful and engaging.

Today I’d like to talk about the crucial role Xs play in low-power verification. Unless all the verification tools in low-power flows can accurately simulate, track and debug Xs, there is a real risk of either not catching subtle low-power bugs until very late, during expensive gate-level simulation, or not at all, causing disastrous functional product failures. Conversely, competent handling of X values throughout low power flows provides huge value to designers and verification engineers, as X values provide deep insight into and validation of power management intent, implementation and behavior.

synopsys1
Figure 1. From “Can You Tell Your ISO from LS? – A Methodology for Low Power Debug”

First, I’ll cover some basic terminology.

– X values – In this context, the representation of indeterminate output values when voltage-aware native low-power simulation corrupts outputs of blocks during reset, shutdown, and when voltage levels fall outside defined thresholds (for DVFS for example).
– X-propagation – In RTL simulation, this relates to the nature of how simulators treat unknowns, and whether the determination is optimistic (converts an X on input to a 0 or 1) or pessimistic (X on input propagates to output). See http://www.sutherland-hdl.com/papers/2013-DVCon_In-love-with-my-X_paper.pdf. Advanced simulators such as VCS with X-Prop provide extensions to Verilog and VHDL to provide accurate modeling and fine control of X propagation, enabling accurate correlation to actual design behavior.
Effective and useful low-power SoC verification must accurately simulate the behavior of advanced low-power design techniques in RTL. This requires four key technologies:

  1. Accurate and complete inference of low-power design intent expressed in IEEE1801 (UPF).
  2. Voltage-level awareness to enable accurate simulation of advanced low-power design techniques, including shutdown, DVFS/AVFS and multi-rail macros.
  3. Low-power simulation-optimized X-propagation features to enable Xs generated by low-power simulation to propagate to outputs, but intelligently block functional Xs that are properly gated by inferred isolation logic.
  4. Low-power debug needs to accurately understand the source of Xs, and in the case of Xs generated by low power simulation, provide easy and effective means to trace back to root cause.

The first capability is required to manage the enormous complexity of low-power design intent for IP-based SoC designs. The second enables SoC designs incorporating fine-grained voltage control-based LP techniques to be simulated accurately at RTL, avoiding expensive and late RTL simulation, and in some cases simulated accurately at all. The third topic is the focus of this discussion: Advanced voltage-level aware native low power simulation must work together seamlessly with simulation with advanced X-propagation. VCS® Native Low Power (NLP) and VCS X-Prop offer this level of integration. The following example shows how these features work in concert to uniquely identify and analyze an LP bug, and with Verdi Power-Aware, find the root cause of such bugs.

Synopsys2
Figure 2.

The figure above shows a simple example of optimistic Verilog X propagation semantics masking a serious missing isolation policy low-power bug. Assuming that we have a design with two communicating power domains, they must be interconnected through isolation cells to ensure valid behavior. This isolation strategy and the valid power states are specified in the UPF power intent. If an isolation cell was missing for some reason, then X values from shut-down downstream OFF power domain 1 may appear at the inputs of ON power domain 2. Verilog RTL semantics optimistically could mask this X by converting the output of power domain 2 to a “1”. Because the X value from low-power simulation correctly corrupting the output of power domain 1 is masked, the missing isolation policy bug can’t be seen during RTL simulation, and may only appear during X-pessimistic low power gate level Verilog simulation.

Synopsys3
Figure 3.

Figure 3 shows using VCS native low power simulation (NLP) with VCS X-Prop capability accurately propagates the X corruption value to the outputs of power domain 2, and ultimately to primary outputs. Notice also that the X corruption value on the lower output of power domain 1 does NOT propagate to the other output of power domain 2. This is because VCS’s native low power and X-propagation technologies understand power intent, and intelligently propagate the valid isolation value from the inferred isolation cell.

The fourth key technology required for effective low power verification is optimized low power debug. Given that low power simulation found and propagated an X value due to a low power bug, how can you find out what’s going on? In traditional RTL simulation, an X value can be very unhelpful, but in low power verification, X is a critical piece of information. Low-power optimized debug such as Verdi® Power Aware debug can rapidly trace Xs back to the exact point of the simulation mismatch, as in figure 4 below, then trace the signal to the origin of the X on the actual schematic, and even cross-correlate to the RTL source and to the UPF low power intent, as in figure 5.

Synopsys4

Figure 4.

synopsys5

Figure 5.

What we’re talking about today doesn’t come close to covering all of the interesting and important aspects of why low-power verification requires advanced X-propagation technologies. For more information, please stay tuned for and see .

Finally, let us know your thoughts in the comments, and see you next time!