Structural Phase..............................................................................................

3
CDC Structural Rules....................................................................................3
Scheme Detection Flow................................................................................7
User Defined Synchronization Scheme......................................................8
User defined Tcl Command.....................................................................8
Pre-defined synchronizer templates.......................................................9
NDFF...................................................................................................9
NDFF_BUS.........................................................................................10
Pulse (Fast to Slow)...........................................................................11
Edge..................................................................................................12
MUX_NDFF.........................................................................................14
MUX_PULSE.......................................................................................16
Handshake........................................................................................18
FIFO...................................................................................................20
Automatic Scheme Detection..................................................................22
Automatic Scheme Detection Tcl Command.........................................22
Automatic Scheme Detection Flow.......................................................22
Manual Scheme Detection.......................................................................23
Functional Phase............................................................................................24
Protocol Checks TCL Commands.................................................................24
NDFF Protocol Checks.................................................................................25
Data Stability...........................................................................................25
Old Property Template for Data Stability..............................................25
New Property Template for Data Stability.............................................25
Pulse (Fast to Slow) Protocol Checks...........................................................27
Data Stability...........................................................................................27
Input Pulse Width.....................................................................................27
Output Pulse Width..................................................................................27
MUX_NDFF Protocol Checks........................................................................28
Control Path Stability...............................................................................28
Data Path Stability During Transfer.........................................................28
Old Property Template for Data Stability During Transfer.....................28
MUX Stability Protocol Problem............................................................29
New Property Template for Data Stability During Transfer...................29
MUX_PULSE Protocol Checks.......................................................................30
Control Path Stability...............................................................................30
Data Path Stability During Transfer.........................................................30
Input Pulse Width.....................................................................................31
Output Pulse Width..................................................................................31
Handshake Protocol Checks........................................................................32
Ack and Req Stability...............................................................................32
Data Stability During Transfer...............................................................321
Handshake Protocol.................................................................................33
FIFO Protocol Checks..................................................................................34
Read and Write Stability..........................................................................34
No Load on Full and No Read on Empty...................................................34
Read and Write Pointers Gray Coding......................................................35

Structural Phase
This section describes the structural phase of the JG-CDC app,
presenting the structural rules that are considered on the analysis and the
synchronizer scheme detection flow.

CDC Structural Rules

The user can define rules that the schemes must comply with. It is
possible to have different rules for the same design, for example:
different rules for different clock domains. If the user does not create
any rule a default rule is used.
The rules must be configured on SETUP phase.
CDC Path:

CDC Pair: A_reg-B1_reg

Source Unit: A_reg
Destination Unit: B1_reg
Path rule 1:
cdc_pair_logic <Wire|Buf|Logic>

Path rule 2: sync_chain_logic <Wire|Buf|

Logic|latch>

Path rule 3: n_min <int>

Path rule 4: n_max <int>

Path rule 5: same_clock_phase <true |

false>

Path rule 6: sync_chain_fanout <true |

false>

Scheme Detection Flow

User Defined Synchronization

Scheme

The user specifies a module that defines a scheme. During automatic scheme
detection the module is mapped to all its instances and one scheme to each
instance is automatically added and associated to the CDC Pairs.
The configuration of user defined schemes must be done on SETUP phase.
The User Defined Scheme can be a well-known and defined pattern (NDFF,
NDFF_BUS, Pulse, Edge, MUX_NDFF, MUX_PULSE, Handshake or FIFO) or even
a different custom pattern.
For user defined schemes added using a pattern the tool is able to generate protocol
checks properly, for custom schemes the tool wont generate any protocol check.

User defined Tcl Command

% check_cdc scheme add (ndff | ndff_bus | pulse | edge | mux_ndff | mux_pulse |
handshake | fifo | custom) connect {{formal_signal}+} module module_name

NDFF required formal signals: data, dout

NDFF_BUS required formal signals: data, dout
MUX_NDFF required formal signals: data, dout, sready, dready
MUX_PULSE required formal signals: data, dout, sready, dready, enable
FIFO required formal signals: wfull, winc, wptr, wdata, rempty, rinc, rptr, rdata
Handshake required formal signals: data, dout, sreq, dreq, dack, sack
Pulse required formal signal: data, dout
Custom required formal signals: dout

Pre-defined synchronizer templates

NDFF
This type of synchronizer is used to synchronize a single bit signal from the
source domain to the destination domain.

NDFF Parameters:
Name

Type

Mandatory

data

signal

true

dout

signal

true

drst*

signal

false

dclk*

signal

false

* If the tool could not infer, the user has to provide these
parameters.

10

NDFF_BUS
This type of synchronizer is used to synchronize a wide signal from the
source domain to the destination domain.

NDFF_BUS Parameters:
Name

Type

Mandatory

data

signal

true

dout

signal

true

drst*

signal

false

dclk*

signal

false

* If the tool could not infer, the user has to provide these
parameters.

11

Pulse (Fast to Slow)

This type of synchronizer is used to synchronize a single bit pulse signal
that was generated on a faster domain to a slower destination domain.

Pulse Parameters:
Name

Type

Mandatory

data

signal

true

dout

signal

true

enable

signal

true

sclk*

signal

false

srst*

signal

false

* If the tool could not infer, the user has to provide these
parameters.

12

Edge
This type of synchronizer is used to detect a change on a single bit pulse
signal that comes from a slower source domain to a faster destination
domain.

Rising Edge Active High

Rising Edge Active Low

Falling Edge Active High

Falling Edge Active Low

13

Name

Type

Mandatory

data

signal

true

dout

signal

true

sclk*

signal

false

srst*

signal

false

drst*

signal

false

dclk*

signal

false

Edge

Parameters:

* If the tool could not infer, the user has to provide these
parameters.

14

MUX_NDFF
This type of synchronizer is used to synchronize a wide data path using a
NDFF to synchronize the single bit control signal. This control signal can be
the selector pin of a MUX gate or can be the enable condition of a clock
gating.

15

Name

Type

Mandatory

data

Signal

true

dout

Signal

true

sready

signal

true

dready

signal

true

drst*

signal

false

dclk*

signal

false

MUX
_ND
FF

Parameters:

* If the tool could not infer, the user has to provide these
parameters.

16

MUX_PULSE
This type of synchronizer is used to synchronize a wide data path using a
Pulse to synchronize the single bit control signal. This control signal can be
the selector pin of a MUX gate or can be the enable condition of a clock
gating.

17

 MUX_PULSE Parameters:
Name

Type

Mandatory

data

signal

true

dout

signal

true

sready

signal

true

dready

signal

true

sreday_in (enable)

signal

true

drst*

signal

false

dclk*

signal

false

* If the tool could not infer, the user has to provide these
parameters.

18

Handshake
This synchronizer is used to synchronize a wide data from the source
domain to the destination domain using the well-defined handshake protocol.

19

 Handshake Parameters:
Name

Type

Mandatory

data

signal

true

dout

signal

true

sreq

signal

true

dack

signal

true

dreq

signal

true

sack

signal

true

dCtrl

signal

false

sCtrl

signal

false

srst*

signal

false

sclk*

signal

false

drst*

signal

false

dclk*

signal

false

* If the tool could not infer, the user has to provide these
parameters.

20

FIFO
This synchronizer is used to synchronize a wide data from the source
domain to the destination domain using the well-defined FIFO protocol.

21

Name

Type

Mandatory

rdata

signal

true

wptr

signal

true

rptr

signal

true

wfull

signal

true

rempty

signal

true

winc

signal

true

rinc

signal

true

wdata

signal

false

srst*

signal

false

sclk*

signal

false

drst*

signal

false

dclk*

signal

false

FIFO Parameters:

22

* If the tool could not infer, the user has to provide these
parameters.

23

Automatic Scheme Detection

The tool is capable of automatic detect NDFF, MUX, Handshake* and

FIFO* schemes and user defined modules.
The first step on the automatic scheme detection is to map all User
Defined scheme modules into instances, then it tries to find a scheme
to each CDC Pair that is not covered by any scheme.
The tool tries to find the schemes from the most complex to the
simplest.

Automatic Scheme Detection Tcl Command

% check_cdc scheme find

Automatic Scheme Detection Flow

Map user defined
schemes module to
design instances
and automatically
create the schemes

Run automatic FIFO

detection

Run automatic
Pulse and Edge
detection

Run automatic
NDFF detection for
single bit pairs

Run automatic
Handshake
detection

Run automatic MUX

detection

Run automatic
NDFF detection for
wide pairs

24

Manual Scheme Detection

In the case of a scheme that was not automatically detected by the

tool and there is no module that represents the scheme, the user can
manually define a synchronization scheme that will be associated with
the CDC Pairs that it covers. The user must provide all the necessary
relevant signals, which are the same as for user defined scheme.
The only time the user needs to do this is if there is no instance that
represents the scheme, because if this is the case he should use the
User Defined scheme.
The Manual detection is the last option, so first the user should try the
automatic detection, and in the case it fails he can manually add one
specific synchronizer.

Manual Scheme Detection Tcl Command

% check_cdc scheme add (ndff | ndff_bus | pulse | edge | mux_ndff |
mux_pulse | handshake | fifo | custom) connect {{formal_signal}+}

25

Functional Phase
This section describes the functional phase of the JG-CDC app,
presenting the protocol checks that are generated for each type of
synchronizer scheme.

Protocol Checks TCL Commands

%check_cdc -protocol_check ( -generate | -verify | -export [-file

file_name] )
-generate: Automatically create the protocol checks
-verify:
Validate all protocol checks created
-export:
Export the protocol checks to a file

Generates and verify protocol checks for all CDC Schemes already
detected
Only Schemes that passed through Structural Analysis without
violations
Based on property templates

26

NDFF Protocol Checks

Data Stability
Functionally checks if the signal from the source clock domain remains stable
long enough to be captured properly in the destination clock domain.

Old Property Template for Data Stability

Given a CDC pair (d1, d2) with clock clk1, data d1 and reset r1 and a
flop with clock clk2, data d2 and reset r2, the current data stability
property can be written like:
assert @(posedge clk2) disable iff (r2) (!$stable(d1)) |=>
$stable (d1) [*n]
n is the number of flops in the nDFF synchronizer
It basically translates into:
Once data d1 changes, it should not change again for n cycles
Its been pointed that this property is too restrict

New Property Template for Data Stability

Given a CDC pair (d1,d2) with clock clk1, data d1 and reset r1 and and
clock clk2, data d2 and reset r2, the new data stability property is:
assert @(posedge :global_clock) disable iff (r1) !$stable(d1) |=>
$stable(d1) until_with $rose(clk2)
It basically translates into:
Once data d1 changes, it should not change again until we have
a clock event in the destination domain, because :global_clk is
the fastest clock in the design.
The data must stay stable during at least one setup-hold time on
the destination

This doesnt work if clk2 is the fastest clock in the system, as no $rose
is detected. In that case, it is sufficient to guarantee that that d1 is
stable for at least one more cycle.
assert @(posedge clk2) disable iff (r1) ##1 !$stable(d1) |=>
$stable(d1)

27

Which means:
Once the data d1 changes, it must not change for at least one
more cycle in the destination domain.
The same way, the data must stay stable during at least one
setup-hold time on the destination.
Example 1: Destination clock slower than the source clock

Example 2: Source and destination clock in the same rate

property p_stability
disable iff (drst)
@(posedge :global_clock) !stable(data) |=> $stable(data)
until_with $rose(dclk)
endproperty
property p_stability_fastest (case the destination clock is
fastest)
@(posedge :global_clock) disable iff (drst) ##1 !
stable(data) |=> $stable(data)
endproperty

28

Pulse Protocol Checks

Data Stability
Functionally checks if the signal from the source clock domain remains stable
long enough to be captured properly in the destination clock domain.
property p_stability
disable iff (drst)
@(posedge :global_clock) !stable(sready) |=> $stable(sready)
until_with $rose(dclk)
endproperty

Input Pulse Width

Functionally checks if the input pulse is always one source clock cycle wide.
property p_pulse_width
@(posedge sclk) disable iff (srst)
sready_in |=> !sready_in;
Endproperty

Output Pulse Width

Functionally checks if the output pulse is always one source clock cycle wide.
property p_pulse_width
@(posedge dclk) disable iff (drst)
dready |=> !dready;
Endproperty

Toggle Circuit
Functionally checks if the toggle circuit works properly.
property p_toggle_circuit
@(posedge sclk) disable iff (srst)
sready_in |=> $changed(sready);
Endproperty

29

MUX_NDFF Protocol Checks

Control Path Stability

Functionally checks if the mux select signal from the source clock domain
remains stable long enough to be captured properly in the destination clock
domain.
property p_stability
disable iff (srst)
@(posedge :global_clock) !stable(sready) |=> $stable(sready)
until_with $rose(dclk)
endproperty

Data Path Stability During

Transfer
Functionally checks if the data remains stable in the destination clock
domain during the data transfer phase

Old Property Template for Data Stability

During Transfer
property p_transfer_stable
disable iff (drst)
@(posedge dclk) ((dready) |=> ($stable (data) || (!dready));
Endproperty

30

MUX Stability Protocol Problem

The protocol check for data stability was not guaranteeing that after a
change, data remains stable until data transfer phase was
complete, i.e., a sampling edge of destination clock, respecting hold
time.
This is shown in the trace, where a simple design with a MUX
synchronizer from the crossing from Data (clk1) to mux.Dout(clk2,
twice as slow) , although respection data transfer property, still
suffers from metastability propagation in mux.Dout, when we inject

metastability in the aforementioned pair.

The trace shows that we allow Dready to be enabled and at the same
time Data changes. At this point, raising edge from cycle 7 to cycle 8,
we allow metastability to happen and PROPAGATES in mux.Dout
The protocol check should require that Data is stable also in cycle 8
hold period of Dout this does not happen.

New Property Template for Data Stability

During Transfer
property p_transfer_stable (Pclk, Prst, Pready, Pdin);
disable iff (Drst)
@(posedge :global_clock) ((dready) |=> ($stable (data)
until_with(!dready));
Endproperty

31

MUX_PULSE Protocol Checks

Control Path Stability

Functionally checks if the mux select signal from the source clock domain
remains stable long enough to be captured properly in the destination clock
domain.
property p_stability
disable iff (drst)
@(posedge :global_clock) !stable(sready) |=> $stable(sready)
until_with $rose(dclk)
endproperty

Data Path Stability During

Transfer
Functionally checks if the data remains stable in the destination clock
domain during the data transfer phase
property p_transfer_stable
disable iff (drst)
@(posedge :global_clock) ((dready) |=> ($stable (data)
until_with(!dready));
Endproperty

32

Input Pulse Width

Functionally checks if the input pulse is always one source clock cycle wide.
property p_pulse_width
@(posedge sclk) disable iff (srst)
sready_in |=> !sready_in;
Endproperty

Output Pulse Width

Functionally checks if the output pulse is always one source clock cycle wide.
property p_pulse_width
@(posedge dclk) disable iff (drst)
dready |=> !dready;
Endproperty

Toggle Circuit
Functionally checks if the toggle circuit works properly.
property p_toggle_circuit
@(posedge sclk) disable iff (srst)
sready_in |=> $changed(sready);
Endproperty

33

Handshake Protocol Checks

Ack and Req Stability

Functionally checks if the signal from the source clock domain remains stable
long enough to be captured properly in the destination clock domain.
property p_stability
disable iff (drst)
@(posedge :global_clock) !stable(sreq) |=> $stable(sreq)
until_with $rose(dclk)
endproperty
property p_stability
disable iff (srst)
@(posedge :global_clock) !stable(dack) |=> $stable(dack)
until_with $rose(sclk)
endproperty

34

Data Stability During Transfer

Functionally checks if the data from the sender remains stable until it
receives an acknowledgement from the receiver.
property p_dest_stability(Pclk, Prst, Preq, Pack, Pdata);
disable iff (drst)
@(posedge dclk) (dreq && !dack) |=> $stable (data);
endproperty

Handshake Protocol
The sender should continue to assert the Sreq signal until Sack is
asserted at the source clock (Sclk) domain.
The sender should not assert a new request Sreq until Sack for the
previous transfer is de-asserted in the source clock (Sclk) domain.
(src_req): Functionally checks if that the sender continues to assert the
request signal until it receives an acknowledgement from the receiver.
(src_req_new): Functionally checks if that the sender should not send a new
request until the acknowledgement for the previous transfer has been deasserted.
property p_src_conformance_req (Pclk, Prst, Pssig, Pdsig);
disable iff (Prst)
@(posedge Pclk) Pssig && !Pdsig |=> Pssig;
endproperty
src_req: p_src_conformance_req (Sclk, Srst, Sreq, Sack);
src_req_new: p_src_conformance_req (Sclk, Srst,!Sreq,!Sack);
The receiver should continue to assert the Dack signal till Dreq is
asserted at the destination clock (Dclk) domain.
The receiver should not assert a new acknowledgement Dack until a
new request is received in the destination clock (Dclk) domain.
(dest_conformance_req): Functionally checks if the receiver continues to
assert the acknowledgement till the request is asserted at the destination
clock domain.
(dest_conformance_new_req): Functionally checks if the receiver does not
assert a new acknowledgement until a new request is received.
property p_dest_conformance_req (Pclk, Prst, Pssig, Pdsig);
disable iff (Prst)
@(posedge Pclk) Pssig |=> Pdsig;
endproperty
dest_conformance_req: p_dest_conformance_req (Dclk, Drst,
Dreq, Dack);
dest_conformance_new_req: p_dest_conformance_req (Dclk, Drst, !
Dreq, !Dack);

35

FIFO Protocol Checks

Read and Write Stability

Functionally checks if the FIFO pointer value remains stable long enough to
be captured correctly in the destination domain.
property p_stability (PfastClk, Pclk, Prst, Pdin);
disable iff (Prst)
@(posedge PfastClk) !stable(Pdin) |=> $stable(Pdin)
until_with $rose(Pclk)
endproperty
wptr_stable: p_data_stability(FastClk, Sclk, Srst, Wptr);
rptr_stable: p_data_stability(FastClk, Dclk, Drst, Rptr);

No Load on Full and No Read on

Empty
No write on full functionally checks if there is no write to the FIFO when it is
full and no read on empty functionally checks if there is no read from the
FIFO when it is empty.
property p_bad_access(Pclk, Pinc, Pflag);
@(posedge Pclk) Pinc |-> !Pflag;
Endproperty
no_write_on_full: p_bad_access (Sclk, Winc, Wfull);

36

no_read_on_empty: p_bad_access (Dclk, Rinc, Rempty);

Read and Write Pointers Gray

Coding
Functionally checks if the FIFO pointers are gray encoded (only one bit
changes at a time).
property p_gray_coded (Pclk, Prst, Pdata);
disable iff (Prst)
@(posedge Pclk) !$stable(Pdata) |-> ($onehot(Pdata ^
$past (Pdata));
Endproperty
p_wptr_gray_coded: p_gray_coded (Sclk, Srst, Wptr);
p_rptr_gray_coded: p_gray_coded (Dclk, Drst, Rptr);

37