Data synchronizer using a parallel handshaking pipeline wherein validity indicators generate and send acknowledgement signals to a different clock domain

[0002] This application is related to U.S. patent application Ser. No. 09/366,773, filed Aug. 4, 1999, by Stone et al. and entitled “System and Method To Transfer Information Across An Asynchronous Interface”, which is a continuation-in-part of U.S. patent application Ser. No. 09/271,215, filed Mar. 17,1999, by Stone et al. and entitled “Data Processing System Having a FIFO Buffer With Variable Threshold Value”, both of which are assigned to the assignee herein.

[0003] The present invention relates to transferring information across an asynchronous interface and, more particularly, to a high-performance, error free data synchronization using a parallel handshake pipeline.

[0004] System designers are faced with the need to integrate more features and capabilities into a given system and to provide higher performance interfaces between different systems. The need for integrating high performance system features further includes support for synchronous and asynchronous system interfaces. Asynchronous interfaces provide system designers with greater flexibility by relieving them of the strong clocking requirements of a synchronous system. Asynchronous interfaces, however, have many disadvantages such as extra latency for data synchronization and the increased probability of data corruption during data transfer.

[0005] Data corruption primarily occurs because of metastability across an asynchronous interface. Metastability has been very well investigated in the past and there are several known solutions. The known solutions have an undesirable trade-off between performance and reliability. In particular, the known solutions are either very good in performance with less immunity to error, or are error-free with poor performance. For example, a first known solution is to provide a full handshake between the transmitting device and the receiving device. The full handshake method, although error free, has a very high latency to transfer data, thereby reducing the performance considerably. Each transaction requires four or more receiver clock cycles to transfer the data. Thus, the full handshake method eliminates the metastability problem and is error free, but has very low performance and is not applicable for high performance designs.

[0006] A second known solution utilizes synchronizing latches to sample a data valid signal across an asynchronous interface. The data valid signal passes through the synchronizing latches to reduce the probability of a metastable condition. This second method is useful for high performance applications since data is read on every cycle of the core domain. However, this method still has several potential disadvantages, such as, the same data may be read twice or may be skipped completely because of metastability. Either scenario causes loss of data which may seriously affect system functionality since transaction information is lost in the transfer. This technique is not desired in high performance systems where re-transmission of data comes at a very high cost. This method also suffers from very poor debug capabilities and there is no mechanism to throttle or control the flow of incoming data.

[0007] It is therefore desired to provide a system and method for transferring data across an asynchronous interface at a very high throughput for use in high performance systems while also reducing or otherwise eliminating transfer errors. It is also desired to provide throttle control and debug capabilities.

[0008] FIG. 1 illustrates a block diagram of an interface between two different systems each having a separate and independent clock source.

[0009] FIG. 2 is a timing diagram illustrating the parallel pipelining of data in accordance with the present invention.

[0010] FIG. 3 illustrates in block diagram form a parallel full handshake pipeline synchronizer for synchronizing data across an asynchronous interface according to the present invention.

[0011] FIG. 4 illustrates in timing diagram form the asynchronous handshake pipelining timing of the synchronizer of FIG. 3.

[0012] FIG. 5 illustrates in timing diagram form a variable transfer delay across the asynchronous interface of the synchronizer of FIG. 3.

[0013] FIG. 1 is a block diagram of two different systems with separate clocks interfaced together utilizing a parallel full handshake pipeline synchronizer according to the present invention. A first clock source 101 provides the clocking to a first system 103 shown as SYSTEM 1. The clock source 101 establishes a domain X for core logic of the system 103. The system 103 includes an interface domain 104 with a transmitter (TX) 105 for transmitting data from the system 103. The interface domain 104 also includes a receiver (RX) 106 that receives data from an external source on a data bus D1 and transfers the data to the core logic of the system 103. The receiver 106 asserts a flow control signal FC1 to prevent overflow.

[0014] A second system 107, shown as SYSTEM 2, also includes an interface domain 109 with a transmitter 111 that transmits data from the system 107 to the receiver 106 of the system 103. Also, the interface domain 109 includes a receiver 113 for receiving data on a data bus D2 from the system 103. The receiver 113 asserts another flow control signal FC2 to the transmitter 105 to prevent overflow. The system 107 operates in a domain Y receiving its clock from a clock source 115. It is noted that the clock sources 101 and 115 are separate and independent, where the clock source 101 establishes the domain X and where the clock source 115 establishes the domain Y. A system interface (I/F) 119 between the systems 103 and 107 is a source synchronous interface (I/F) so that the interface between the receivers 106 and 113 and the respective core logic of the respective systems 103 and 107 are asynchronous. The interface between the core logic and the transmitters 105, 111 of the respective systems 103, 107 may be synchronous or asynchronous depending on the particular topology chosen for system implementation.

[0015] FIG. 2 is a timing diagram illustrating the parallel pipelining of data transfer from the receiver of an interface domain to the core logic, such as from the receiver 106 to the core logic of the system 103, or from the receiver 113 to the core logic of the system 107. As described in detail below, data is transmitted across the source synchronous interface 119 and latched into a respective receiver. The receiver (106, 113) submits to its respective core logic (system 103, 107) a corresponding service request (REQUEST 1, etc.) for each beat or frame of data sampled from a bus of the source synchronous interface 119. Five transactions are shown, individually labeled T1, T2, T3, T4, and T5, synchronized with the respective system interface domain clock. Each of transactions T1-T5 is initiated with a corresponding service request signal, shown as REQUEST 1, REQUEST 2, REQUEST 3, REQUEST 4 and REQUEST 5, respectively, to the core logic of the respective system. After the core logic samples the respective service request signals in the core logic domain, it acknowledges back with respective acknowledge signals, shown as ACK 1, ACK 2, ACK 3, ACK 4 and ACK 5, respectively, which are synchronous to a core logic domain clock. Each transaction at T1-T5 has a variable delay (VD) time period separating an assertion of a request signal and an acknowledge signal, shown as VD 1, VD 2, VD 3, VD 4 and VD 5, respectively. The respective delays VD 1-VD 5 may not be the same and may be variable with respect to each other, unlike as illustrated in FIG. 2.

[0016] As will be described in detail below, in spite of uncertain delay during the time from a request to an acknowledge for each individual transaction T1-T5, the respective REQUEST signals are asserted in consecutive cycles of the system interface domain clock even though prior transactions have not been completed. Corresponding and respective acknowledge signals (ACK) are shown asserted in consecutive cycles of the core logic domain clock in the same order as the respective REQUEST signals, each after the respective one of the variable delays VD 1-VD 5. It is noted, however, that depending upon the respective frequencies of the core logic and system interface domain clocks, one or more cycles of the core logic domain clock may be inserted between consecutive assertions of the acknowledge signals. It is important to note that the acknowledge signals are nonetheless asserted in order (i.e. sequential) to ensure error-free data transfer. In this manner, multiple transactions are issued in parallel, thereby effectively pipelining data transfer across the interface to achieve maximum throughput with full handshakes.

[0017] FIG. 3 is a block diagram of a parallel full handshake pipeline synchronizer 300 implemented according to the present invention. The synchronizer 300 is utilized to synchronize the data transfer between a receiver, such as the receivers 106 or 113 in FIG. 1, and the corresponding core logic of the respective system, such as the systems 103 or 107, respectively. A dashed line 301 represents the asynchronous interface between the system interface domain 303 and the core logic domain 305 across the asynchronous interface 301. For example, circuitry above the asynchronous interface 301 is implemented in corresponding core logic of each of system 103 and 107, and circuitry below the aysnchronous interface 301 is implemented in each of receiver 106 and receiver 113, respectively. A data bus 307 transfers data from a transmitter, such as the transmitter 105 or 111, to a series of registers, labeled REGISTER 1, REGISTER 2, REGISTER 3, REGISTER 4, and REGISTER 5 stacked to form a flat circular first-in first-out (FIFO) 309 storage device. The data bus 307 further includes an embedded clock signal CLK which serves as a timing reference for the data asserted on the data bus 307. The data bus 307 also includes a Data Beat Valid (DBV) signal to indicate that a particular data beat is valid during a particular cycle of the CLK signal. The CLK and DBV signals are provided to a load handler 311 to enable the load handler 311 to generate load enable signals to the REGISTERs 1-5 of the FIFO 309 to latch or otherwise capture data from the data bus 307. Each REGISTER 1-5 has associated therewith a handshake valid bit in a validity indicator register in the system interface domain 303 shown as SV 1, SV 2, SV 3, SV 4 and SV 5, respectively. The validity indicator registers for SV 1-5 may be implemented as separate registers from each of REGISTERs 1-5 or may be implemented as individual storage bits within REGISTERs 1-5. In one embodiment, the load handler 311 sets the respective one of the SV 1-5 bits when the data is latched into the corresponding one of the REGISTERs 1-5 of the FIFO 309. Alternatively, the SV 1-5 bits are configured as registers, where each is automatically set when the respective one of the REGISTERs 1-5 is loaded with data.

[0018] Within the core logic domain 305 there are core logic handshake valid bits CV 1, CV 2, CV 3, CV 4 and CV 5 corresponding to the respective SV 1-5 bits of the FIFO 309. When set, the SV 1-5 bits cause corresponding request signals REQ 1, REQ 2, REQ 3, REQ 4, AND REQ 5 to be asserted across the asynchronous interface 301 to the corresponding CV 1-5 bits. The CV 1-5 bits are set after sampling the assertion of the respective REQ 1-5 request signals. The CV 1-5 bits may also be configured as registers that are set in response to assertion of corresponding REQ-1-5 signals.

[0019] A data sampler/unloader 313 samples the CV 1-5 bits in an orderly fashion as further described below. Upon detecting that a CV 1-5 bit is set, the data sampler/unloader 313 generates a multiplex or select signal (MX_SEL) which is connected to a multiplexor (MUX) 315 to select the inputs of the multiplexor (MUX) 315 and causes the generation of a respective acknowledge signal, shown as ACK 1, ACK 2, ACK 3, ACK 4 and ACK 5, provided back to the respective SV 1-5 bits. The outputs of each of the REGISTERs 1-5 of the FIFO 309 are provided to respective inputs of the MUX 315. The MX_SEL signal selects the data from one of the REGISTERs 1-5 to be sampled by a data latch 317 operating in the core logic domain 305. After the latch 317 samples the data, the data sampler/unloader 313 resets the corresponding CV 1-5 bit and de-asserts the corresponding ACK 1-5 signal. An assertion of any of the ACK 1-5 signals causes the corresponding SV 1-5 bit to reset, thereby indicating the completion of data transfer for a particular transaction. To maintain proper ordering of data, upon system reset, the load handler 311 always points to a default starting register, such as REGISTER 1 of the FIFO 309. The data sampler/unloader 313 also points to the same default starting register by monitoring the corresponding one of the CV 1-5 bits, such as the CV 1 bit corresponding to REGISTER 1. When data is asserted on the data bus 307 as detected by the load handler 311 via the CLK and DBV signals, the load handler 311 latches or captures data into the REGISTERs 1-5 in a cyclic fashion. In particular, the first data beat is loaded into REGISTER 1, the second data beat is loaded into REGISTER 2 and so on up to REGISTER 5 and then the circuit operation wraps around back to REGISTER 1. The data sampler/unloader 313, by monitoring the CV 1-5 bits in the same, cyclic order, follows the same ordering while unloading the data from the FIFO 309 via the MUX 315. As an example, suppose three data beats A, B, and C are asserted on the data bus 307 in sequential order. The load handler 311 captures the data beats A, B and C into the respective registers, REGISTER 1, 2 and 3, of the FIFO 309. After data beat A is loaded into REGISTER 1, the SV 1 bit is set causing assertion of the REQ 1 signal. Likewise, after data beats B and C are loaded into REGISTERs 2 and 3, respectively, the SV 2 and SV 3 bits are set generating the REQ 2 and REQ 3 request signals. The assertion of the REQ 1-REQ 3 request signals is eventually sampled by the CV 1-3 bits, although not necessarily in that order due to metastability. The data sampler/unloader 313 is parked at the CV 1 bit until it is detected being set by the REQ 1 request signal. When the CV 1 bit is set, the data sampler/ unloader 313 asserts the ACK 1 signal back to SV 1 bit and generates the MX_SEL signal to the MUX 315 to multiplex the data beat A from REGISTER 1 to be sampled by the latch 317. After the data beat A is latched by the latch 317, the data sampler/unloader 313 resets the CV 1 bit and de-asserts the ACK 1 signal back to the SV 1 bit. Assertion of ACK 1 signal causes the SV1 bit to reset and the REQ 1 request signal is de-asserted.

[0020] Meanwhile, the data sampler/unloader 313 increments to the next CV 2 bit and remains there until it is set. When the CV 2 bit is set upon sampling of the REQ 2 signal, the data sampler/unloader 313 asserts the ACK 2 signal back to SV 2 and also generates the MX_SEL signal to the MUX 315 to multiplex the data beat B from REGISTER 2 of the FIFO 309 to the latch 317. Operation continues in this manner until all of the data beats A, B, and C are multiplexed by the multiplexor 315 and latched by the latch 317 in that order and until all of the corresponding CV 1-3 and SV 1-3 bits are cleared. The data sampler/unloader 313 then remains parked at the CV 4 bit and the load handler 311 remains parked at REGISTER 4 of the FIFO 309. Another set of data such as data bits D, E, and F are subsequently loaded into REGISTERs 4, 5 and 1, in that order, and unloaded by the data sampler/unloader 313 by sampling the CV 4, CV 5 and CV 1 bits being set, in the same order. Operation repeats in this manner through all subsequent data beats in a similar manner.

[0021] The load handler 311 also detects errors such as overwriting a valid entry when the system interface domain 303 is operating at significantly higher frequency than the core logic domain 305. In particular, the load handler 311 detects an error and asserts a corresponding ERR signal when data is about to be loaded into a register of the FIFO 309 that already has its corresponding SV 1-5 bit set. Load handler 311 does this detection function by using the DBV signal received via data bus 307 and monitoring when the DBV signal is asserted valid. This error detection capability facilitates easy error recovery of the system and provides better debug capabilities.

[0022] A throttle generator 319 monitors each of the SV 1-5 bits for purposes of flow control. For example, when the throttle generator 319 detects any predetermined number of asserted SV1-SV5 bits, it asserts a flow control (FC) signal back to the transmitter informing the transmitter to pace the data being transmitted via the data bus 307. By throttling the transmitter in this manner, the synchronizer 300 has sufficient time to empty the FIFO 309 to prevent overflow. For example, the throttle generator 319 may assert the FC signal upon detection of three (3) or more of the SV 1-5 bits set at the same time, indicating a potential overflow condition.

[0023] FIG. 4 is a timing diagram showing operation of the synchronizer 300 illustrating parallel pipelined data flow from the system interface domain 303 to the core logic domain 305 of FIG. 3. A system interface domain clock is shown with respective cycles SC1, SC2, SC3, etc. Data beats A, B, C, D, E, F, G and H are asserted on the data bus 307 synchronized with the system interface domain clock and corresponding cycles SC1-SC8 as shown. The load handler 311 captures data beats into the REGISTERs 1-5 of the FIFO 309 as previously described. The contents of the REGISTERs 1-3 in FIG. 4 are labeled with names REG1, REG2 and REG3, respectively. For simplicity, only the data beats A, B and C are illustrated as being latched into the corresponding REGISTERs 1-3. In particular, after the data handler 311 captures the data beat A into REGISTER 1 (REG1), the SV 1 bit asserts the REQ 1 signal during clock cycle SC2. The data beat A is loaded into REGISTER 1 beginning at clock cycle SC2. Likewise, the REQ 2 and REQ 3 signals are asserted during clock cycles SC3 and SC4, respectively, while the data beats B and C are captured into the registers 2 and 3 beginning at clock cycles SC3 and SC4, respectively, as shown.

[0024] A core logic clock is also shown illustrated with respect to clock cycle CC1, CC2, CC3, etc. After the REQ 1 signal is asserted, the CV 1 bit detects assertion of the REQ 1 signal and is set. The data sampler/unloader 313 detects the CV 1 bit set and asserts the ACK 1 signal and the MX_SEL signal to the MUX 315 during clock cycle CC4, resets the CV 1 bit, and also de-asserts the ACK 1 signal during clock cycle CC5. Further, the data beat A is latched by latch 317 during the clock cycle CC5. The assertion of the ACK 1 signal during clock cycle CC4 causes SV1 to reset and causes de-assertion of the REQ 1 signal during a subsequent clock cycle, such as SC6. The assertion of the REQ 2 signal during clock cycle SC3 eventually causes assertion of the ACK 2 signal. Due to the pipelining nature of the synchronizer 300, the ACK 2 signal is asserted during clock cycle CC5 following assertion of the ACK 1 signal during clock cycle CC4. Also, the data sampler/unloader 313 asserts the ACK 2 signal and the MX_SEL signal to select the REGISTER 2 (REG2) of the FIFO 309 during the clock cycle CC5. Selection of the REGISTER 2 during the clock cycle CC5 causes reset of the CV 2 bit, and also causes de-assertion of the ACK 2 signal at the beginning of the next clock cycle CC6. Further, the data beat B is latched by latch 317 during the clock cycle CC6. Also, assertion of the ACK 2 signal during clock cycle CC5 eventually causes de-assertion of the REQ 2 signal, such as during the system interface domain clock cycle SC7. In a similar manner, assertion of the REQ 3 signal during the system interface domain clock cycle SC4 eventually causes assertion of the ACK 3 signal and the generation of MX_SEL signal to select REGISTER 3 (REG3) during the clock cycle CC6. The assertion of the ACK 3 signal during clock cycle CC6 eventually causes de-assertion of the REQ 3 signal at the beginning of the clock cycle SC8. Further, the data beat C is latched by latch 317 during the clock cycle CC7. In this manner, it is shown that data is capture and latched during consecutive cycles of the core logic domain clock after a delay of four (4) clock cycles.

[0025] FIG. 5 is a timing diagram showing operation of the synchronizer 300 and further illustrating the effect of a variable delay. The timing diagram shown in FIG. 5 is very similar to the timing diagram shown in FIG. 4 and operation is very similar. However, metastability causes the data sampler/unloader 313 to pause at the CV 3 bit so that operation is delayed by one core logic clock cycle. In particular, the data sampler/unloader 313 does not detect the CV 3 bit set until clock cycle CC7. After a delay of one core logic clock cycle, the data sampler/unloader 313 asserts the MX_SEL signal to the MUX 315 during the clock cycle CC7. Also, the ACK 3 signal is asserted during the clock cycle CC7 and de-asserted at the beginning of the clock cycle CC8. Assertion of the ACK 3 signal ultimately causes de-assertion of the REQ3 signal such as at the beginning of the clock cycle SC9.

[0026] It is appreciated that metastability may cause the CV 1-5 bits to be set out of order. Nonetheless, the data sampler/unloader 313 samples the CV 1-5 bits in order so that metastability concerns are eliminated and data ordering is maintained. The throttle generator 319 asserts the FC signal to prevent or otherwise reduce the possibility of overflow. If the core logic domain clock is at least as fast as the system interface domain clock, then data transfer across the asynchronous interface 301 using the synchronizer 300 may occur as fast as data arrives at the FIFO 309 after an initial delay, such as the delay VD 1, as shown in FIG. 2.

[0027] By now it should be apparent that there has been provided a method and apparatus for error-free and high throughput data transmission across an asynchronous interface. Desired pipelining of an asynchronous interface is achieved by sending transactions in parallel across the interface to achieve a high throughput. Because of the parallel structure of the interface, new transactions do not take the same path as an uncompleted transaction. The parallel feature allows a receiver to get one transaction every clock cycle. Additionally, input data can be throttled so that data is not dropped if FIFO 309 is full. If the flat circular FIFO 309 were to overrun for some reason, the overrun can be detected with this method because of data being written into an entry whose valid bit is still set. Therefore, the present invention readily supports debug capabilities and helps establish the best and worst case frequency ratio across the interface.

[0028] Therefore, it is intended that this invention encompass all such variations and modifications as fall within the scope of the appended claims.