[SOLVED] How do I make synchronization between different clock?

[u24c02]

Hi.

I want to know how to make synchronous design in different clock design?
As I know, there is one way to using 2 flip flop.
But what if it has constraints like this.
Input data 8bit
output data 8bit.
Input clk 100Mhz
output clk 15Mhz
Input data valid
Output data valid

No use FiFo.
Then what does exist good way to synchronous this design?

 

[FvM]

Transfer of 8-bit data between clock domains can work without a FIFO if the data changes infrequently. You'll synchronize only the data valid signal and sample the data in the receiving clock domain when it's known stable.

You'll possibly want a full handshake with a synchronized acknowledge signal telling the sending clock domain that the data have been received and can be updated with new content.

 

[u24c02]

Transfer of 8-bit data between clock domains can work without a FIFO if the data changes infrequently. You'll synchronize only the data valid signal and sample the data in the receiving clock domain when it's known stable.

You'll possibly want a full handshake with a synchronized acknowledge signal telling the sending clock domain that the data have been received and can be updated with new content.

Did you mean that the Input data rate does not excess output data rate?

 

[FvM]

Did you mean that the Input data rate does not excess output data rate?

No. This restriction would apply in any domain crossing data transfer, even with a FIFO. Receiving data available in a two stage synchronizer will at least take two cycles of the slow clock. You'll end up with a data rate considerably below the output clock, e.g. 5 MHz.

 

[u24c02]

Sir, Would you please let me know more?
I didn't a bit catch. Please another explanation.

 

[FvM]

Why don't you sketch a circuit and timing diagram using a two stage synchronizer, e.g. a toggle synchronizer. Then check how fast data can changed without risking inconsistent transfer.

 

[u24c02]

..........

 

[FvM]

Some basic synchronizer circuits that might be used for data available in this paper: https://inst.eecs.berkeley.edu/~cs150/sp10/Collections/Papers/ClockCrossing.pdf

 

[u24c02]

I saw that already.. If you don't mind, would you please let me know my specific question's answer? Your answer is very generally. Sorry.

- - - Updated - - -

Transfer of 8-bit data between clock domains can work without a FIFO if the data changes infrequently. You'll synchronize only the data valid signal and sample the data in the receiving clock domain when it's known stable.*

You'll possibly want a full handshake with a synchronized acknowledge signal telling the sending clock domain that the data have been received and can be updated with new content.

I cannot catch about your Idea. Please help me what you said.

 

[FvM]

The key point is "sample the data in the receiving clock domain when it's known stable". Synchronized data available signal gives you the information about data being stable. Second requisite is not to write new data before it has been safely received.

 

[D.A.(Tony)Stewart]

The question must be asked, what determines validity of data?

If data is has redundancy and bandwidth limitation, then the sampling rate of both input and output must exceed twice the bandwidth of the signal.
If there is an anti-aliasing filter or Nyquist filter, the sampling rates do not need to be synchronous.

There is no obvious need to synchronize the data streams unless you define the need by the information contents and the channel capacity.

for example telephony network is synchronous to conserve bandwidth where a 64kbps channel is carried on a higher multiple bit rate frame in a time slot. This represents an 8 KHz frame rate for less than 4KHz audio bandwidth using 7th order Nyquist filters. The output synchronization is kept so that signalling information used on the least significant bit in the I frame is preserved. This signaling bit over-rides the voice bit and is not heard. In the case of data, the channel is limited to 7 bits unless SDLC protocols or similar are used. Asynchronous links are common in long haul trunks.

 

[u24c02]

The key point is "sample the data in the receiving clock domain when it's known stable". Synchronized data available signal gives you the information about data being stable. Second requisite is not to write new data before it has been safely received.

What if stable datum are coming to output continuously as 100Mhz, Then How do that get the stable data?
I think your explain is about handshake technic. that is, if i want to write 100mhz , then I make stable then output data also stable. but this event is only one data passing. what if the data is continuously coming through to output. how do you garuntee?

 

[ads-ee]

Input data 8bit
output data 8bit.
Input clk 100Mhz
output clk 15Mhz
Input data valid
Output data valid

What if stable datum are coming to output continuously as 100Mhz, Then How do that get the stable data?

It is impossible to transfer all of the data as ingress rate > egress rate (i.e. 100 MB/sec vs. 15 MB/sec transfer rates). You can only sample some of the data in this case.

You would have to capture a single sample in a holding register (or an enabled register), generate your valid, synchronize that valid from the 100 MHz to the 15 MHz (valid must persist for at least 7 clock cycles, in 100 MHz, to be at least one clock period in the 15 MHz domain), detect valid in the 15 MHz domain, capture the stable output of the holding register. After all that which will be 10+ 100 MHz clock cycles you can now release the held 100 MHz data and start sampling another byte.

You need to go back and study the fill drain rate problem. Based on what you've posted you're going to overflow your "tank".

 

[u24c02]

It is impossible to transfer all of the data as ingress rate > egress rate (i.e. 100 MB/sec vs. 15 MB/sec transfer rates). You can only sample some of the data in this case.

You would have to capture a single sample in a holding register (or an enabled register), generate your valid, synchronize that valid from the 100 MHz to the 15 MHz (valid must persist for at least 7 clock cycles, in 100 MHz, to be at least one clock period in the 15 MHz domain), detect valid in the 15 MHz domain, capture the stable output of the holding register. After all that which will be 10+ 100 MHz clock cycles you can now release the held 100 MHz data and start sampling another byte.

You need to go back and study the fill drain rate problem. Based on what you've posted you're going to overflow your "tank".

You mean that 100/15 = round 6.666 = 7, so you said 7 clock be needed to input part. That is, 1Byte come in 1cycle at 100Mhz, then it need 7 cycle to out at 15Mhz.
if you mean this , I agree. But the important thing is the input never valid until after done output valid. So handshake method needed to here. I get it.

 

[ads-ee]

You mean that 100/15 = round 6.666 = 7, so you said 7 clock be needed to input part. That is, 1Byte come in 1cycle at 100Mhz, then it need 7 cycle to out at 15Mhz.
if you mean this , I agree. But the important thing is the input never valid until after done output valid. So handshake method needed to here. I get it.

No, I did not write that.

I was pointing out that you can't transfer every byte across the clock domains.

one side is 100,000,000 bytes/sec and the other is 15,000,000 bytes/sec. Because one side runs faster you can't expect the slower side to keep up.

The only way to transfer anything across the domains is to sample the data in the 100 MHz domain once every 270 ns (might get away with 200 ns, three 15 MHz clocks). So you get only 1 out of every 27 data bytes from the 100 MHz domain transferred to the 15 MHz domain.

 

[u24c02]

Thanks I get it what you said.