Hi all, I have to transfert signals from a clock domain to another. First clock domain is fixed, but the second can be faster or slower than the first one. Does somebody can give me some help. Thanks Matthieu
crossing clock domain ??
Started by ●January 10, 2007
Reply by ●January 10, 20072007-01-10
How often does the signal change relative to the two clocks? "Matthieu Cattin" <matthieu.cattin@cern.ch> wrote in message news:eo30bh$c3j$1@cernne03.cern.ch...> Hi all, > > I have to transfert signals from a clock domain to another. > First clock domain is fixed, but the second can be faster or slower than > the first one. > > Does somebody can give me some help. > > Thanks > Matthieu
Reply by ●January 10, 20072007-01-10
Signal can change on each rising edge or less often. "John_H" <newsgroup@johnhandwork.com> wrote in message news:12qa3g2otrg95e1@corp.supernews.com...> How often does the signal change relative to the two clocks? > > > "Matthieu Cattin" <matthieu.cattin@cern.ch> wrote in message > news:eo30bh$c3j$1@cernne03.cern.ch... >> Hi all, >> >> I have to transfert signals from a clock domain to another. >> First clock domain is fixed, but the second can be faster or slower than >> the first one. >> >> Does somebody can give me some help. >> >> Thanks >> Matthieu > >
Reply by ●January 10, 20072007-01-10
I wrote a TechXclusives paper a while ago, on this exact subject: You can click on the (ridiculously long) URL: http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=pa_clock_bound 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 On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote:> Signal can change on each rising edge or less often. > > "John_H" <newsgr...@johnhandwork.com> wrote in messagenews:12qa3g2otrg95e1@corp.supernews.com... > > > How often does the signal change relative to the two clocks? > > > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message > >news:eo30bh$c3j$1@cernne03.cern.ch... > >> Hi all, > > >> I have to transfert signals from a clock domain to another. > >> First clock domain is fixed, but the second can be faster or slower than > >> the first one. > > >> Does somebody can give me some help. > > >> Thanks > >> Matthieu
Reply by ●January 10, 20072007-01-10
Peter, Would your Asynchronous FIFO core handle this situation correctly given a large enough FIFO? ---Matthew Hicks "Peter Alfke" <peter@xilinx.com> wrote in message news:1168449451.035500.190590@p59g2000hsd.googlegroups.com...>I wrote a TechXclusives paper a while ago, on this exact subject: > You can click on the (ridiculously long) URL: > > http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=pa_clock_bound > > 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 > > > On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote: >> Signal can change on each rising edge or less often. >> >> "John_H" <newsgr...@johnhandwork.com> wrote in >> messagenews:12qa3g2otrg95e1@corp.supernews.com... >> >> > How often does the signal change relative to the two clocks? >> >> > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message >> >news:eo30bh$c3j$1@cernne03.cern.ch... >> >> Hi all, >> >> >> I have to transfert signals from a clock domain to another. >> >> First clock domain is fixed, but the second can be faster or slower >> >> than >> >> the first one. >> >> >> Does somebody can give me some help. >> >> >> Thanks >> >> Matthieu >
Reply by ●January 10, 20072007-01-10
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. "Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message news:eo3h81$id4$1@news.ks.uiuc.edu...> Peter, > > Would your Asynchronous FIFO core handle this situation correctly given a > large enough FIFO? > > > ---Matthew Hicks > > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:1168449451.035500.190590@p59g2000hsd.googlegroups.com... >>I wrote a TechXclusives paper a while ago, on this exact subject: >> You can click on the (ridiculously long) URL: >> >> http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=pa_clock_bound >> >> 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 >> >> >> On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote: >>> Signal can change on each rising edge or less often. >>> >>> "John_H" <newsgr...@johnhandwork.com> wrote in >>> messagenews:12qa3g2otrg95e1@corp.supernews.com... >>> >>> > How often does the signal change relative to the two clocks? >>> >>> > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message >>> >news:eo30bh$c3j$1@cernne03.cern.ch... >>> >> Hi all, >>> >>> >> I have to transfert signals from a clock domain to another. >>> >> First clock domain is fixed, but the second can be faster or slower >>> >> than >>> >> the first one. >>> >>> >> Does somebody can give me some help. >>> >>> >> Thanks >>> >> Matthieu >> > >
Reply by ●January 10, 20072007-01-10
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 relationships. The telecom guys have lived with these situations for half a century... Peter Alfke, Xilinx On Jan 10, 12:44 pm, "John_H" <newsgr...@johnhandwork.com> wrote:> 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. > > "Matthew Hicks" <mdhic...@uiuc.edu> wrote in messagenews:eo3h81$id4$1@news.ks.uiuc.edu... > > > Peter, > > > Would your Asynchronous FIFO core handle this situation correctly given a > > large enough FIFO? > > > ---Matthew Hicks > > > "Peter Alfke" <p...@xilinx.com> wrote in message > >news:1168449451.035500.190590@p59g2000hsd.googlegroups.com... > >>I wrote a TechXclusives paper a while ago, on this exact subject: > >> You can click on the (ridiculously long) URL: > > >>http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&cate... > > >> 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 > > >> On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote: > >>> Signal can change on each rising edge or less often. > > >>> "John_H" <newsgr...@johnhandwork.com> wrote in > >>> messagenews:12qa3g2otrg95e1@corp.supernews.com... > > >>> > How often does the signal change relative to the two clocks? > > >>> > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message > >>> >news:eo30bh$c3j$1@cernne03.cern.ch... > >>> >> Hi all, > > >>> >> I have to transfert signals from a clock domain to another. > >>> >> First clock domain is fixed, but the second can be faster or slower > >>> >> than > >>> >> the first one. > > >>> >> Does somebody can give me some help. > > >>> >> Thanks > >>> >> Matthieu
Reply by ●January 10, 20072007-01-10
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!! "John_H" <newsgroup@johnhandwork.com> wrote in message news:12qak264aekr04b@corp.supernews.com...> 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. > > > > "Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message > news:eo3h81$id4$1@news.ks.uiuc.edu... >> Peter, >> >> Would your Asynchronous FIFO core handle this situation correctly given a >> large enough FIFO? >> >> >> ---Matthew Hicks >> >> >> "Peter Alfke" <peter@xilinx.com> wrote in message >> news:1168449451.035500.190590@p59g2000hsd.googlegroups.com... >>>I wrote a TechXclusives paper a while ago, on this exact subject: >>> You can click on the (ridiculously long) URL: >>> >>> http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=pa_clock_bound >>> >>> 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 >>> >>> >>> On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote: >>>> Signal can change on each rising edge or less often. >>>> >>>> "John_H" <newsgr...@johnhandwork.com> wrote in >>>> messagenews:12qa3g2otrg95e1@corp.supernews.com... >>>> >>>> > How often does the signal change relative to the two clocks? >>>> >>>> > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message >>>> >news:eo30bh$c3j$1@cernne03.cern.ch... >>>> >> Hi all, >>>> >>>> >> I have to transfert signals from a clock domain to another. >>>> >> First clock domain is fixed, but the second can be faster or slower >>>> >> than >>>> >> the first one. >>>> >>>> >> Does somebody can give me some help. >>>> >>>> >> Thanks >>>> >> Matthieu >>> >> >> > >
Reply by ●January 11, 20072007-01-11
One solution is to have the transmitter include padding, extra bits or words that the receiver recognizes and can, if necessary, "throw away" = skip over. That way, the receiver does not need a back communication to the transmitter. The price is of course a loss of throughput. There is no free lunch. Peter Alfke On Jan 10, 7:18 pm, "Rob" <robns...@frontiernet.net> wrote:> 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!! > > "John_H" <newsgr...@johnhandwork.com> wrote in messagenews:12qak264aekr04b@corp.supernews.com... > > > 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. > > > "Matthew Hicks" <mdhic...@uiuc.edu> wrote in message > >news:eo3h81$id4$1@news.ks.uiuc.edu... > >> Peter, > > >> Would your Asynchronous FIFO core handle this situation correctly given a > >> large enough FIFO? > > >> ---Matthew Hicks > > >> "Peter Alfke" <p...@xilinx.com> wrote in message > >>news:1168449451.035500.190590@p59g2000hsd.googlegroups.com... > >>>I wrote a TechXclusives paper a while ago, on this exact subject: > >>> You can click on the (ridiculously long) URL: > > >>>http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&cate... > > >>> 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 > > >>> On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote: > >>>> Signal can change on each rising edge or less often. > > >>>> "John_H" <newsgr...@johnhandwork.com> wrote in > >>>> messagenews:12qa3g2otrg95e1@corp.supernews.com... > > >>>> > How often does the signal change relative to the two clocks? > > >>>> > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message > >>>> >news:eo30bh$c3j$1@cernne03.cern.ch... > >>>> >> Hi all, > > >>>> >> I have to transfert signals from a clock domain to another. > >>>> >> First clock domain is fixed, but the second can be faster or slower > >>>> >> than > >>>> >> the first one. > > >>>> >> Does somebody can give me some help. > > >>>> >> Thanks > >>>> >> Matthieu
Reply by ●January 11, 20072007-01-11
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 "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1168489015.772863.289540@i39g2000hsf.googlegroups.com...> One solution is to have the transmitter include padding, extra bits or > words that the receiver recognizes and can, if necessary, "throw away" > = skip over. That way, the receiver does not need a back communication > to the transmitter. The price is of course a loss of throughput. > There is no free lunch. > Peter Alfke > > On Jan 10, 7:18 pm, "Rob" <robns...@frontiernet.net> wrote: >> 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!! >> >> "John_H" <newsgr...@johnhandwork.com> wrote in >> messagenews:12qak264aekr04b@corp.supernews.com... >> >> > 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. >> >> > "Matthew Hicks" <mdhic...@uiuc.edu> wrote in message >> >news:eo3h81$id4$1@news.ks.uiuc.edu... >> >> Peter, >> >> >> Would your Asynchronous FIFO core handle this situation correctly >> >> given a >> >> large enough FIFO? >> >> >> ---Matthew Hicks >> >> >> "Peter Alfke" <p...@xilinx.com> wrote in message >> >>news:1168449451.035500.190590@p59g2000hsd.googlegroups.com... >> >>>I wrote a TechXclusives paper a while ago, on this exact subject: >> >>> You can click on the (ridiculously long) URL: >> >> >>>http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&cate... >> >> >>> 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 >> >> >>> On Jan 10, 8:12 am, "Matthieu Cattin" <matthieu.cat...@cern.ch> >> >>> wrote: >> >>>> Signal can change on each rising edge or less often. >> >> >>>> "John_H" <newsgr...@johnhandwork.com> wrote in >> >>>> messagenews:12qa3g2otrg95e1@corp.supernews.com... >> >> >>>> > How often does the signal change relative to the two clocks? >> >> >>>> > "Matthieu Cattin" <matthieu.cat...@cern.ch> wrote in message >> >>>> >news:eo30bh$c3j$1@cernne03.cern.ch... >> >>>> >> Hi all, >> >> >>>> >> I have to transfert signals from a clock domain to another. >> >>>> >> First clock domain is fixed, but the second can be faster or >> >>>> >> slower >> >>>> >> than >> >>>> >> the first one. >> >> >>>> >> Does somebody can give me some help. >> >> >>>> >> Thanks >> >>>> >> Matthieu >
