1 Clock Domain Crossing

OverviewAs modern System-on-Chip (SoC) designs continue to face increasing size andcomplexity challenges, multiple asynchronous clock domains have been employedfor different I/O interfaces. A CDC-based (Clock Domain Crossing) design is a designthat has one clock asynchronous to, or has a variable phase relation with, anotherclock. A CDC signal is a signal latched by a flip-flop (FF) in one clock domain andsampled in another asynchronous clock domain. Transferring signals betweenasynchronous clock domains may lead to setup or hold timing violations of flip-flops.These violations may cause signals to be meta-stable. Even if synchronizers couldeliminate the meta-stability, incorrect use, such as convergence of synchronizedsignals or improper synchronization protocols, may also result in functional CDCerrors. Functional validation of such SoC designs is one of the most complex andexpensive tasks. Simulation on register transfer level (RTL) is still the most widelyused method. However, standard RTL simulation can not model the effect of meta-stability.Within one clock domain, proper static timing analysis (STA) can guarantee that datadoes not change within clock setup and hold times. When signals pass from oneclock domain to another asynchronous domain, there is no way to avoid meta-stabilitysince data can change at any time.As the CDC errors are not addressed and verified early in the design cycles, manydesigns exhibit functional errors only late in their design cycles or during post-siliconverification. Several coverage metrics are proposed to measure the validation'sadequacy and progress, such as code based coverage, finite state machinecoverage, and functional coverage. Nevertheless, these coverage metrics do nothave direct relations with CDC issues.To address clock domain problems due to meta-stability and data sampling issues,designers typically employ several types of synchronizers. The most commonly usedsynchronizer is based on the well-known two-flip-flop circuit. Other types ofsynchronizers are based on handshaking protocols or FIFOs. In a limited number of

cases it may be useful to employ dual-clock FIFO buffers or other mechanismsoptimized for domains with similar clock frequencies.To accurately verify clock domain crossings, both structural and functional CDCanalysis should be carried out. Structural clock domain analysis looks for issues likeinsufficient synchronization, or combinational logic driving flip-flop basedsynchronizers. Functional clock domain analysis uses assertion-based verification tocheck the correct usage of synchronizers. Assertions may be used to find problemssuch as data stability violations when going from a fast clock domain to a slower one.Assertions generated in PSL or other assertion languages such as OpenVera orSystemVerilog, can then be used in formal model checking or simulation.This chapter is organized in the following sections:

Background - Prepares the background required for further discussions.Synchronization Techniques - Discusses the synchronization techniques.CDC Analysis - Discusses the various steps of CDC analysis.Leda-CDC Flow - Provides information on the basic Leda-CDC tool flow.Automatically Generated CDC Assertions - Provides a detailedspecification of the Leda supported assertions.CDC AEP Rule Usage & Naming Conventions for AutomaticallyGenerated CDC AEP Files - Provides further detail of assertion relatedtopics.

BackgroundClock domainA clock domain is a part of a design that has a clock that operates asynchronous to, orhas a variable phase relationship with, another clock in the design. For example, aclock and its derived clock (via a clock divider) are in the same clock domain becausethey have a constant phase relationship. But, 50MHz and 37MHz clocks (whosephase relationship changes over time) define two separate clock domains. Figure 1illustrates three different clocks in a design, but synchronous to each other. CLK, itsinversion and D1 (derived from CLK) are synchronous to each other.

Figure 1: Synchronous Clock

A clock domain crossing signal is a signal from one clock domain that is sampled bya register in another clock domain. More details of the clock origin/domain inferenceengine are given in [1].

Meta-stability

Every flip-flop (FF) that is used in any design has a specified setup and hold time, orthe time in which the data input is not legally permitted to change before and after asampling clock edge. This time window is specified as a design parameter preciselyto keep a data signal from changing too close to another synchronizing signal thatcould cause the output to go meta-stable.

Figure 2: Setup and hold time of a Flip-flopHowever, if some input(say d in Figure 2)violates the setup andhold time of a FF, theoutput of the FF (q inFigure 2) keepsoscillating for anindefinite amount oftime. This unstablevalue may or may notnon-deterministically

converge to a stable value (either 0 or 1) before the next sampling clock edge arrives.Example - Consider the 1-bit CDC signal adat, which is sampled by register bdat1 inFigure 3. Since adat comes from a different clock domain (aclk), its value can changeat any time with respect to bdat1's clock (bclk). If the value of adat changes duringbdat1's setup and hold time, the register bdat1 might/might not assume a statebetween 0 and 1. In this state, the register is said to be meta-stable. A meta-stableregister may/may not (unpredictably) settle to either 0 or 1, causing illegal signalvalues to be propagated throughout the rest of the design.

Figure 3: Meta-stability scenario

In a multi-clock design, meta-stability is inevitable, but there are certain designtechniques that help to avoid the chance of getting meta-stable. The following sectionprovides an overview of different synchronization techniques.

Synchronization Techniques

The main responsibility of a synchronizer is to allow sufficient time such that anymeta-sable output can settle down to a stable value in the destination clock domain.The most common synchronizer used by designers is two-flip-flop (2-FF)synchronizers as shown in Figure 4. Usually the control signals in a design aresynchronized by 2-FF synchronizers.

Figure 4: A 2-FF synchronizer

Synchronization of Control Signals with 2-FF SynchronizersIn a 2-FF synchronizer, the first flip-flop samples the asynchronous input signal intothe destination clock domain and waits for a full destination clock cycle to permit anymeta-stability on the stage-1 output signal to decay, then the stage-1 signal issampled by the same clock into a second stage flip-flop, with the intended goal thatthe stage-2 signal is now a stable and valid signal synchronized into the destinationclock domain. It is theoretically possible for the stage-1 signal to still be sufficientlymeta-stable by the time the signal is clocked into the second stage to cause thestage-2 signal to also go meta-stable.However, note that the meta-stability is a probabilistic phenomenon. The meta-stableoutput converges to a stable value with time. Therefore, even if the input to the stage-2 FF still remains meta-stable, the probability that the output of the stage-2 FF willremain meta-stable for a full destination clock cycle is asymptotically close to zero.This calculation of the probability of the time between synchronization failures(MTBF) is a function of multiple variables including the clock frequencies used togenerate the input signal and to clock the synchronizing flip-flops. For mostsynchronization applications, a 2-FF synchronizer is sufficient to remove all likelymeta-stability.Even if a 2-FF synchronizer helps to prevent propagation of meta-stable values, forthe correct operation of the design, some other issues needs to be tackled. Theseissues are explained in the following sections.

Input Data Stability to Avoid Data LossA synchronizer circuit ensures avoiding propagation of meta-stability into thedestination clock domain, but it can't ensure propagation of correct value as the meta-stable signal non-deterministically converges to any stable value (1 or 0). However,for correct operation of the design, every transition on the input signal needs to becorrectly propagated to the destination domain. To ensure preventing data loss(losing input transitions), the input signal needs to hold its value a minimum amount of

time such that there is at least a single destination sampling clock edge, whichsamples the input value correctly (No setup/hold violation; Figure 5 gives such anexample). This stability condition on the input signal is usually checked by puttingassertions. For more information, see the section "Flip-flop Synchronizers".

Figure 5: Stability of input signal value

Gray Encoding to Avoid Data Incoherence (For Vector CDCControl Signals)Similar to the case of syncing a single bit control signal, the natural way to transfer avector control signal is to model each bit of the vector to be separately synchronizedby a FF synchronizer. You have already seen that even if you use FF synchronizers,it usually takes more than one cycle to propagate correct input values to thedestination domain. Now consider a case where every bit of the vector takes atransition very close to the destination clock edge. Also assume that, by virtue ofmeta-stability, only some of these transitions are correctly captured by the destinationdomain in the first cycle. Now, if the bit values of the vector decide the state of thedestination domain, after the first cycle, the destination domain may move into aninvalid state.

Figure 6: Scenario indicating Data Incoherence

Example - Suppose a vector control signal Sig [2:0] crosses from Domain 1 toDomain 2. Signal Sig also decides the state of Domain 2 and you assume that thevalue "100" of Sig [2:0] indicates an invalid state for Domain 2. Now, think of asituation, where the signal Sig wants to change its value from "000" to "101" (both

indicate valid states). This requires the two bits Sig [0] and Sig [2] to transitsimultaneously. Both these transition occurs very close to the destination samplingclock edge (see Fig 6). By virtue of meta-stability, transition on Sig [2] gets capturedcorrectly and the transition on Sig [0] is missed. In this way, in the first cycle of thedestination clock, the system moves to state "100" which is invalid.This case would not have happened, if changing the states of the design requireschanging only a single bit of the vector (Sig in this case). In case of a single bittransition, either that transition would be captured in the destination domain or not.This way the design either stays in the previous state or move to a valid state.Therefore, for vector control signals (multi-bit signals, such as address buses), theusual solution is to use a Gray code when crossing a clock domain boundary. A Graycode ensures that only a single bit changes as the bus counts up or down. Thepresence of gray coding on vector control signal can be checked by using assertions.For more information, see the section "Gray Code Encoding for Vector ControlSignals".

Synchronization of CDC Data SignalsOne of the challenges in designing a multi-clock based system is to enable correcttransfer of data buses from one clock domain to another. The difficulty arises, asindividual bits of a data bus can change randomly while changing clock boundaries.Using synchronizers/gray code to handle the passing of data bus is generallyunacceptable.Three common methods for synchronizing data between clock domains are:

Using MUX based synchronizers.Using Handshake signals.Using FIFOs (First In First Out memories) to store data with one clockdomain and to retrieve data with another clock domain.

Passing Data through MUX SynchronizerAs shown in the following figure (Figure 7), in a MUX synchronizer, the control path isusually FF-synchronized while the synced-in control signal is used to synchronize thedata paths.

Figure 7: A MUX synchronizer

Handshaking Data between Clock DomainsData can be passed between clock domains using a set of handshake controlsignals, depending on the application and the paranoia of the design engineer. Whenit comes to handshaking, the more control signals that are used, the longer thelatency to pass data from one clock domain to another. The biggest disadvantage inusing handshaking is the latency required to pass and recognize all of thehandshaking signals for each data word that is transferred. Figure 8 shows a typicalhandshake synchronizer.

Figure 8: A Handshake Synchronizer

For many open-ended data-passing applications, a simple two-line handshakingsequenceissufficient.The senderplaces dataonto a databus andthen

synchronizes a "req" signal (request) to the receiving clock domain. When the "req"signal is recognized in the destination clock domain, the receiver clocks the data intoa register (the data should have been stable for at least two/three sampling clockedges in the destination clock domain) and then passes an "ack" signal(acknowledgement) through a synchronizer to the sender. When the senderrecognizes the synchronized "ack" signal, the sender can change the value beingdriven onto the data bus.

Passing Data by FIFO between Clock DomainsOne of the most popular methods of passing data between clock domains is to use aFIFO. A dual port memory is used for the FIFO storage. One port is controlled by thesender, which puts data into the memory as fast as one data word (or one data bit forserial applications) per write clock. The other port is controlled by the receiver, whichpulls data out of memory; one data word per read clock. Two control signals are usedto indicate if the FIFO is empty, full, or partially full. Two additional control signals arefrequently used to indicate if the FIFO is almost full or almost empty. In theory, placingdata into a shared memory with one clock and removing the data from the sharedmemory with another clock seems like an easy and ideal solution to passing databetween clock domains. For the most part it is, but generating accurate full and empty

flags can be challenging.Figure 9: A dual-clock FIFO Synchronizer

User-definedSynchronizersSometimes, you mayspecify some cells tobe synchronizers. Ifthis cell is found onthe path between theFF, the path has tobe considered assynchronized. Note

that the cell itself may have other inputs than the source flip-flop as shown in thefollowing illustration. The way of specifying a synchronizer is explained in chapter 2,section "Using Tcl Command 'set_cdc_synchronizer'".

Figure 10: User-defined Synchronizer

CDC AnalysisFollowing are thebasic steps for CDCanalysis and checking(irrespective of toolsetimplementation):

StructuralAnalysis to

Identify CDC Signals and Appropriate SynchronizersThe most important task of any CDC structural analyzer is to find out all the signals(CDC) that cross clock boundaries. In Leda, rule NTL_CDC01 (For more information,see the section "CDC Ruleset" in chapter 2.) reports all the un-synchronized CDCpaths. However a CDC path may be synchronized in the destination clock domain.Thus, identification of synchronization schemes is very important to avoid reportingfalse CDC reports. Automatic detection of synchronizers is very tough and maydepend on the underlying design principle. Therefore, sometime, the designer needsto provide additional information for the underlying synchronization schemes.Once extraction of information for all the CDC paths (synchronized and un-synchronized) is over, you need to see whether there are structural defects before andafter the synchronizers.

Structural Analysis to Identify Structural Defects Before and AfterSynchronization

Many design teams choose a few synchronizer styles, apply them to all signalscrossing clock domains and enforce their usage by design style rules and designreviews. Although proper synchronizers are essential for multi-clock designs, they areinsufficient to avoid all possible problems regarding signals crossing clock domains.Considerable extra care must be taken in the design process to avoid theseproblems. Some of the structural problems that may cause functional errors in multi-clock based systems are as follows.

Convergence in the Crossover PathUsing combinational elements in a CDC path before synchronization can lead tofunctional problems. For example, it is important that glitches in the driving clockdomain not be propagated into the receiving clock domain. Since the flip-flops in thereceiving clock domain can sample the signals from the driving clock domain at anypoint, there is no way through static timing analysis to ensure that the glitch will not bepropagated. Figure 11 shows an example of combinational logic (convergence) thatcould cause a glitch to pass from one clock domain to another. Rule NTL_CDC02detects this issue.

Figure 11: Glitch propagation due to convergence in CDC Path

Divergence in the Crossover PathDesign styles which allow divergent logic on a CDC signal to multiplesynchronization paths, may cause functional errors. As Figure 12 illustrates, a singlecontrol signal (Trans_en) from the source clock domain (clk1) is used to activate boththe "addr" and "data" transfer unit in the destination clock domain (clk2). The purposeis to enable both the logics at the same time. To model this, fan-outs of Trans_en hasbeen used before the synchronization takes place. However, due to the propagationdelay and different meta-stable settling times, the two fan-outs ('addr_en' and'data_en') could reach the Address and Data transfer logics at different times.Therefore these two logics may start at different time causing functional errors. Thistype of structure should be avoided by fanning out a single FF synchronized 'commonenable' signal to the two transfer logics. Rule NTL_CDC03 detects this issue.

Figure 12: Divergence in the crossover path

Divergence of Meta-stable SignalUsing a meta-stable signal in a design can be erroneous. Therefore multiple fan-outof the output of the first FF of a FF synchronizer can cause functional errors. RuleNTL_CDC04 detects this issue.

Figure 13: Divergence of meta-stable signal

Re-convergence of Synchronized SignalsSynchronization and glitch elimination alone are not enough to ensure reliabletransfer of data across clock domains. When a signal goes meta-stable, a

synchronizer settles it down, but cannot guarantee the precise number of cyclesbefore the valid signal is available in the receiving clock domain. Therefore, if (1) twoindependent signals or (2) bits of a multi-bit signal are independently synchronized(using same type of synchronizers or different types of synchronizers), the bits mayarrive in the receiving clock domain skewed with respect to one another. A verysimple form of re-convergence is shown in Figure 14. Rule NTL_CDC05 and

NTL_CDC07 detect this issue.Figure 14: The simplest form of re-convergence

Therefore, even when meta-stability does not occur, any pair of bits can get out ofsynchronization if routing differences and electrical effects cause the two bits to havedifferent delays before reaching their respective synchronizers. It is possible for onesynchronizer to sample its input and capture a signal change before the othersynchronizer captures the change, at which point the two copies of the signal will beskewed by a cycle and no longer correlated.Leda has six rules that check all the above structural checks for CDC signals. Thepurpose of these rules is to provide the following information. Detailed description ofall the Leda structural checks is provided in chapter 2.a. NTL_CDC01 - Reports all the unsynchronized CDC paths in the design.b. NTL_CDC02 - Reports all convergence in the crossover paths in the design.c. NTL_CDC03 - Reports all divergence in the crossover paths in the design.d. NTL_CDC04 - Reports divergence of any meta-stable signal in the design.e. NTL_CDC05/07 - Reports all kinds of re-convergence of synchronized signals inthe design. There is a subtle difference between rule NTL_CDC05 and NTL_CDC07.For more information about the difference, see the section "CDC Ruleset" in chapter2.

Determination and Validation of Appropriate Properties for EverySynchronizer

Just having a synchronization circuit connected is only part of the solution; theassociated logic must interact correctly with the synchronization circuit to ensure validoperation. To ensure this, assertions need to be specified that check correctfunctionality of the synchronization circuits and validates correct use of thesynchronizers by the environment in which they are instantiated. You automaticallyspecify these properties once for every synchronizer and automatically attach them toall instances of the corresponding synchronization building blocks. The supportedproperty checks for CDC synchronization circuit elements are given as follows. Formore information about these property specifications, see the section "AutomaticallyGenerated CDC Assertions".Flip-flop Synchronizer

Control signal stability assertionsMUX Synchronizer

Control signal stability assertionsData signal stability assertions

Handshake SynchronizerControl signal stability assertionsData signal stability assertionsHandshake protocol check assertions

FIFO SynchronizerControl signal stability assertionsGray coded assertions for read and write pointersFIFO protocol (full/empty check) assertionsData integrity checks

A more complete description of the CDC AEP (automatically extracted properties)usage is given in the section "CDC AEP Rule Usage".

Leda - CDC FlowThe complete Leda CDC flow is given in Figure 15. The main CDC related moduleshave been colored. The CDC verification engine takes help of the Magellan/VCS forchecking the Leda CDC assertions (statically/dynamically).

Figure 15: The complete Leda CDC flow

Automatically Generated CDC AssertionsStructural analysis primarily checks whether there exists a synchronizer in the CDCpaths. Having a synchronizer connected only solves the verification problem partially.You additionally need to check the following two features.

1. The environment (associated logic) must interact properly with the synchronizer.2. The

synchronizer itself behaves correctly.These two checks are mandatory to ensure valid operation in real life. The AEP(automatically extracted properties) engine of Leda generates and binds assertionsthat check correct functionality of the synchronizers and validates correct use of thesynchronizers by its environment. To identify the synchronizers, the AEP engine usesthe Leda structural analyzer. In the following paragraphs, you will categoricallyenumerate the synchronizer related checks for ABV (assertion based verification).

Flip-flop SynchronizersDescriptionThe FF synchronizers (shown in Fig 16) form the basic building block for most of theexisting synchronization circuits. A simple FF synchronizer consists of m (> 1) FFmodeled as a shift register running on the 'destination clock'. Once the presence of aFF synchronizer having m stages is detected, the following property is generated toensure that the device functions correctly in presence of this synchronizer.If no assumptions are made about the relationship between the 'source' and'destination' clock domains, then the following property ensures that all input signalvalues can be reliably transported to the synchronizer output.Input data values must be stable for m+1 destination clock edges.

Figure 16: Flip-flop Synchronizers

ImplementationExample SVA codes for the above properties are given as follows. This assertion

verifies the stability of din as observed in the destination clock domain. Signal rst isthe reset signal (if any, with the appropriate polarity) extracted from the synchronizerFF, din is the single bit input to the first FF of the synchronizer.property p_stability; disable iff (rst)@( dclk) !$stable (din) |=> $stable (din)[*m] );endproperty A_p_stability: assert property (p_stability);

MUX SynchronizersDescriptionDesigns typically have both control and data paths. As shown in the following figure(Fig 17), the control paths are usually flop-synchronized while the synced-in controlsignals are used to synchronize the data paths. Here, these data paths use acontrolled synchronizer MUX for crossing clock domains. These control MUXs aresometimes called D-MUX, MUX synchronizer, or sync MUX.

Figure 17: MUX synchronizers

The MUX synchronizer has the following functional requirements to ensure correct

results.sready must be stable for m+1 number of destination clock cycles(modeled by property p_stability as explained in the section "Flip-flopSynchronizers").data should remain stable in the destination clock domain during the datatransfer phase (indicated by the time dready is asserted in dclk domainand until dready deasserted in dclk domain).

ImplementationStability of Dataproperty p_data_stable; disable iff (drst) @( dclk) ((dready) |=> ($stable (data) || (!dready)); endpropertyA_p_data_stable: assert property (p_data_stable);

Handshake Synchronizers (Push)DescriptionThere are different types of handshake synchronizers in practice, but most comedown to the fundamental working principle of synchronizing a single-bit request intothe destination clock domain and waiting for a synchronized version of theacknowledge to come back. The differences in the architecture of the handshakesynchronizers take place because of the higher level protocols for the associatedinterfaces, data management, etc.The handshake synchronizers use two m-flip-flop synchronizers to generate requestand acknowledge signals. The associated properties are given as follows.

Input Data Stability for the m-flip-flop Synchronizers - Input data valuesmust be stable for m+1 destination clock edges (Re-use of the assertion in6.a)Protocol check - The sender and the receiver should follow the handshakeprotocol correctly.Data Stability - The data must be present when request is asserted on thedestination and remain stable until the acknowledgment is generated.

Figure 18: Handshake synchronizers

ImplementationThe following assertions cover the proper use of the m-flip-flop synchronizers, thehandshake protocol, and the corresponding data stability.

1. Input Data Stability for the m-flip-flop synchronizers

Request signal (sreq) of the sender and Acknowledgement signal (dack) must bestable for m+1 'dclk' and 'sclk' cycles respectively as implemented in the section "Flip-flop Synchronizers".2. Protocol checka. The sender should continue to assert the sreq signal until sack is asserted at thesource clock (sclk) domain.b. The sender should not assert a new request (sreq) until the acknowledgement forthe previous transfer is de-asserted in the source clock (sclk) domain.A SVA property that covers the above two checks is given as follows.property src_conformance (clk, rst, ssig, dsig); disable iff (rst) @( clk) ssig && !dsig |=>ssig; endpropertyA_src_conformance_req: assert property (src_conformance (sclk, srst, sreq, sack));A_src_conformance_new_req: assert property (src_conformance (sclk, srst, !sreq, !sack));

Similar properties for the destination clock domain (dclk) are given as follows.- The receiver should continue to assert the dack signal till dreq is asserted at thedestination clock (dclk) domain.- The receiver should not assert a new acknowledgement (dack), until a new requestis received in the destination clock (dclk) domain. A SVA property that covers the above two checks is given as follows.property dest_conformance (clk, rst, ssig, dsig); disable iff (rst) @( clk) ssig |=>dsig; endpropertyA_dest_conformance_req: assert property (dest_conformance (dclk, drst, dreq, dack));

A_dest_conformance_new_req: assert property (dest_conformance (dclk, drst, !dreq, !dack));3. Data stability- The receiver should continue to receive stable data till it asserts theacknowledgment.The following SVA property implements the above two scenarios.property data_stability (clk, rst, dreq, dack, data); disable iff (rst) @( clk) (dreq && !dack) => $stable (data);endpropertyA_data_stability_dest: assert property (dest_stability (dclk, drst, dreq, dack, data));The checks for Pull synchronizers are similar.

Dual Clock FIFO SynchronizersDescriptionAnother common CDC synchronization circuit, which is used when the high latency ofthe handshake protocols cannot be tolerated, is the dual-clock asynchronous FIFO asshown in Fig 19. Although many implementation variations exist, the basic operationis the same; data is written into a dual-port RAM block from the source clock domainand the RAM is read in the destination clock domain. Gray-coded read and writepointers are passed into the alternate clock domain (using two m-flip-flopsynchronizers) to generate full and empty status flags. The following properties aregenerated for the dual-clock asynchronous FIFO:

The producer never writes when the FIFO is full.The consumer never reads when the FIFO is empty.Read and Write pointers must be gray-coded at source.Checks for data integrity (FIFO preserves Order and Data Value).

Figure 19: FIFO Based Synchronizer

Implementation

The following SVA code provides a possible implementation of these checks. Thep_data_integrity assertion starts a new thread with a unique cnt value wheneverwdata is written to the FIFO and checks the rdata value against the local data variablewhenever the corresponding read occurs. The first_match is required inp_data_integrity to ensure the property checks rdata on the first occurrence of a readwith the corresponding cnt, otherwise it waits for ever for a rdata match at the rcntvalue. You should create a module M, which contains the assertions. It is then boundto the nearest top-level module instance containing the FIFO code.No Load on Full & No Read on Emptyproperty p_bad_access(clk, inc, flag);@( clk) inc |-> !flag;endproperty : p_bad_access//-- Property for bad write accessA_p_bad_access_write: assert property (p_bad_access (wclk,winc,wfull));//-- Property for bad read accessA_p_bad_access_read: assert property (p_bad_access (rclk,rinc,rempty));Order and Data Preservation//- The following code mimics the grey coded read and write pointers. If you have//- those pointers automatically identified from the design, this is not requiredbit [$bit (waddr)-1:0] rcnt=0, wcnt=0;always @(posedge wclk or negedge wrst_n) begin if (wrst_n) wcnt (rdata == data));endproperty : p_data_integrity

A_p_data_integrity: assert property (p_data_integrity);

Gray Code Encoding for Vector Control SignalsDescriptionThis check addresses multi-bit signals (bit vectors or a collection of individual signals)that originate in one clock domain with the clocking event sclk and then re-convergein another clock domain with the clocking event dclk without using any of the abovehandshake-based synchronization schemes. Such signals must all have m-flip-flopsynchronizers and in addition they must be Grey-code encoded before entering thesynchronizers. In this way, when there is a change from one state of the multi-bitsignal to another, only one bit changes at a time. It ensures that the destination sidewill not sample inconsistent state values due to different skews and meta-stabilitydelays on each bit. The Gray code may be decoded on the destination side, after theindividual synchronizers.

Figure 20: Multi-bit Data Transfer

Once such multi-bit signals are identified, the purpose of the function checks is toverify that state changes on the source side before entering the bit synchronizersfollow the Gray code.

ImplementationEach individual m-flip-flop synchronizer must satisfy the signal stability propertiesindicated in 1.1.2. In addition, the Gray code assertion verifies that whenever there isa change of value on data_in the next value differs from the preceding one only in onebit. The vector data_in is formed by concatenating all the variables that are part of themulti-bit signal.property p_gray_coded (clk, rst,data); disable iff (rst) @( clk) !$stable (data) |-> ($onehot (data ^ $past (data)); endpropertyA_p_gray_coded: assert property (p_gray_coded (dclk, rst, din));

In the following section, you will read how Leda generates these assertions and howto use these assertions for verification.

CDC AEP Rule UsageClock Domain Crossing is a global problem and Leda currently has an effectivesolution for CDC verification. In this section, the CDC rules that generate assertionsfor verifying functionality of each of the CDC synchronizer recognized in the design(NTL_CDC06, and NTL_CDC14 - NTL_CDC16) are elaborated. In addition, there isa rule NTL_CDC08, which checks for the correct implementation of grey coding foreach vector CDC control signal detected in the design.The purpose of adding these five rules is to provide the following information:

NTL_CDC06 - Indicates that FF synchronizers have been used in thedesign. For each of these FF synchronizers, Leda generates assertion forchecking the signal stability property of the associated CDC control signal.NTL_CDC08 - Indicates that vector CDC control signals have been usedin the design. For each of such vector CDC control signal, Leda generatesassertion for checking whether the associated vector has been graycoded.NTL_CDC14 - Indicates that MUX synchronizers have been used in thedesign. For each of such MUX synchronizers, Leda generates assertionsfor checking signal stability of the associated control and data signals.NTL_CDC15 - Indicates that Handshake (Push/Pull) synchronizers havebeen used in the design. For each of such Handshake synchronizers,Leda generates assertions for checking signal stability of the associatedcontrol and data signals. In addition, it generates assertions for checkingthe correctness of the associated handshake protocol.NTL_CDC16 - Indicates that FIFO synchronizers have been used in thedesign. For each of such FIFO synchronizers, Leda generates assertionsfor checking empty/full criterion of the associated FIFO. In addition, itgenerates assertions for checking the (a) data signal integrity of the FIFO,and (b) gray coding of the FIFO read/write pointers.

Furthermore, the detailed structural analysis statistics for the CDC synchronizers(such as the numbers, locations etc.) can be accessed in the following ways:

While using Tcl mode (switch leda +tcl_shell), there is a command called'report_cdc_info', which displays all types of detected CDC structures.There are 7 rules (NTL_CDC01, NTL_CDC01_0, NTL_CDC01_1, ...,NTL_CDC01_6) which when selected displays all types of CDCstructures (synchronized, unsynchronized) detected in a design by Leda.

The section "CDC Tcl Interface" provides details of the current CDC Tcl interface.Additionally, each of the CDC assertion specific rules NTL_CDC14 - NTL_CDC16also provides signal specific information about the CDC synchronizers. An example

is provided in the section "CDC Analysis".

Naming Convention for Automatically GeneratedCDC AEP FilesFor each of the rules specified in previous section, Leda generates a separateassertion file. This file contains the template/definition for the associated assertion.The naming convention of the assertion files (also definitions) follows the specificissue for which the assertion has been generated. For example,'aep_signal_stability.v' file contains assertion definition for checking the control signalstability. The generated file names along with their purposes are given as follows:

aep_signal_stability.v - Checks control signal stability.aep_mux_data_signal_stability.v - Checks data signal stability of a MUXsynchronizer.aep_handshake_data_signal_stability.v - Checks data signal stability of aHandshake synchronizer.aep_handshake_protocol_check.v - Checks handshake protocol checksfor a Handshake synchronizer.aep_fifo_validate_assertions.v - Checks fifo properties (full/empty, dataintegrity) for a FIFO synchronizer.

Each of these assertion definition files are generated only once. As every complexsynchronizer (MUX, FIFO, and Handshake) uses FF synchronizers for synchronizingthe control signals, aep_signal_satbility.v is also re-used for each of them.

Binding the Assertion Definitions to the DesignThe generated assertion definitions are attached to the design signals using a set of'bind' statements. These bind statements are generated in a separate file named'leda_top_properties.v'. As there can be multiple instances of a specific synchronizer,for each of these instances, a separate bind statement is generated. The instancename of the assertion definitions (used in the bind statements) is numbered.The general idea for generating properties is to use prepackage modules containingassertions and bind them to the verified design. The bind should try to bind the lowestpossible module in the design hierarchy in order to allow reduction of the design sizefor the formal tool. The bind command will have the general following syntax:bind #( ) ( );where, is of the form: i__For example if there are three FF synchronizers detected in a design, there would beone control signal stability assertion definition and three separate bind statements

generated with three unique assertion instances namely - i_NTL_CDC06_1,i_NTL_CDC06_2, and i_NTL_CDC06_3.Sometimes, if you want to avoid explosion of the simulation time or Magellan runningtime, you can also bound the number of properties that are generated. Theset_max_properties command placed in the design configuration file allowscontrolling this number. This command is not specific to the CDC Manager; it is part ofthe property generation manager.set_aep_max_properties -value max_value

Using Generated Assertions in VCS and MagellanThe generated assertions can be verified on the design using (1) VCS (simulationbased verification) or (2) Magellan (formal verification). To simplify building of theassertions, a file (named leda_prop_file.lst) containing the list of automaticallygenerated files is created. As a result, you only need to attach file 'leda_prop_file.lst'to the associated checker tool.The set of assertion related files are generated in a directory naming 'ForMG'. Thisdirectory is located by default in .leda_work or in case .leda_work is missing in the'run directory.Moreover, for Magellan, a project file template (named 'LedaMgPrjFile.prj') is alsogenerated. You (sometimes) may need to add additional information like - the clockperiods, the reset configurations etc. in this template. You don't need to use anyswitch for generating the assertions. The assertions and the associated files arecreated by default.

Failure DebuggingIn case of any CDC assertion violations for a design, you need to use the debuggingaids of the associated checker (VCS/Magellan) for finding the root cause of thefailure.

Using Property Generation for CheckingSome of the CDC rules can identify certain situations and generate properties fordynamic and formal verification. Different rules generating properties are written in thesame SystemVerilog file LEDA__properties.sv. You can control the number ofproperties generated by the CDC rules using the following command:Syntaxset_aep_max_properties -value max_valueArguments-value Specify the value to control the number of properties generated by CDCrules.The general idea for generating properties is to use prepackage modules containing

assertions and bind them to the verified design. The bind tries to bind the lowestpossible module in the design hierarchy in order to allow reduction of the design sizefor the formal tool. The bind command will have the general following syntax:Syntaxbind #() ()where, is of the form__

Assertion LibraryInstead of generating assertions or properties for each check, Leda uses an assertionlibrary packaged with the tool. Each check now binds to the module containing theprepackaged property. This library is a set of modules containing the necessaryproperties. These modules may also have parameters to set different options or bitwidth.

Data Signal StabilityThe following assertion is generated for the condition that data signals must be stablewhile the control signal is asserted (from source of control path asserted until target ofcontrol path deasserted):bind top aep_assert_data_stable #( 2, "Error : CDC data signal S must be stable while control signal is asserted") CDC06_test_v_40 (ck2, rst, DataIn, CtrlSource, CtrlTarget);

Grey CodingThe following assertion is generated by the rule that checks if two or more signals are gray coded (for example, multi-bit control signals).bind top aep_assert_gray_coding #( BitWidth, "Error : multibit control signals must be gray coded") CDC08_test_v_40 (ck1, rst, CtrlSig );

Detailed Explanations for Rules NTL_CDC05 andNTL_CDC07Both of these rules check a common CDC scenario - called the "re-convergence ofsynchronized signals".As explained earlier, loss of correlation can also occur when two apparentlyindependent signals are synchronized separately, but ultimately fed into the samelogic. This scenario, sometimes dubbed re-convergence, is especially difficult todetect by manual inspection of the synchronization schemes during design review.Another form of correlation loss can occur when a signal has fan-outs into multiple

synchronizers. The two branches of the signal can have different delays; the electricaland routing effects can also cause different delays in the clocks going to the twosynchronizers. Therefore, if the two synchronizers sample their inputs at differenttimes then the two copies of the signal can be skewed by a cycle and no longercorrelated.To prevent these correlation loss scenarios, Leda has two CDC rules that confirm thatthere is no "re-convergence of synchronized signals" in the design.The first one "NTL_CDC05" confirms that two signals synchronized in two differentsynchronizers (thus forming two different CDC elements) never converge.On the other-hand "NTL_CDC07" confirms that CDC paths synchronized by the samesynchronizer (thus grouped in a single CDC element) never converges after beingsynchronized in the target clock domain.Examples:For CDC05 rule, two one bit signals are synchronized by two 2-FF synchronizers intwo different target domains (CLK2 and CLK3), thus forms two different CDCelements. After the synchronization is done, these two signals converge in an ANDgate.For CDC07 rule, a single bit signal has fan-outs two 2-FF synchronizers. After thesynchronization is done (in the single target domain CLK2 thus forming a single CDCelement), these two signals converge in an AND gate. The HDL codes and relatedCDC error messages are given as follows.For more information about these rules, see the chapter "Clock Domain CrossingRules".

CDC Tcl InterfaceThe following is the command reference information for built-in Tcl commands thatyou can use to manage the CDC rules:

set_cdc_ignored_pathUse the set_cdc_ignored_path command to specify a path to be ignored by CDCanalysis.Syntaxset_cdc_ignored_path [-from source_ff_name] \[-to target_ff_name] Arguments-from Specify the source flip-flop name.-to Specify the target flip-flop name.Although -from and -to are optional, at least one of the options must be used. If you

don't specify any one of the options, then it's value is considered as 'any'. Forexample:set_cdc_ignored_path -from top.rstFor the above command, any CDC path from top.rst will be ignored.

set_cdc_synchronizerUse the set_cdc_synchronizer command to specify a synchronizer cell.Syntaxset_cdc_synchronizer -name name \[-synchro_type type [-synchro_parameters {..} ] ]Arguments-name Specify the name of the synchronizer cell.-synchro_type Specify the synchronizer type. It can take one of the following values:simple (for flip-flop synchronizers).logic (for logic synchronizers).complex (for complex synchronizers).fifo (for fifo synchronizers).handshake (for handshake synchronizers).-synchro_parameters Specify the parameters corresponding to the synchronizer.

For all the specified synchronizers, the parameters are a list of strings that specifysome values. The following table lists the parameters that are applicable for varioussynchronizers.

Table 2: Parameters of different synchronizersParameters applicable

to all synchronizersParameters applicableto FIFO synchronizer

Parameters applicable tohandshake synchronizer

-source_clock -source_clock -source_clock-target_clock -target_clock -target_clock

-write_signal-handshake kind (can bepushhanshake orpullhandshake)

-read_signal -transmit_signal-fifo_full -receive_signal-fifo_empty-write_reset_signal-write_read_signal

-data_signal

set_cdc_groupUse the set_cdc_group command to override the automatic CDC inference. Thiscommand enables you to create a CDC element and specify additional informationlike synchronization type. In other words, it allows a complete specification of theCDC information from you. This command is generated by the dump mode of theCDC. After CDC inference in dump mode, all the inferred information is dumpedusing the set_cdc_group command. If you want to modify the inferred information orgrouping of the different paths, you need to edit the dumped file and adapt theinformation.The rules concerning reconvergent paths and gray coding of control paths are highlydependent on the grouping. So, make sure that the groups are formed correctly. Inaddition to the automatic inference algorithm and the possibility to definesynchronizer, Leda also offers the flexibility to fully customize the CDC information.The CDC inference engine first uses the information from the set_cdc_groupcommand. If this information is incomplete, then it tries to automatically complete it.When the command set_cdc_group contains only the -paths directive and no -synchronizer information, then the synchronizer is recognized automatically.Similarly, if you provide only the synchronizer type information, then the parameters(specially for fifo and handshake) is computed automatically.Syntaxset_cdc_group -name group_name \[-synchro_type type [-synchro_parameters {...} ] ] \-paths { {s1 t1} {s2 t2}...{sn tn} }Arguments-name Specify the name of the synchronizer cell.-synchro_type Specify the type of synchronizer. It can take the following values:simple (for flip-flop synchronizers).logic (for logic synchronizers).complex (for complex synchronizers).fifo (for fifo synchronizers).handshake (for handshake synchronizers).-synchro_parameters Specify the parameters corresponding to the synchronizer.-paths Specify the set of paths, which is just a collection of tuples representingdifferent paths.

set_cdc_input_delayUse the set_cdc_input_delay command to specify a clock that controls the modulepins or ports specified with the option -pin_port_list. This helps you to analyze theCDC issue in a given module and focus on debugging in that module.

Syntaxset_cdc_input_delay -clock user_clock_name -delay_value delay_value \-pin_port_list {PIN_PORT_LIST}Arguments-clock Specify the clock name.-delay_value Specify the delay value. Leda actually discards this value and so you can specify any value.-pin_port_list Specify the list of pins or ports that the clock controlsFor example, if you have a module SYNCHHRONIZER_MODULE that contains thesynchronizer as follows:module SYNCHRONIZER_MODULE (out_data, in_data, clk);You can instantiate this module in a design and specify a new clock, say "clk1" thatcontrols the pin in_data. To avoid debugging the whole design and to just focus onthis synchronizer module, you need to specify the set_cdc_input_delay command inthe leda_clock_file.tcl as follows:set_cdc_input_delay -clock clk1 -delay_value 1 -pin_port_list {SYNCHRONIZED_MODULE.in_data}

set_cdc_output_delayUse the set_cdc_output_delay command to specify the relationship between anoutput pin and a clock pin of a hard IP cell.

create_cdc_clockUse the command to specify a given pin of the cell as a clock pin of a hard IP cell.

ExampleThe usage of the commands is as follows:You can specify hard IP blocks and provide information about the relation betweenclocks and data ports of the block. A cell which is instantiated from a library and doesnot contain any statement (only port definition) is considered a hard IP cell. In suchcase, for efficient CDC checking, you can specify the relationship between data pinsand clock pins.The command to specify a given pin of the cell as a clock pin of a hard IP cell is asfollows:create_cdc_clock -name clock_name source_objects

The following commands allow creating a relationship between a clock pin and adata pin.set_cdc_input_delay -clock clock_name delay_value port_pin_listset_cdc_output_delay -clock clock_name delay_value port_pin_listIf such information is provided to the checker then efficient CDC checking can beperformed even on designs using hard IP. Else, no checking will be possible since noconnectivity information is available.For example, the previous illustration shows a hard IP block with two clocks, two input

ports, and two output ports:Here the connection from O1 to the D input of the third flip-flop has a CDC issue thatcould be detected if you provide the following relations: create_cdc_clock -name CK1 Top.HardCell.CK1 create_cdc_clock -name CK2 Top.HardCell.CK2 set_cdc_output_delay -clock CK1 10 Top.HardCell.O1 set_cdc_output_delay -clock CK2 10 Top.HardCell.O2If the cell has only one clock, all the pins will be considered to be controlled by thisclock. The clock will be detected automatically by the clock inference if it is connectedto other clock signals in the design.

extract_cdc_infoUse the extract_cdc_info command to run the CDC inference within the Tcl shellmode in order to refine the different parameters for this inference.Syntaxextract_cdc_infoYou need to execute this command only after elaboration. You can then use thereport_cdc_info command to visualize the inferred CDC elements. You may executethis command many times, but it is important to run the clear_cdc_info commandbefore any call.

report_cdc_infoUse the report_cdc_info command to print the inferred CDC elements on the consoleor to a file.Syntaxreport_cdc_info [-file filename]Arguments-file Specify the file name.This command reports all the CDC elements set using the command set_cdc_groupsyntax. This allows you to visualize the inferred information.When you redirect the output of this command to a file, the console does not displayany information. You can customize and source this file from the tcl_shell or the design_config file tohave a clean CDC inference.

clear_cdc_infoUse the clear_cdc_info command to clear all the inferred CDC informations.

Syntaxclear_cdc_infoIn the Tcl shell mode, you may be interested to try several parameters until you getthe correct CDC inference. In order to do this incrementally, you can call theclear_cdc_info command to reset everything and start the inference with newparameters.

set_cdc_parameterUse the set_cdc_parameter command to specify a value for the parameters for CDCinference.Syntaxset_cdc_parameter [-parameter parameter_name] [-value value]Arguments-parameter Specify the parameter.-value Specify the value for the parameter.The following parameters shall be used with this command:

NB_FFS_FOR_SYNCHRONIZER - Use this parameter to specify thenumber of flip-flops to be used for synchronization. The minimum value ofthis parameter is 2. The default value is 2.ALLOW_BUF_INV_IN_SYNC_FFS - This parameter is used to specify ifthe path between the synchronizing flip-flops contain buffers or inverters. Ifset to 1, the path between the synchronizing flip-flops may contain buffersor inverters. The default value is 1.MAX_NB_PATHS - This parameter is used to specify the maximumnumber of path allowed in a valid CDC Element. Above this number, theCDC element is marked invalid and not taken into account by any CDCchecks.MAX_NB_DISPLAYED_PATHS - This parameter is used to specify themaximum paths to be displayed in a single CDC violation. The defaultvalue is 10.MAX_SYNCHRONIZATION_DEPTH - The CDC Inference algorithmexplores the influence of control signals to find the controlled paths. Thisparameter is used to controls the maximum sequential depth to beexplored by Leda. The default value of this parameter is set to 4, to allowLeda to detect all kinds of synchronizers. In a design using logicsynchronizers, it is recommended to limit this number to 2 or 1.

1 Clock Domain CrossingOverviewBackgroundClock domainMeta-stability

Synchronization TechniquesSynchronization of Control Signals with 2-FF SynchronizersInput Data Stability to Avoid Data LossGray Encoding to Avoid Data Incoherence (For Vector CDC Control Signals)Synchronization of CDC Data SignalsPassing Data through MUX SynchronizerHandshaking Data between Clock DomainsPassing Data by FIFO between Clock DomainsUser-defined Synchronizers

CDC AnalysisStructural Analysis to Identify CDC Signals and Appropriate SynchronizersStructural Analysis to Identify Structural Defects Before and After SynchronizationConvergence in the Crossover PathDivergence in the Crossover PathDivergence of Meta-stable SignalRe-convergence of Synchronized SignalsDetermination and Validation of Appropriate Properties for Every Synchronizer

Leda - CDC FlowAutomatically Generated CDC AssertionsFlip-flop SynchronizersDescriptionImplementationMUX SynchronizersDescriptionImplementationHandshake Synchronizers (Push)DescriptionImplementationDual Clock FIFO SynchronizersDescriptionImplementationGray Code Encoding for Vector Control SignalsDescriptionImplementation

CDC AEP Rule UsageNaming Convention for Automatically Generated CDC AEP FilesBinding the Assertion Definitions to the DesignUsing Generated Assertions in VCS and MagellanFailure DebuggingUsing Property Generation for CheckingAssertion LibraryData Signal StabilityGrey Coding

Detailed Explanations for Rules NTL_CDC05 and NTL_CDC07CDC Tcl Interfaceset_cdc_ignored_pathset_cdc_synchronizerset_cdc_groupset_cdc_input_delayset_cdc_output_delaycreate_cdc_clockextract_cdc_inforeport_cdc_infoclear_cdc_infoset_cdc_parameter