6544743 - b y sh a k e r s a r wa ry a n d sau r a b h V e...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
T oday’s SOC (system-on-chip) designs have dozens of clocks, many of which are asynchronous. This design approach facilitates the convergence of dig- ital-audio, video, wireless, and networking applica- tions in a single chip. CDCs (clock-domain cross- ings) can cause difficult-to-detect functional fail- ures in SOCs involving multiple asynchronous clocks. Simula- tion and static-timing analysis often do not detect issues such as metastability and the coherency of correlated signals’ CDCs; as a result, these issues often end up as bugs in silicon. Unfortu- nately, most relevant literature does not adequately cover some of these critical CDC issues, and designers learn about them only after making costly mistakes. Two of the most common and critical issues involving CDCs are improper sequencing of data/enable in enable-based synchronization and data coher- ency due to the convergence of signals. ENABLE-BASED SYNCHRONIZATION A receiver flip-flop output can become metastable if it vio- lates the data/reset setup-and-hold times. This scenario can arise when the transmitter—the source of data—and the re- ceiver flip-flop are in asynchronous-clock domains. To avoid such issues, designers use synchronizers that isolate metasta- bility and deliver a clean signal to the downstream logic. A synchronizer can be a simple double flip-flop. Designers com- monly use this technique for a control signal’s CDCs. In a data transfer across clock domains, the data is first set up; then, a control signal that synchronizes with the destination domain travels to the destination to enable data capture. Although this data-transfer technique across clock domains is a common and proven technique, it involves pitfalls that require special attention. This technique relies on data to be stable when you assert an enable ( Figure 1 ). Having too low a margin between the data you are set- ting up and the enable you are asserting may corrupt the data transfer. A good way to prevent such problems is to design a full handshake when you set up the data. In this approach, you assert and synchronize the request in the destination domain and adequately assert an acknowledge to let the next data load occur. This approach might add a few cycles of latency, but it avoids functional failures. Glitches are other sources of worry across clock domains. Typically, any combinational logic may be subject to short- lived glitches. These issues are generally harmless because they resolve themselves when you activate the next clock edge. Although these issues are not problematic for synchro- nous transfers, a glitch may occur with asynchronous cross- ings if you activate a destination clock. The design may there- fore receive a glitch as a pulse, causing a functional failure. For this reason, it is important to avoid using any combi-
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 4

6544743 - b y sh a k e r s a r wa ry a n d sau r a b h V e...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online