cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
342 Views
Registered: ‎01-06-2016

burst clock synchronization

Jump to solution

Basically, a generated clock needs to be locked onto a clock burst. I am wondering if the clock burst connected to the MCMM input will be enough to keep the generator going? The clock burst is one for 1 part in 64.

 Can I approach this using the two inputs to the MCMM, one input connected to a feedback clock and the other to the burst clock source then switching to the burst source with a window signal? It says in the docs that the MCMM must be reset and may lose its lock. How then to synchronize to a clock burst?

0 Kudos
Reply
1 Solution

Accepted Solutions
Moderator
Moderator
264 Views
Registered: ‎04-18-2011

Hi @rtfinch 

I don't really see a way here. the MMCM needs to have a clock at it's input or else you are going to lose the lock as you point out. 

I was thinking of using a free running reference clock to clock an MMCM and we phase shift the output until the clock output matches the incoming burst clock but I don't see how we do it without several bursts to train on..

In this case you would likely need several bursts to train the MMCM. 

It kind of reminds me of an asynchronous interface where the relationship between the data and the capture clock is not known so maybe that is something to look at in terms of XAPPs. 

https://www.xilinx.com/support/documentation/application_notes/xapp1330-async-data-capture-hssio.pdf

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

2 Replies
Moderator
Moderator
265 Views
Registered: ‎04-18-2011

Hi @rtfinch 

I don't really see a way here. the MMCM needs to have a clock at it's input or else you are going to lose the lock as you point out. 

I was thinking of using a free running reference clock to clock an MMCM and we phase shift the output until the clock output matches the incoming burst clock but I don't see how we do it without several bursts to train on..

In this case you would likely need several bursts to train the MMCM. 

It kind of reminds me of an asynchronous interface where the relationship between the data and the capture clock is not known so maybe that is something to look at in terms of XAPPs. 

https://www.xilinx.com/support/documentation/application_notes/xapp1330-async-data-capture-hssio.pdf

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

Adventurer
Adventurer
255 Views
Registered: ‎01-06-2016

Phase shifting the clock output was the kind of thing I was thinking of, but I've decided to just send the clock continuedly. It is 25% overhead just for the clock but is a lot simpler design. Thanks for the application note reference.

0 Kudos
Reply