Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Practical Design For Transferring Signals Between Clock Domains

Download as pdf or txt
Download as pdf or txt
You are on page 1of 4

designfeature By Michael Crews and Yong Yuenyongsgool, Philips Semiconductors

A SIMPLE CIRCUIT ADDRESSES THE ERRORS AND


LIMITATIONS OF ASYNCHRONOUS DESIGN.

Practical design for transferring


signals between clock domains
ith the increasing integration of multi- handshake signals, which signify the validity of data

W ple systems on single SOCs (systems on chip)


or boards, multiple clock frequencies in sin-
gle digital designs have become common. Because
being transferred to the destination clock domain.
Once the handshake signals transfer to the destina-
tion-clock domain, the system clocks the data set di-
of the asynchronous nature of these designs, passing rectly to the destination module. The most common
data or control signals between logic operating on mistakes in this situation involve the handshake sys-
different clock frequencies presents a special set of tem and its usage.
problems. Because asynchronous design is unfamil-
iar to most experienced digital designers, errors are SYNCHRONIZATION
common. Many of these errors find their way into A signal that a system sends from one clock do-
the silicon and even into production because they main arrives as an asynchronous signal in the desti-
are nearly impossible to detect in simulation and nation-clock domain, possibly violating the desti-
easily missed in postsilicon validation. Problems of nation flip-flop setup or hold time, causing it to
performance degradation, back-end EDA-tool in- enter a metastable condition. This condition, in turn,
compatibility, and dependency on the frequency re- causes propagation of nonbinary signals to other
lationship of the clocks involved often plague even parts of the system. The time required for the
functionally correct implementations. Frequency metastable flip-flop to settle out to a binary voltage
dependency is problematic for production tests that level varies. A double-stage synchronizer (Figure 2)
run the parts at different speeds, and it limits is the most widely used method of stabilizing a sig-
reusability in future designs with different system nal in the destination-clock domain. If the first flip-
frequencies. You can address all of these errors and flop stage enters the metastable condition, it has a
limitations with a fairly simple circuit that works for full clock period to stabilize before the second flip-
both data and control logic. flop stage samples it. Only the second-stage value is
The circuit requires both signal synchronization propagated to other parts of the system. To ensure
and a handshake protocol (Figure 1). The synchro- that interconnect delay does not reduce the one-
nizer guarantees the amount of time required for the clock-period settling time that the double-stage syn-
signal level to settle following a metastability viola- chronizer supplies, you must minimize interconnect
tion, thereby preventing undetermined signal levels delay between the two stages. To do so, you place the
from propagating to the destination module. The flop-flops directly next to each other on the die or
handshake protocol maintains signals levels long board. Note that you can add synchronization stages
enough to ensure that the system does not miss sig- in series to reduce the probability of the metastable
nal events or wrongly interpret them as multiple condition’s propagating to the last stage, but you pay
events. Normally, the circuit synchronizes only a price in system performance. However, the dou-

DATA_VALID TAKE_IT_PL
SOURCE- DESTINATION-
SOURCE CLK_SCR CLOCK CLOCK DESTINATION
MODULE SYNCHRONIZER MODULE
HANDSHAKE HANDSHAKE
GOT_IT_PL MODULE MODULE CLK_DST

DATA_SCR
INTERFACE MODULE

Figure 1

A simple circuit employing a synchronizer and handshake protocol can help overcome limitations and errors inherent in asynchronous design.

www.edn.com February 20, 2003 | edn 65


designfeature Asynchronous design

ble-stage synchronizer is generally suffi- NEXT-STAGE FLIP-FLOP IN


SYNCHRONIZER
DESTINATION-CLOCK DOMAIN
cient, even for high-speed systems, be-
cause metastable settling time scales SIGNAL_SCR RANDOM
down with the technology that enables COMBINATORIAL
high-speed designs. LOGIC
Figure 2
HANDSHAKE PROTOCOL
A double-stage synchronizer stabilizes CLK_DST
a signal in the destination-clock domain,
but it does not ensure that the signal re- A double-stage synchronizer is the most widely used method of stabilizing a signal in the destina-
mains stable long enough for the desti- tion-clock domain.
nation circuit to sample it once and only
once. Consider a case in which a system frequency relationship between source which the source model has been con-
asserts a signal in a fast source-clock do- and destination. tinuously driving, is stable with respect
main and then sends it to a very slow des- When the source module initiates a to the destination-clock domain. There-
tination-clock domain. The source must write transaction to the destination mod- fore, it is safe to clock the data into the
hold the signal for multiple clocks, or the ule, the interface module responds by as- destination-clock domain without syn-
logic of the slower destination-clock do- serting the START_PL signal. This signal chronizing the data signal. The TAKE_
main may never detect it. On the other begins the transfer process. Sampling the IT_PL signal generates the toggle-hand-
hand, if the system asserts a signal in a acknowledgment signal GOT_IT_PL de- shake counterpart, whereupon it is
slow source-clock domain and then asserted, the source module continues clocked through the other synchronizer
sends it to a very fast destination-clock driving the DATA_SRC and DATA_ back to the source-module clock do-
domain, the logic may detect the signal VALID signals, therefore allowing the main. As a result, the GOT_IT_PL signal
multiple times, mistaking it for multiple time for the destination logic to capture is generated in the source-module clock
events. A handshake protocol can solve the DATA_SRC in the destination-clock domain and signifies the completion of
this problem. domain. The TAKE_IT_TG signal, de- the current transaction, allowing the
Figure 1 shows an interface between rived from the START_PL signal, is the source module to resume its normal op-
two modules operating in different clock toggle-handshake signal. Once clocked eration. Notice that the system does not
domains. The interface module contains through the synchronizer, its pulse de- restore the logical levels of the toggle-
the synchronizers and the handshake- rivative, TAKE_IT_PL, is generated in the handshake signals, TAKE_IT_TG and
protocol logic. The handshake protocol destination-clock domain. The TAKE_ GOT_IT_TG, to their original states.
must ensure that the data holds stable IT_PL signal guarantees the stability of Again, the transitional—not the logi-
long enough for circuitry to sample it in the DATA_SRC data signal and acts as a cal—level acts as a means of communi-
the destination-clock domain. It must strobe to capture the DATA_SRC signal cation across clock domains. Figure 4 il-
also ensure that the handshake-protocol in the destination-clock domain. lustrates this situation. Note that, because
logic does not signal a new data-valid sig- By the time the toggle handshake sig- the handshake protocol ensures stable
nal until the destination has acknowl- nal has been clocked through the syn- data, the data signals need not be syn-
edged the first data valid signal was re- chronizer and appears in the destination- chronized themselves.
ceived. Failing to recognize the need for clock domain, the associated set of data, You can also adapt this method to sup-
this data-valid deassertion ac-
knowledgment is a common fail-
ure of asynchronous designs. DATA_VALID
One of the most efficient pro-
tocol implementations is the “tog- DATA_SRC
gle” implementation. By using the
change in the handshake’s signal START_PL
level and not the level itself to
communicate through the syn- TAKE_IT_TG

chronizer, the system immediate- TAKE_IT_PL


ly readies itself for another trans-
action. The deassertion acknowl- GOT_IT_TG
edgment occurs without the need
for a second round trip to restore GOT_IT_PL
all control signals to their proper
logical states, as a four-phase DATA_DST
round trip requires. Figure 3 il-
lustrates this protocol. The fig- The toggle-handshake protocol uses the change of the handshake’s signal level—not the
Figure 3
ure shows no clocks, because level itself—to communicate through the synchronizer, and the system immediately
the protocol works with any clock- readies itself for another transaction.
66 edn | February 20, 2003 www.edn.com
designfeature Asynchronous design
PULSE2TOGGLE

SYNCHRONIZER TOGGLE2PULSE

TAKE_IT_TG TAKE_IT_PL

Figure 4

START_PL CLK_DST

CLK_SRC

GOT_IT_TG
GOT_IT_PL

In the basic double-stage synchronization-and-toggle protocol, the transitional—not the logical—level acts as a means of communication across clock
domains.

port self-clearing bits, such as


those common in interrupt- Figure 5
CLK_DST_PL
set and -clear registers. In such cases, the
CPU’s service routine must clear the in-
terrupt by writing a self-clearing bit in
the destination module’s register. It
achieves this feat through the use of CLR_SRC_PL CLK_DST
pulse-to-toggle and toggle-to-pulse con-
CLK_SRC TAKE_IT_PL
verters (Figure 5). Note that a self-clear-
ing bit is logically equivalent to a pulse. Modifying the system in Figure 4 allows it to support a self-clearing register bit.
Due to the difference in clock speeds
between modules, a latency-absorbing through another synchronizer to ac- state at slightly different times, environ-
FIFO often acts as a data buffer destined knowledge that the source-clock domain mental conditions, or both. In this situ-
for a different clock domain. In this case, has completed the transfer. This transac- ation, it is impossible to guarantee the re-
the FIFO empty and full conditions per- tion may seem complete; however, it does solved logical states of both strobe signal
form the handshake (Figure 6). This sit- not restore the handshake signals to their and data.
uation requires the FIFO to pass the in- original values in preparation for the Sensible solutions must neither as-
put and output pointers between clock next handshake. sume nor require any fixed relationship
domains. Because the pointers contain To resolve this situation, you must ini- between the source- and destination-
multiple bits, they can introduce a race tiate another level round trip to restore clock frequencies. An implementation
condition through the synchronizer. To the logical level of the handshake signal with a fixed-frequency relationship sig-
avoid this problem, you must implement to its original state—doubling the proto- nificantly limits the reusability of the de-
the input and output pointers as Gray col latency. Employing asynchronous sign and imposes significant limitation
Code counters to ensure that only one bit flip-flops as a means of restoring the for manufacturing test. With any design
changes at a time. handshake signal level to its original state implementation, verification is critical.
in the one round-trip level protocol However, simulation cannot hope to du-
AVOID THE PITFALLS seems a natural way to cope with this is- plicate the infinite number of clock and
One of the most common pitfalls of sue. Though you can work out the signal-edge relationships that are possi-
edn030206ms9004
asynchronous design involves the use of method to yield the correct logical func- ble in a clock-domain-crossing design.
Heather
level-handshake protocols. Similar to the tions, using asynchronous flip-flops sig- Therefore, the only complete form of
toggle method, a strobe from the source nificantly complicates static-timing verification is inspection. When inspect-
clock domain generates a level handshake analysis and manufacturing test. ing a clock-domain-crossing design, you
signal, which gets clocked through a syn- Another common pitfall includes must fully analyze two cases. First, as-
chronizer in the destination-clock do- clocking of the data, as well as the strobe sume one extreme clock-frequency rela-
main. The signal’s level, as opposed to its signal, through the synchronizers, thus tionship (10 to one, for example) and
transition, is a means of communication. causing a race condition. The race con- manually analyze the behavior of the im-
The level-handshake signal in the desti- dition in this situation occurs when the plementation on a timing diagram for at
nation-clock domain is then clocked data and strobe signals enter a metastable least two consecutive transactions. Then,
68 edn | February 20, 2003 www.edn.com
designfeature Asynchronous design
DATA_DST TAKE_IT_PL
repeat the analysis, assuming the oppo-
site of the clock-frequency relationship.
Of course, the best way to avoid errors is COMPARATOR

to stick with a standard implementation,


such as the toggle technique.왏 GRAY-CODE
GRAY-CODE
OUTPUT
CLK_DST INPUT POINTER CLK_DAT
Authors’ bio graphies POINTER
(DESTINATION
(DESTINATION
Michael Crews is a design-engineering CLOCK)
CLOCK)
manager at Philips Semiconductors,
SYNCHRONIZER
where he has worked for seven years. He
FIFO
leads a hardware-design group that de- MEMORY
velops multimillion-gate SOCs for media-
SYNCHRONIZER
processing markets. He holds a BSEE from
Arizona State University (Tempe) and en- GRAY-CODE
GRAY-CODE
OUTPUT
joys piloting planes, scuba diving, and CLK_SRC INPUT POINTER
POINTER
CLK_SRC
traveling. (SOURCE
(SOURCE
CLOCK)
CLOCK)
Yong Yuenyongsgool is a design engineer
at Philips Semiconductors, where he has
worked for seven years. He is re- COMPARATOR
Figure 6
sponsible for the digital design and
verification of embedded multimedia
processor chips. He holds a BSEE and an
GOT_IT_PL DATA_SCR
MSEE from Arizona State University
(Tempe) and enjoys jogging, hiking, and Due to the difference in clock speeds between modules, a latency-absorbing FIFO often acts as a
community service. buffer data destined for a different clock domain.

www.edn.com February 20, 2003 | edn 71

You might also like