crossing clock domain ??

How often does the signal change relative to the two clocks?

Signal can change on each rising edge or less often.

I wrote a TechXclusives paper a while ago, on this exact subject: You can click on the (ridiculously long) URL:

When the transmit clock is faster than the receive clock, there is of course the danger of "overrunning" the receiver, and thus losing data... Peter Alfke, Xilinx

messagenews: snipped-for-privacy@corp.supernews.com...

Peter,

Would your Asynchronous FIFO core handle this situation correctly given a large enough FIFO?

---Matthew Hicks

Do you know what "large enough" is given the speeds of your two clock domains? If your downstream clock domain is always slower than your upstream time domain, you cannot get a FIFO large enough.

If you can determine the maximum sustained upstream rate (less than or equal to the upstream clock frequency) and know the minimum sustained downstream clock frequency, you can determine the FIFO size that will guarantee a system that communicates all the information. If your output frequency isn't fast enough to keep up - ever - you're hosed from the start.

Keep in mind there will be a maximum delay encountered when the FIFO reaches full.

Agreed. The FIFO behavior is easy to understand. It can smoothe out the rate variations at the input and the output, until it goes either full or empty. When full, it either tells the input to stop sending, or it will "let the bucket overflow", and data gets lost.

The easiest case is when the receiver is guaranteed to always be faster than the sender, or when send and receive really occur at the same frequency, but at unknown phase relati> Do you know what "large enough" is given the speeds of your two clock

messagenews:eo3h81$id4$ snipped-for-privacy@news.ks.uiuc.edu...

As John stated, make sure you do the analysis and assure yourself you can use a FIFO, and if so, that it is large enough. We ran into the very problem--transmit clock faster than recieve clock--and our FIFO wasn't big enough--ooops! Furthermore, it was an ASIC--double oops!! The solution was to force the transmitter to use a slightly lower clock. We weren't off by much, less than 1%, but it was enough at times to cause problems. Had we not been able to slow the transmitter we would have been screwed!!

messagenews: snipped-for-privacy@corp.supernews.com...

The method you just described sounds similar to what is done with MGT protocols. Send a special K character that can either be processed to waste time or thrown away to catch up. For small unknown differences that is a great idea. As for the FIFO solution I mentioned earlier, our group is using it to cross clock domains. We are using a NACK to control the sender and are also using extensive calculations to ensure that all FIFOs can handle a given data valid rate from the sender (because part of our system requirements is that we need to gurantee a minimum throughtput).

---Matthew Hicks

You could use a pulse-extender and then re-sync to the new clock domain. Here's an example:

---------------------------------------------------------------------------------

-- The LD control signals need to be pulse-extended and re-registered for the

-- ld_bus_clk to accept them.