FPGA与SoC芯片设计中五步法CDC跨时钟域检查方法学

Advanced Verification White Paper Five Steps to Quality

CDC Verification

Ping Yeung Ph.D.

Mentor Graphics

CDC synchronizers are used to reduce the probability of metastable signals. Taking unpredictable metastable sig-

nals and creating predictable behavior, they prevent metastable values from reaching the receiving clock domain.Metastability Effects

Even when proper CDC synchronizers are used for all clock-domain crossings and all CDC protocols are cor-rectly implemented, metastability inevitably leads to unpredictable cycle-level timing [4, 5]. Traditional RTL simulation does not model metastability, therefore, it cannot be used to find functional problems that may arise when metastability manifests in hardware. We are going to show two scenarios in which the cycle-level timing of RTL simulation differs from the cycle-level timing of the actual hardware in the presence of metastability.In Figure 3, the incoming CDC signal, cdc_d , violates the register setup time. Although it is sampled correctly in RTL simulation, the register is metastable and the output settles to 0. As a result, the hardware transition is delayed by one cycle.

Figure 2: A two-register CDC synchronizer.

Figure 4: Hold time violation: hardware transition is advanced by one cycle.

Figure 3: Setup time violation: hardware transition is

delayed by one cycle.

In Figure 4, the incoming CDC signal, cdc_d, violates the register hold time. In RTL simulation, it is not sam-pled until the next cycle. However, the register is metastable and the output settles to 1. As a result, the hardware transitions one cycle before simulation.

CDC Verification

Many designers know that metastability can be controlled using synchronizers on CDC signals. The most com-mon solution is to use synchronizers made up of two D flip-flops (2-DFF), or more, in sequence to dramatically increase the mean time between failure (MTBF) of the crossings. It is important to point out that simply ensur-ing the presence of synchronizers on the appropriate signals, while necessary, is not nearly sufficient. There are three different aspects of CDC verification that must be carefully addressed:

?Structural verification. Each synchronizer must have the correct structure for the type of signal being sent across clock domains. For example, a 2-DFF synchronizer is usually the best solution for single-bit signals but should not be used for multi-bit signals unless they are gray-coded to ensure that only one bit changes at a time [1, 2]. Multi-bit signals may be synchronized across domains using a separate control signal, an asynchronous FIFO, or other methods. Also, there should be no combinational logic inside or before a synchronizer.

?Protocol verification. Each synchronizer must follow a set of rules, called a transfer protocol, to ensure that the CDC signal is properly transferred across clock domains. For example, even the simplest 2-DFF synchronizer requires that the transmitting signal be held stable long enough to guarantee that it is captured in the receiving domain. This may not occur if the transmitting clock is faster than the receiving clock. Synchronization structures for multi-bit signals require more complex protocol checks [2, 3]. When CDC transfer protocols are violated, an error may not occur in simulation but will eventually occur in real hardware.

?Metastability verification. Problems associated with the reconvergence of CDC signals must be avoided. Reconvergence occurs when multiple signals are synchronized separately from one clock domain to another and then used by the same logic in the receiving domain (Figure 5). If that logic assumes a timing relationship between the signals, the design is not tolerant of metasta-

Figure 5: Reconvergence of CDC signals.

running CDC verification at the chip-level is not ideal

as there are too many behavioral models. For this reason, designs with the RTL representation are

best suited for CDC verification. All multiple-bit regis-

ters and buses can be identified explicitly. As CDC

requirements for data and control signals are different,

they can be analyzed separately. Conversely, with a gate-

level representation, all buses have been synthesized into

single-bit wires. It is impossible to distinguish data from

control signals. Thus, only a subset of the CDC scheme

is applicable.

In addition, knowledge of the internal structure of the

design is essential for successful CDC verification.

Performing CDC analysis on third-party IP blocks or

legacy designs are not very beneficial. Without design

knowledge, you may not be able to confirm the bugs or

filter violations. You need access to the original design-

er; knowledge of the design is essential to understand

the results.

Document CDC requirements This step is important. It has the biggest impact on the quality of the result. You need to ensure that your CDC verification will be aware of all relevant design characteristics, clock relationships, and the external environ-ment. Although a set of CDC rules have been defined already in the tool, with this additional information, extra design rules and filters will be activated. As a result, the results will be more accurate and thorough. You should define the operational modes of the design, outline the clock structures, document the domains for interface sig-nals, and determine the acceptable or unacceptable synchronization rules.

?Define operational modes . Some users may be interested in verifying that all registers are driven by only the test clock when the design is in scan mode. However, in general, we want to perform CDC verification when the design is in normal operation. You should disable the non-functional modes (i.e., test, BIST, JTAG , etc.)and define the meaningful operational modes and configurations for the tool (Figure 8). In many cases, some parts of a design can be put into sleep or powered-down mode. The combinations can be countless. Hence, it is important to focus CDC verification on the important combinations.

?Outline clock structures . For a multiple-clock design, the primary clocks, the clock distribution structure, and the internal clock generators, dividers, and clock gating schemes are important and should be documented. The 0-In CDC tool [7] can understand these structures and extract the clock tree information automatically. It is useful to verify the original design intent with the extracted clock structures. Only crossings between asynchronous clocks should be analyzed, and there may be clock gating conditions that need to be set up properly. As the number of CDC paths Figure 7: Blocks suitable for running CDC verification are A, C, and D.

Figure 8: Define meaningful modes for CDC verification.

is proportional to the number of clock domains, it is much more efficient to limit analysis to the relevant clock domains only.

?Document interface signals.CDC verification will not check an interface signal if it does not know which clock domain it is coming from or fanning out to. You should group signals for each functional interface and clock domain and explicitly identify any input signals that are asynchronous to all clock domains. The tool will then determine whether input signals require synchronization before use. Asynchronous and synchro-nous reset signals should be labeled separately. The synchronization schemes used for reset signals are dif-ferent from normal interface signals.

?Define synchronization rules.Some companies require all CDC signals to be synchronized with a particular CDC scheme (for instance, 3-level DFFs) or with a custom synchronization cell. The 0-In CDC tool [7] rec-ognizes many CDC schemes. It is important to review those schemes first. Then you can categorize the legal or illegal synchronization schemes, turn off the unused schemes and capture the characteristics of the syn-chronization cells or modules.

Some detail-oriented designers will specify the clock domain information and capture the CDC paths in the design document. This is a practice we encourage. With this information, you can pay special attention to the specified CDC paths to ensure they are well covered.

Formalize known exceptions

It is not unusual that a simple CDC error will generate a lot of violations, especially when the CDC signal fans out to a large number of asynchronous domains. Hence, we want to identify upfront all registers that can be con-sidered stable and do not require synchronization. This is especially true for configuration registers, status regis-

ters, or control registers that are programmed by software before the design enters into normal operation. Usually this information is in the design specification. Often these control registers all reside within a single module or follow a common naming scheme. It is useful to leverage this information for CDC verification.

In addition to registers, some of the interface or internal signals are known to be stable during normal opera-tion; for example, the internally generated reset signals, the power-down signals, the chip select, and functional enable and disable signals. These are all useful in improving the efficacy of CDC verification. Finally, in previ-ous revisions of the chip, there may be known CDC bugs and issues found using manual or gate-level method-ologies.. These are painful lessons which should be captured in the verification plan. During CDC verification, you should ensure that those CDC paths are analyzed and that all problems were fixed correctly.

Define coverage goals

Based on our experience, CDC paths are poorly verified by traditional functional verification because, in a functional simulation environment, the clock periods are defined to be constants, the clock skews and relation-ships are fixed, and the clock signals are well-behaved without any buffer or propagation delay. To ensure metastability effects on CDC paths are better verified, companies use various ad-hoc approaches. Some ran-domly reduce or prolong the clock periods. Some randomly change the skews and relationships among multiple asynchronous clocks.

Regardless of the technique used, when verifying CDC transfer protocols in simulation, it is important to moni-tor protocol coverage to make sure the CDC paths are adequately verified. This can be done by using a checker from an assertion library [9, 10, 11] to capture the semantics of the protocol. Checkers collect coverage infor-mation to ensure that each CDC protocol is fully exercised. Insufficient coverage means that the design may contain undiscovered bugs.

CDC Handshake:

- Assertion:

i.multiple requests violation

ii.acknowledge without request violation

iii.request drop violation

iv.acknowledge timeout violation

- Coverage:

i.#request asserted

ii.#acknowledge asserted

CDC FIFO:

- Assertion:

i.FIFO overflow violation

ii.FIFO underflow violation

iii.Simultaneous push and pop violation

- Coverage:

i.#push asserted

ii.#pop asserted

iii.maximum FIFO entry

You start by itemizing the protocols used in the CDC paths, ordering them from most important to least, and identifying the protocols that require coverage. For each CDC protocol, you will determine the assertion and coverage items, as in the code shown above. To measure how well your simulation is verifying the metastability effects, you should also monitor the alignments of the RX and the TX clocks.

Select a verification strategy

You may choose to perform exhaustive verification on each individual block or use a hierarchical approach on the entire top-level of a chip. The top-level represents the highest functional hierarchy of the design, excluding the pad ring, the test logic, the power controls, etc. You may be looking for a known bug or hunting for a prob-lem that has appeared in the lab. The strategies you choose will determine how to run your CDC analysis tools. Based on our experience, there are four common strategies

?Block-level verification.During block-level design, static analysis of the CDC structures should be run before checking in the RTL code. This ensures strict compliance with CDC schemes. If issues are discov-ered, they can be identified and debugged quickly at this level. The generated CDC protocol monitors can also be used with block-level functional verification methodologies, such as formal verification [8] and simulation. These ensure that CDC protocols are followed without any data loss.

?Top-level verification. During top-level integration, static analysis of the CDC structures should be re-run to check the new CDC signals created when multiple blocks are integrated together. The number of CDC signals goes up exponentially at the top-level. Hence, it is important to follow the five-step planning process

described above. For large and complex designs, especially ones with a lot of IP modules, a hierarchical veri-fication approach can be used. The generated CDC protocol monitors should be included in the regression for system-level functional verification.

?Bug hunting and triage. This is performed to identify known or suspected CDC issues in the design. It is important to distinguish timing from CDC issues. Timing issues tend to cause the chip to fail consistently. By changing the frequencies of the clocks or of some of the signals, the problems may disappear permanently. On the other hand, as metastability is unpredictable, CDC problems will cause the chip to fail randomly. Based on our experience, it is extremely difficult to look for CDC issues at the system or chip level. There are just too many potential candidates. Hence, the first task is to narrow down the problem to the block or subsystem level.

You should focus on blocks with asynchronous clock domains. Blocks with CDC reconvergence are especially suspicious. The random delays from different CDC paths may cause the data to be sampled incorrectly or cor-rupted completely. Once the candidate blocks are identified, the block-level verification strategy can be applied.?Targeting coverage.This can be an extension of the block-level or top-level verification strategy. The goal is to ensure that all CDC protocols have been fully exercised and that the metastability effects are fully verified on all CDC paths. The coverage on the CDC protocols monitors should be examined and additional tests created to fill any coverage holes. Once the bug rate of system-level regression has stabilized, metastability can be injected into simulation. Metastability effects will change the timing of the CDC paths. If the block is not designed to handle the random delays of the CDC paths, it may fail functionally. To make debugging easier, it is better to start with a representative subset of the regression.

In the next two sections, we will elaborate on the two most commonly used strategies: block-level and

top-level verification.

?Correctly implemented synchronizers

?Missing and incorrectly implemented synchronizers

?Complex synchronizers that require protocol verification

?Potential reconvergence problems

At this level, since the design description contains a lot of modules with a lot of asynchronous clock domains, most of the CDC paths fall into the complex and reconvergence categories. The GUI environment is particularly useful in this case as the CDC path may span multiple levels of hierarchy and several modules.

2. Run protocol verification with simulation. With the testbench environment already available for functional veri-fication, we can run the CDC protocol monitors within the simulation environment. These monitors ensure that the CDC signal is stable when going from the TX to the RX domain; the multiple-bit CDC data is gray-coded, or it is stable when it is sampled. Any assertion failure caught by the monitors means that the CDC protocol is vio-lated and should be fixed. Functional simulation gives lengthy margins for CDC signals. They tend to be suffi-ciently stable when going through the clock domains. This approach does a poor job stressing the timing of the CDC paths. Hence, when running CDC protocol monitors with functional simulation, it is important to examine the corner case coverage of the protocol monitors. Monitors which pass should have adequate coverage when the results from the whole regression suite are merged together. In order to stress the timing of the CDC paths explic-itly, we can add some direct tests into the regression suite. With a constrained-random verification environment, we can tighten the timing of the stimulus generator.

3. Run metastability verification with simulation and effect injection.If your design contains potential reconver-gence violations that cannot be easily waived after manual inspection, the 0-In CDC tool [7] can be used to iden-tify reconvergence problems by injecting metastability effects dynamically. In simulation, metastability effect injectors will change the delays through synchronizers. As a result, any logic that assumes a fixed timing rela-tionship between the outputs of the synchronizers is likely to fail. Running simulation with the effect injectors is the most cost effective way to imitate CDC metastability effects during functional verification. It enables any potential problems to be discovered quickly, before any hardware is built.

Debugging CDC Violations

In this section, we will describe a few common CDC violations and the techniques you can use to determine whether they are real design issues or not.

Missing synchronizer violation

An unsynchronized CDC signal is the most common violation reported during structural verification. For instance, in Figure 11, depending on the clock frequency, the RX register may not be able to sample its input reliability. This is a real problem. In other cases, violation are due to the following exceptions.

References

1. Clifford E. Cummings, “Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock Designs,” SNUG-2001. Downloadable from https://www.360docs.net/doc/1b9337622.html,/papers

2. Tai Ly, “The Need for an Automated Clock Domain Crossing Verification Solution,” White Paper, Downloadable from https://www.360docs.net/doc/1b9337622.html,/fv

3. Chris Kwok, et al, “Using Assertion-Based Verification to Verify Clock Domain Crossing Signals,” DVCon 2003

4. Tai Ly, et al, “Formally Verifying Clock Domain Crossing Jitter Using Assertion-Based Verification,” DVCon 2004

5. Tai Ly, et al, “A Methodology for Verifying Sequential Reconvergence of Clock Domain Crossing Signals,” DVCon 2005

6. Harry Foster, et al, “Assertion-Based Design,” Kluwer Academic Publishers, 2003

7. Mentor Graphics, “CDC Compiler User Guide V2.5,” Feb 2007

8. Mentor Graphics, “Formal Verification User Guide V2.5,” Feb 2007

9. Accellera, “Accellera Standard OVL Library Reference Manual,” July 2006

10. Mentor Graphics, “QuestaTM Verification Library Checkers Data Book V6.2f,” Jan 2007.

11. Mentor Graphics, “CheckerWare Data Book Assertion Library V2.5,” Feb 2007

Corporate Headquarters Mentor Graphics Corporation 8005 S.W. Boeckman Road

Pacific Rim

Mentor Graphics Taiwan

Room 1603, 16F,

Europe

Mentor Graphics

Deutschland GmbH

Silicon Valley

Mentor Graphics Corporation

1001 Ridder Park Drive

Japan

Mentor Graphics Japan Co., Ltd.

Gotenyama Hills

Copyright ? 2007 Mentor Graphics Corporation. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposed only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use of this information. 0-In and Mentor Graphics are registered trademarks of Mentor Graphics Corporation. All other trademarks are the property of their respective owners.

For more information, visit https://www.360docs.net/doc/1b9337622.html,/fv