Browse Prior Art Database

Method of Data Synchronization On an Asynchronously Clocked Interface

IP.com Disclosure Number: IPCOM000100056D
Original Publication Date: 1990-Mar-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 4 page(s) / 134K

Publishing Venue

IBM

Related People

Jackowski, SP: AUTHOR [+2]

Abstract

The logic described below buffers data being transferred at one clock rate and synchronizes it for transfer at a different clock rate.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method of Data Synchronization On an Asynchronously Clocked Interface

       The logic described below buffers data being transferred
at one clock rate and synchronizes it for transfer at a different
clock rate.

      When data is transferred on an asynchronously clocked
interface, neither side of the interface can receive and transmit
data at the same rate as the other side.  Thus, when data being
transmitted at a faster rate must be retimed to a slower rate, it
must be buffered somehow to prevent an overrun condition, and the
faster side must be informed that it must wait until more data can be
accepted.  If data being transferred at a slower rate must be
transmitted at a faster rate, valid data must exist before it can be
transferred at the faster rate.

      The common problem associated with moving data between clocks
of different rates is that of indeterminate or metastable signal
values which occur when data changing at one rate is clocked into a
latch at a different rate.  Fig. 1 shows a latch scheme which will
retime SCLKed (slower clocked) data to a FCLK (faster clock) rate.
Latches SRL1 and SRL2 insure a stable data set or reset value.  In
certain technologies more latches may be needed if the signal voltage
remains metastable for an extended period of time.

      In this scheme, however, the data being latched by FCLK must
remain constant in value long enough for the same data value to be
latched into both SRL1 and SRL2 - no less than two FCLK cycles in
this example.  If full bytes of data, potentially changing each SCLK
cycle, are being transferred, buffering the bytes before retiming can
solve the problem.

      Fig. 2 shows two four-byte-wide buffers.  The SREG buffers are
data clocked by a slower clock (SCLK) for retiming to a faster clock
(FCLK).  The FREG buffers faster data for retiming to the slower
clock.  For each buffer, a byte is loaded into one of the four bytes
by allowing only one of the four bytes to be clocked at a time.  This
is done by gating the clock using a two-bit counter.  The counter
increments and a new byte is loaded into the next byte of the buffer.
 The data is unloaded using a counter clocked at the rate to which
the data is retimed.

      Simply allowing the counters to increment normally and load and
unload the buffer will not accurately retime the data though.  The
FCNT, since it counts faster, would always catch up and pass the
SCNT, and invalid data would be transferred.  Simply adding the
retiming circuit in Fig. 1 to each bit in the buffer costs too many
c...