The Need for Gate-Level CDC

Transcription

1 The Need for Gate-Level CDC Vikas Sachdeva Real Intent Inc., Sunnyvale, CA

2 I. INTRODUCTION Multiple asynchronous clocks are a fact of life in today s SoC. Individual blocks have to run at different speeds in order to handle different functional and power payloads efficiently. In addition, the ability to split clock domains across an SoC, in effect isolating clock domains to small subsections of the device within which traditional skew-control can still be used, has become a key part of timing-closure processes. As a result, clock domain crossing (CDC) verification is essential to ensure that logic signals pass between regions controlled by different clocks without corruption or causing metastability. Traditionally, CDC verification has been carried out on RTL designs on the basis that appropriate directives inserted in the RTL will ensure that reliable data synchronizers are inserted into the netlist by synthesis. In reality, a number of factors are coming together that demand a re-evaluation of this assumption. II. Motivation for Gate-Level CDC A combination of process technology trends and increased intervention by synthesis tools in logic generation, both intended to improve power efficiency, performance and area, is leading to a situation in which a design that is considered CDC-clean at RTL can fail in operation. Implementation tools fail to take CDC into account and unwittingly increase the chances of metastability and transient effects. For example, synthesis algorithms and post-synthesis tools insert logic cells that, if in the path of a CDC, conflict with assumptions made in CDC analysis during RTL verification. Consider the circuit in Figure1. A CDC-valid mux-based synchronizer is converted during synthesis to combinational logic that is logically correct, but can propagate a glitch from the asynchronous transmit domain, causing chip failure. Figure 1: Logic optimization leading to glitch failure at gate level 2

3 There are many more changes which take place in the design flow from RTL to gate level. Test synthesis, for example, inserts additional registers for inspection of logic paths through JTAG. Low-power design can further complicate CDC analysis by introducing new CDC paths or invalidating CDC paths already verified in RTL. For example, consider the circuit in Figure2, which shows the introduction of a new asynchronous driver absent in RTL. Figure 2: New asynchronous driver absent at RTL level The size and complexity of today s designs, coupled with the challenges of meeting timing, area, power and schedule, requires the newest, most advanced synthesis optimizations. These complex optimizations, such as flop cloning or retiming, can inadvertently create CDC hazards even though the RTL is CDC clean. For example, consider the circuits in Figure3 and Figure4. They show advanced synthesis optimizations leading to CDC failures at gate level. Figure 3: Retiming leading to CDC Glitches 3

4 Figure 4: Flop cloning leading to CDC correlation failure Another imperative for gate-level CDC is the effect of sub 14nm technology nodes. Beyond the standard CDC-aware design techniques, one must also keep an eye on the likelihood of metastability as modeled by the formula for mean time between failure (MTBF) of each synchronizer: MTBF varies with the settling time of the signal (S), the time window over which data is expected to settle to a known state (T w), the clock frequency (F C), the data frequency (F D), and the resolution time-constant for the synchronizer, written as τ (tau). The τ parameter depends primarily on the capacitance of the first flip-flop in the synchronizer, divided by its transconductance. To get the correct picture, the parameters affecting MTBF should be measured post synthesis and physical design, and adjustments should be made for crossings where the MTBF is below spec. In particular, the value of τ varies with both process technology and operating temperature because these parameters affect drain current and transconductance. As a result, the MTBF can drop many orders of magnitude at temperature extremes, making failure far more likely. Technology evolution has generally improved τ, making it less significant as a parameter over the past decade, but τ is beginning to become significant again in more advanced nodes because of the inability to scale some device parameters. Because of the reasons given above, CDC verification needs to occur at both RTL and the gate level (netlist) any solution that does not perform gate-level verification is not complete. An effective strategy is to ensure that the design is CDC clean at RTL, and then to use physical-level CDC checks on the netlist to ensure that problems that might have been created by the various implementation tools are trapped and fixed using a combination of structural and formal techniques. 4

5 III. Gate-Level CDC Methodology - Challenges and Requirements CDC verification is a critical part of the design verification cycle. It is important to catch CDC errors as early as possible in the design cycle, probably more so than for other types of failure because CDC failures are catastrophic and very hard to catch and triage in simulation. Because of this, CDC verification at RTL is a necessary step. However, as was explained in last section, just RTL verification for CDC is not sufficient as some CDC hazards can only be caught at the gate-level. Gate-level CDC verification comes with its own set of challenges, some which are explained below: Setup effort Most of CDC sign-off currently is done at RTL. So CDC-relevant design constraints are nominally available only for RTL. Unfortunately, these constraints may not be directly applicable at gate level because of various transformations from RTL to gates. Typical changes are in instance hierarchies and signal names. Creating new constraints is a duplication of effort and significantly impacts chip schedules if added to the design process. On the other hand, manually mapping constraints from RTL to netlist can be an error-prone and high-effort task. In order to be successful, a gate-level CDC methodology needs to handle these setup challenges in an efficient manner. Capacity and scalability challenges As we move from RTL to gate level, design-size increases many times over because new logic is added and existing logic is converted into a sea of gates. In addition,, gate-level designs are usually flattened out, implying that CDC analysis at the gate-level needs to run flat. Buses are also expanded and bit blasted at the gate-level. It is also difficult to identify CDC structures like FIFOs at the gate-level due to expanded logic. These changes can stress the capacity of even state-of-art CDC verification flows. Moreover, accurate and low-noise glitch analysis at the gate-level needs efficient functional and formal technology to be able to handle these billion gates netlists. Debug effort Gate-level CDC sign-off can be a huge burden on verification engineers if they have to reanalyze all the CDC paths that were already signed-off in RTL. On the other hand, paths that were signed-off in RTL can go through transformations that invalidate RTL sign-off. Reusing RTL waivers automatically can also be a risky proposition in this scenario. An efficient methodology needs to address these debug effort challenges and provide a solution that provides complete gate-level CDC sign-off without overwhelming verification engineers. A winning methodology will be the one that is efficient in terms of the overall time it takes to detect, debug, and fix all CDC issues. Automation and ease of debug are very important, as well as is the ability to reuse effort spent in RTL CDC verification. IV. Complete CDC Sign-Off with Verix CDC & Verix Physical CDC 5

6 Verix Physical CDC, built on the top of Real Intent s revolutionary first-to-market multimode CDC sign-off solution Verix CDC, enables efficient sign-off-quality multimode gate-level CDC verification. In the Verix Physical CDC flow an RTL CDC DB is saved automatically at the end of an RTL CDC run. The proprietary DB contains comprehensive CDC information about RTL constraints and CDC paths. A gate-level run with Verix Physical CDC saves user effort and iterations significantly by automatically mapping the previously saved RTL constraints to the gate level. It can also take guidance from formal equivalence tools to enable such mapping. Figure 5 shows the Verix Physical CDC sign-off flow. Figure 5: Verix Physical CDC sign-off flow Once the RTL constraints have been mapped, Verix Physical CDC identifies CDC crossings paths and runs CDC Equivalence (CDC-EQ) to check whether any CDC paths have gone through transformations that invalidate RTL CDC sign-off. CDC-EQ provides a waiver-free approach and avoids user or methodology effort in waiver mapping from RTL to gate-level, while ensuring risk free sign-off. Verix Physical CDC builds on the proven industry-leading performance and capacity of Verix CDC and adds netlist-specific optimization to enable flat CDC analysis on billion-gate size designs. Verix Physical CDC s enhanced structural and staged-formal glitch analysis enables comprehensive glitch sign-off for billion gate SoCs. It provides high-quality failure reporting that does not miss any potential glitch issues and such that crossings that are reported as requiring designer review tend to be real failures. In addition to the above, Verix Physical CDC also supports an integrated visualization tool. Its idebug GUI provides pruned annotated schematic and source views that focus on the faulty logic. The schematic generated is tuned to the specific CDC problem being reported. For example, Figure 6 shows the schematic for a glitch violation identified by Verix Physical CDC. 6

7 Figure 6: Pruned annotated schematic in idebug Said schematics are annotated with CDC attributes specific to the problem being investigated. These attributes enable context-specific root-cause analysis, and allow users to quickly identify sources of clocks, resets, constants and other CDC properties of the design. Users can efficiently investigate CDC problems deep in the design to quickly root cause any CDC warnings or errors. In general, at every step in debug, idebug provides helpful guidance and suggests actions for users to pinpoint the problem source quickly. V. SUMMARY Traditionally, CDC verification has been carried out on RTL descriptions on the basis that appropriate directives inserted in RTL will ensure that reliable data synchronizers are inserted into the netlist by synthesis. Unfortunately, a number of factors are coming together that demand a reevaluation of this assumption. Especially in advanced technology nodes, CDC analysis at the gate-level is necessary. Without it, CDC bugs introduced during synthesis can slip through into tape-out, leading to chip failure Verix Physical CDC s unique flow linked to RTL DB provides an unprecedented runtime and productivity boost for netlist CDC sign-off, saving weeks of sign-off effort. Verix Physical CDC s proprietary mapping and CDC-Equivalence technology enables gate-level CDC signoff with minimal additional effort on the part of verification engineers. Verix Physical CDC builds on the proven industry-leading performance and capacity of Verix CDC and adds netlist-specific optimization to enable flat CDC analysis on billion-gate designs. Verix Physical CDC s enhanced structural and staged-formal glitch analysis enables comprehensive glitch sign-off for billion-gate SoCs. It provides high-quality failure reporting in which crossings reported as requiring designer review tend to be real failures. The Verix Physical CDC flow was developed with several partners who have helped refine the presentation of violations. This has also helped ensure that the tool provides relevant debug information for the user to understand the cause and effect of a violation. Verix Physical CDC s technology delivers the full pathway for RTL + Netlist CDC sign-off. 7

8 REFERENCES [1] Real Intent, Inc. 932 Hamlin Court Sunnyvale, CA Phone: Fax: realintent.com 8