Sei sulla pagina 1di 7

Register | Login

About Us | Newsletter Sign Up | Mobile Site

Home News Opinion Messages Video Slideshows Teardown Education EELife Events
Android

BREAKING NEWS

Automotive

Embedded

Industrial Control

Internet of Things

MCU

Medical

Memory

Open Source

PCB

NEWS & ANALYSIS: Fried Cable Sparked EE Profession

Most Recent Comments

Design How-To

Understanding Clock Domain


Crossing Issues
12/24/2007 03:00 PM EST
7 comments
Like

Tweet 1

Share

antedeluvian Rich I remember back

NO RATINGS
10 saves
LOGIN TO RATE

Saurabh Verma, Ashima S. Dabare,


Atrenta

1/28/2015
9:01:42 PM

in the late 80s early 90s when Intel


introduced a configuration package
for the 8051 mirco, running under
MSDOS. I don't think I ever ran it, but
I can't...

Introduction
SoCs are becoming more complex these days. A lot of functionality
is being added to chips and data is frequently transferred from
one clock domain to another. Hence, clock domain crossing
verification has become one of the major verification challenges in
deep submicron designs.
A clock domain crossing occurs whenever data is transferred from
a flop driven by one clock to a flop driven by another clock.

Navigate to Related Links


1. Clock domain crossing.
In Figure 1, signal A is launched by the C1 clock domain and
needs to be captured properly by the C2 clock domain. Depending
on the relationship between the two clocks, there could be
different types of problems in transferring data from the source
clock to the destination clock. Along with that, the solutions to
those problems can also be different.

What Drove CES 2015 Innovation? IP and IP Subsystems


Moore's Law Covers Human Progress
TSVs to Split More Chips: Re-Integration is the Focus
Are TSMC, UMC Affected By Taiwans Water Shortages?
Intel, Microsoft Improve Odds for AR

Traditional methods like simulation and static timing analysis alone


are not sufficient to verify that the data is transferred consistently
and reliably across clock domains. Hence, new verification
methodologies are required, but before devising a new
methodology it is important to understand the issues related to
clock domain crossings properly. Different types of clock domain
crossings are discussed here along with the possible issues
encountered in each one of them and their solutions. A new
verification methodology is then proposed which will ensure that
data is transferred correctly across clock domains.
In all the subsequent sections, the signal names shown in Figure 1
are directly used. For example, C1 and C2 imply the source and
destination clocks respectively. Similarly A and B are used as
source and destination flop outputs respectively. Also, the source
and destination flops are assumed to be positive edge triggered.
Clock Domain Crossing Issues
converted by Web2PDFConvert.com

Clock Domain Crossing Issues


This section describes three main issues which can possibly occur
whenever there is a clock domain crossing. The solutions for those
issues are also described.
A. Metastability
Problem. If the transition on signal A happens very close to the
active edge of clock C2, it could lead to setup or hold violation at
the destination flop "FB". As a result, the output signal B may
oscillate for an indefinite amount of time. Thus the output is
unstable and may or may not settle down to some stable value
before the next clock edge of C2 arrives. This phenomenon is
known as metastability and the flop "FB" is said to have entered a
metastable state.

Cartoon

Contest

December 2014 Cartoon Caption


Contest: White Smoke Is Rising!

Metastability in turn can have the following consequences from a


design perspective:
1. If the unstable data is fed to several other places in the
design, it may lead to a high current flow and even chip
burnout in the worst case.
2. Different fan-out cones may read different values of the
signal, and may cause the design to enter into an unknown
functional state, leading to functional issues in the design.
3. The destination domain output may settle down to the new
value or may return to the old value. However, the
propagation delay could be high leading to timing issues.
For example, see Figure 2. If the input signal A transitions very
close to the posedge of clock C2, the output of the destination flop
can be metastable. As a result it can be unstable and may finally
settle to 1 or 0 as depicted by signals B1 and B2.

"Remember when someone promised us change a


few years ago? That's all we have left!"
2 comments
ALL CARTOONS

Most Commented

Most Popular

124 Just Call Me 'King of the Salad People'


80 What's the Best T-Shirt for an Engineer?
64 Sound Effects Shield for Arduino: The ...
62 You May Be an Engineer If ...
51 Tired Old iPad 2 vs. Shiny New iPad Air 2
50 It's Not the Size of Your ... or Is It?
50 ESC Minneapolis 2015 Will Blow Your Mind
48 Max's BADASS Display: A Comedy of Errors
44 Recommended Reads From the Engineer's ...
44 My Tower Computer Is Dead -- Long Live My ...

Flash Poll

Is there an Internet of Things (IoT) bubble


and will it burst?
No bubble no burst: IoT is hype

2. Metastability has consequences.

Small bubble that fizzles: consumers already bored

Solution. Metastability problems can be avoided by adding special


structures known as synchronizers in the destination domain. The
synchronizers allow sufficient time for the oscillations to settle
down and ensure that a stable output is obtained in the destination
domain. A commonly used synchronizer is a multi-flop synchronizer
as shown in Figure 3.

Over-inflated bubble to burst like a dot.com in 2001;


expect casualties
IoT here to stay but slow measured progress
Rock solid: IoT to float all boats
Submit
ALL POLLS

3. Multi-flop synchronization.

Like Us on Facebook

This structure is mainly used for single and multi-bit control signals
and single bit data signals in the design. Other types of
synchronization schemes are required for multi-bit data signals
such as MUX recirculation, handshake, and FIFO.
B. Data Loss
Problem. Whenever a new source data is generated, it may not be
captured by the destination domain in the very first cycle of the
destination clock because of metastability. As long as each

EE Times
converted by Web2PDFConvert.com

destination clock because of metastability. As long as each


transition on the source signal is captured in the destination
domain, data is not lost. In order to ensure this, the source data
should remain stable for some minimum time, so that the setup
and hold time requirements are met with respect to at least one
active edge of destination clock.

EE Times
Like
12,414 people like EE Times.

If the active clock edges of C1 and C2 arrive close together, the


first clock edge of C2, which comes after the transition on source
data A, is not able to capture it. The data finally gets captured by
the second edge of clock C2 (Figure 4).
However, if there is sufficient time between the transition on data A
and the active edge of clock C2, the data is captured in the
destination domain in the first cycle of C2.

Datasheets.com Parts Search


185 million searchable parts
(please enter a part number or hit search to begin)
powered by DataSheets.com

SEARCH

EE Times on Twitter

follow us

EE Times @eetimes
27 Jan
.@ESC_Conf Boston 2015 Schedule
is NOW LIVE! Check out what's in
store so far ow.ly/I2KCt #ESCBOS
4. Effect of metastability on data capture.
Hence, there may not be a cycle by cycle correspondence
between the source and destination domain data. Whatever the
case, it is important that each transition on the source data should
get captured in the destination domain.
For example: Assume that the source clock C1 is twice as fast as
the destination clock C2 and there is no phase difference between
the two clocks. Further assume that the input data sequence "A"
generated on the positive edge of clock C1 is "00110011". The
data B captured on the positive edge of clock C2 will be "0101".
Here, since all the transitions on signal A are captured by B, the
data is not lost. This is depicted in Figure 5.

EE Times @eetimes
23 Jan
Holographic Images for Healthcare
ubm.io/1uDTRMB

EE Times @eetimes
22 Jan
Debug 101: Squashing the Wee
Beasties ubm.io/1JeEkWE

EE Times @eetimes
Talking Terminations
ubm.io/1JeEkWC

22 Jan

Expand

EE Times @eetimes
Top Comments of the Week

5. No data is lost in this case.


However, if the input sequence is "00101111", then the output in
the destination domain will be "0011". Here the third data value in
the input sequence which is "1" is lost as shown in Figure 6.

Re: More cold weather comments:


@David: Baby polar bear comes to his
mother on the ice. "Mum", he says, "Am I a
real polar bear??" That reminds me of a true
story --...
Max The Magnificent on ESC Minneapolis
2015 ...
More Questions: While the FAA and drone
manufactures talk about how to share air
space there are many other issues related
to drones. Many drones carry cameras....
EdGear on Drone Debate to Pose ...
Re: Where to go? What to do and see?:
@mhrackin: How about "Oh,
excrementum!!!!" AFAIR, that's what I used
to say on those days in Chicago back in the
'60s That reminds me...
Max The Magnificent on ESC Minneapolis
2015 ...

6. Data is lost in this case.


Solution. In order to prevent data loss, the data should be held
constant in the source domain long enough to be properly
captured in the destination domain. In other words, after every
transition on source data, at least one destination clock edge
should arrive where there is no setup or hold violation so that the

Re: Visit the Mall and high tech: @TonyTib:


Isn't the world's largest mall pretty close?
(Mall of the Americas or something like that).
Hmmm -- thanks for that, but if...
Max The Magnificent on ESC Minneapolis
2015 ...

converted by Web2PDFConvert.com

should arrive where there is no setup or hold violation so that the


source data is captured properly in the destination domain. There
are several techniques to ensure this.

January Caption: Do you want fries with


this?
mhrackin on January 2015 Cartoon ...

For example, a finite state machine (FSM) can be used to


generate source data at a rate, such that it is stable for at least 1
complete cycle of the destination clock. This can be generally
useful for synchronous clocks when their frequencies are known.
For asynchronous clock domain crossings, techniques like
handshake and FIFO are more suitable.
C. Data Incoherency
Problem. As seen in the previous section whenever new data is
generated in the source clock domain, it may take 1 or more
destination clock cycles to capture it, depending on the arrival time
of active clock edges. Consider a case where multiple signals are
being transferred from one clock domain to another and each
signal is synchronized separately using a multi-flop synchronizer. If
all the signals are changing simultaneously and the source and
destination clock edges arrive close together, some of the signals
may get captured in the destination domain in the first clock cycle
while some others may be captured in the second clock cycle by
virtue of metastability. This may result in an invalid combination of
values on the signals at the destination side. Data coherency is
said to have been lost in such a case.
If these signals are together controlling some function of the
design, then this invalid state may lead to functional errors.
For example: Assume that "00" and "11" are two valid values for a
signal X[0:1] generated by clock C1. As shown in Figure 7, initially
there is a transition from 1->0 on both the bits of X. Both the
transitions get captured by clock C2 in the first cycle itself. Hence
the signal Y[0:1] becomes "00".

7. Data coherency is lost in this case.


Next, there is a transition from 0->1 on both the bits of signal X.
Here the rising edge of clock C2 comes close to the transition on
signal X. While the transition on X[0] is captured in the first clock
cycle, the transition on X[1] gets captured in second clock cycle of
C2. This results in an intermediate value of "10" on Y[0:1] which is
an invalid state. Data coherency is lost in this case.
Solution. In the above example, the problem results because all
the bits are not changing to a new state in the same cycle of
destination clock. If all the bits either retain their original value or
change to the new value in the same cycle, then the design either
remains in the original state or goes to a correct new state.
Now, if the circuit is designed in such a way that while changing the
design from one state to another, only one bit change is required,
then either that bit would change to a new value or would retain
the original value. Since all the other bits have the same value in
both the states, the complete bus will either change to the new
value or retain the original value in this case.
This in turn implies that if the bus is Gray-encoded, the problem
would get resolved and an invalid state would never be obtained.
However, this is applicable only for control busses as it may not be
possible to Gray-encode the data busses. In such cases, other
techniques like handshake, FIFO and MUX recirculation can be
converted by Web2PDFConvert.com

techniques like handshake, FIFO and MUX recirculation can be


used to generate a common control logic to transfer data correctly.
The MUX recirculation technique is shown in Figure 8.

8. MUX recirculation technique.


Click here for a larger version
Here, a control signal EN, generated in the source domain is
synchronized in the destination domain using a multi-flop
synchronizer. The synchronized control signal EN_Sync drives the
select pin of the muxes, thereby controlling the data transfer for all
bits of the bus A. In this way, individual bits of the bus are not
synchronized separately, and hence there is no data incoherency.
However, it is important to ensure that when the control signal is
active, the source domain data A[0:1] should be held constant.
EMAIL THIS PRINT COMMENT
PAGE 1 / 3 NEXT >

More Related Links


What Drove CES 2015 Innovation? IP and IP Subsystems
Moore's Law Covers Human Progress
TSVs to Split More Chips: Re-Integration is the Focus
Are TSMC, UMC Affected By Taiwans Water Shortages?
Intel, Microsoft Improve Odds for AR

Comments
VIEW COMMENTS: NEWEST FIRST | OLDEST FIRST | THREADED VIEW
re: Understanding Clock Domain
Crossing Issues
singh32 5/21/2014 3:30:21 PM
USER RANK
ROOKIE

NO RATINGS
LOGIN TO RATE

This is a great article and covers the topic in an efficient way.


However, I would like to make a correction:
One of the consequences of Metastability is mentioned as:
1. The destination domain output may settle down to the
new value or may return to the old value. However, the
propagation delay could be high leading to timing
issues.
This is not correct. The flop B output will eventually settle to
the correct (A) value. It is only when in the uncertain state that
flops downstream can see different values which causes a
design issue. If the flop B output were to finally settle to an
incorrect value (as also show in the waveforms for B1 and
B2), then the same could happen at the output of a
synchronizer cell and that would defeat the purpose.
The point I am trying to make is that the syncronizer cell takes
away the uncertain period from being seen by the capture flop
and passes the CORRECT/ INTENDED value to the capture
flop. If there is a rise transition on A, then flop B output will
also always have a rise transtition and wont ever get a fall
transntion.

converted by Web2PDFConvert.com

Reply Post Message Messages List Start a Board

re: Understanding Clock Domain


Crossing Issues
Richard_Brabant 4/9/2012 10:57:31
PM
USER RANK
ROOKIE

NO RATINGS
LOGIN TO RATE

May I start a controversial remark? may I say an iconoclast


approach? The Clock Domain Crossing Issues are everything
else that is not METASTABILITY. Per design the "metastability
risk" must be constrained to the same level of any
synchronous signal in a synchronous design per se, this is
known and documented 2/3/4 special flops and no
combinatorial, neither reconvergences. Then all issues
remaining are how to validate and verify the specific logic(s)
is(are) functionally guaranteeing the proper functions for not
missing any data. Many tools are addressing the checking
and verification with more or less quality and thoroughness. If
you are interesting by the topic you can join the group:
http://www.linkedin.com/groups/CDC-clock-domain-crossingin-3748476?gid=3748476&trk=hb_side_g Best regards.
Richard.
Reply Post Message Messages List Start a Board

re: Understanding Clock Domain


Crossing Issues
keith.kowal 10/4/2011 12:33:08 AM
USER RANK
ROOKIE

NO RATINGS
LOGIN TO RATE

I found this article very well written and gives a great


theoretical explaination for 99.9% of the cases - What I would
find interesting is a use of statistical method to analyze and
detect the metastable conditions.... using spice / or whatever
you all think would get - call it Part II. Go to the SI guys : use
eye patterns , etc. send me the pdf of this report posted
keith@product-designs.com thanks
Reply Post Message Messages List Start a Board

re: Understanding Clock Domain


Crossing Issues
asldjflaskjflkasjd 7/28/2010 9:13:04
PM
USER RANK
ROOKIE

NO RATINGS
LOGIN TO RATE

very good, excellent. thank you.


Reply Post Message Messages List Start a Board

re: Understanding Clock Domain


Crossing Issues
Philip_SV 8/20/2008 6:02:45 PM
USER RANK
ROOKIE

NO RATINGS
LOGIN TO RATE

The suggested patent pending solution to metastability is


flawed, as are all such proposals. The injected noise is just
as likely to move a stable event to a metastable event as it is
to move a metastable event to a stable event. And Philip
Freidin 8/27/2003 "Nothing improves the MTBF of a
metastable synchronizer better than just waiting longer. Not
clocking the intermediate signal on the negative clock edge.
Not voting. Not threshold testing. Not adding noise. Not fancy
SPICE simulations. Not predicting circuits. Not circuits
designed to bias the outcome to either 1 or 0. Not clocking it
twice as fast through twice as many flip flops. Nothing. " From
Thomas Cheney, October 1979: "In closing, there is a great
deal of theoretical and experimental evidence that a region of
anomalous behavior exists for every device that has two
stable states. The maturity of this topic is now such that
papers making contrary claims without theoretical or
experimental support should not be accepted for publication".
See http://www.fpgafaq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
Reply Post Message Messages List Start a Board

re: Understanding Clock Domain


Crossing Issues
baskarv 5/15/2008 4:37:44 AM

NO RATINGS
LOGIN TO RATE

Excellent explination
USER RANK
ROOKIE

Reply Post Message Messages List Start a Board

re: Understanding Clock Domain


Crossing Issues
rewolf 3/4/2008 7:56:09 PM

NO RATINGS
LOGIN TO RATE

converted by Web2PDFConvert.com

USER RANK
ROOKIE

But it is possible to avoid most of the problems with a simple


solution. Like other people I'm not able to design circuits
without metastable states, but my patent pending solution
ends it in a short and in its maximum defined time. If you see
a flip flop as an analog circuit, you may inject a low AC signal
in the feedback loop. If you do that, so the amplifier circuit with
its positive feedback will go very fast to a stable state. You are
able, to build a D-flip-flop with such a modified feedback
discrete, but I wish to have such flip flops in programmable
logic and other integrated circuits.
Reply Post Message Messages List Start a Board

Sign up for EE Times newsletter

Terms of Service | Privacy Statement | Copyright 2013 UBM Tech, All rights reserved

converted by Web2PDFConvert.com

Potrebbero piacerti anche