Billion-Gate Signoff

At last year’s Design and Verification Conference in San Jose, Real Intent had a tutorial session on “Pre-Simulation Verification for RTL Sign-Off.” This was a start of conversation in the industry that we have seen grow through DAC 2013 in Austin, and which is getting louder each day. Verification companies are now talking about crossing the billion-gate threshold and what can be done to not only control this explosion of complexity, but also to achieve signoff for RTL code.

RTL and gate-level simulation theoretically can be used to fully test a billion-gate SoC, but the cost of complete RTL testing is beyond what design teams can afford. To reduce the testing cost and the risk of missing critical tests, abstract modeling and pre-simulation static analysis of RTL have now become imperative in SoC design flows. Integration of heterogeneous IP and design units require confirmation of protocols, power budgets, testability and the correct operation of multiple interfaces and clock domain crossings (CDC).
A verification company might be tempted to promote a list of requirements for SoC sign-off that just focuses on its offerings. A better approach would be to look at what is going outside their organization to see what the design industry’s best practices are.

At DVCon, we presented a comprehensive list of sign-off activities in conjunction with Calypto Design Systems, and DeFacto Technologies. Not all activities would be universally accepted by all design teams. However, each step represents a substantial hardening of the design and is best served by a top-of-the-line tool designed specifically for that step. For CDC analysis, this is a definite must-have since those kind of failures do cause expensive response.

Recommended signoff activity list:

• Syntax and semantic checking with Lint that covers loop detection, FSM, low-power, and mixed-language issues;
• Automatic formal analysis to verify design functional intent;
• Reset flop analysis and later optimizations to reduce the number of required flops;
• Timing constraints (SDC) correctness and consistency verification, especially after RTL changes from power and clock-gating optimizations and top-level integration of IP;
• CDC sign-off flow using formal and structural methods;
• Testability sign-off, DFT verification and planning, and proper DFT implementation;
• Correct X-hygiene in preparation for simulation including optimism/pessimism correction, and
• Power estimation and optimization.

Let’s look at these in more detail and discuss their importance to sign off.

Modern Lint tools have evolved to the point where they can handle full-chip designs and yet still offer concise hierarchical reporting. The availability of low-noise reporting means less time waiving violations and more time cleaning easy-to-fix issues. Because of the lower-noise, designers can use the tool earlier and more often. However, an RTL Lint tool requires only rule-setup and therefore cannot provide a deep analysis.
Automatic formal RTL analysis builds on Lint cleaning for early detection of functional issues and takes advantage of clock definitions for the design. Because automated formal performs a sequential analysis and does constant propagation, it can do a deeper design exploration to uncover potential problems. Formal analysis can eliminate potential failures reported in Lint. Designers benefit from early static analysis of problems such as potential FSM deadlocks, bus issues and even X-value propagation.

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.

Flip-flop reset analysis ensures that the SoC design will come in a known good state, and in later iterations of the design it may be used to save chip area and routing resources through a more intelligent application of reset signals. The analysis of any system with such a reset and initialization scheme is bound to identify many Xs. For designers, the issue is in knowing which ones matter, because 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.

As a last step, it is important to manage the way simulation and synthesis processes handle the unknown (X) states thrown up by power management strategies that turn blocks on and off, and adjust clocks crossing between domains. A proper analysis of this issue can reveal functional bugs that have been hidden at the RTL level by too much optimism about the impact of X states, and also reduce the impact of excessive pessimism given to X states after synthesis.

Timing constraints (SDC) are a key input to the gate-level synthesis of designs, so SDC management and checking ensures correct timing for the block and full-chip level, so long as any changes in the RTL are reflected in the SDC files for the design. And the SDC itself needs to be verified for correctness and consistency, which is essential for other analyses such as clock design crossing.
Clock domain crossing analysis, so important for design reuse, IP, and complex power management schemes, can be carried out using a combination of formal and structural methods. It helps trap the corner case combinations of timing and functionality that lead to errors.

Power analysis and optimization techniques address issues such as retention flop and isolation-cell analysis and optimization, clock/power gating, and sequential/combinational optimizations. These interventions can be so extensive that it makes sense to go back to the other static analyses to recheck the design.

Combining these static verification steps can enable signoff of the RTL to reduce the simulation burden of testing functionality and the synthesis burden of trying to implement conflicted code from disparate IP. It means the design will be as correct as possible as soon as possible, with reduced risk of failure at the implementation stage. And billion-gate SoC signoff is now a reachable goal, not an impossibility.