LMK04828: LMK04828 Multiple Device Sync Clock Tree

Hello usethewrench,

1. The phase between the two devices will be deterministic (in the sense that there are N possible phases between one slave device and the other, where N is the slave PLL2 phase detector frequency divided by 8 MHz), but whether the phase is consistent depends on the phase detector rate and the SYNC strategy. There are two ways to get consistent phase between the two devices:
   1. Set PLL2 phase detector to 8 MHz, guaranteeing all clocks align. Use SYSREF divider as ZDM feedback, forcing PLL2 phase detector rate to 8 MHz or lower.
   2. Use the SYNC to reset the slave devices, ensuring that the dividers all begin counting at the same time, and come up with a way to SYNC against a ~3GHz VCO.
2. You can re-clock the SYNC signal to the SYSREF divider. However, unless you can meet ~300ps setup time on CLKin0 to re-clock the initial SYNC event against the slave device VCOs, you will still run into a problem ensuring that the SYSREF dividers are aligned to the same phase between slave devices - a "chicken and egg" problem. One way to solve this new problem is to set the internal SYSREF divider on the slave devices to 80 MHz and use it as ZDM feedback for PLL2. Then you can re-sync the device clocks against the internal SYSREF divider which is guaranteed to be aligned to the CLKin edge on each slave device, avoiding the chicken and egg problem and also permitting a higher phase detector rate on PLL2. To get the actual 8 MHz SYSREF, just reconfigure the slave SYSREF muxes to forward CLKin0 to SDCLKoutY, and connect the master SYSREF to the slave CLKin0. The master or the slave can be used to make any additional delay adjustments. To make things even easier, use CLKin0 as both the SYNC source and the SYSREF source, and use the master SYSREF pulser to generate a single SYNC event to all devices. No connection to SYNC pin is required.
3. Nested ZDM could also work. There are three major differences between the above solution and a nested ZDM solution:
   1. Nested ZDM would "just work" without needing external divider SYNC, as you could arrange for only one phase to be possible between input and output. The PLL2-only solution requires a SYNC event, and arranging it is somewhat elaborate.
   2. Nested ZDM could avoid propagation delay differences in the CLKin0->SDCLKoutY path, which could move the SYSREF edge by a few tens (maybe low hundreds) of picoseconds across PVT. The PLL2-only solution might require some kind of compensation for SYSREF, if the edge timing is critical to within a few tens or hundreds of picoseconds.
   3. Nested ZDM costs an additional VCXO per slave device. The PLL2-only solution would be cheaper, lower power, and is probably sufficiently accurate for setting up a SYSREF for a 160 MHz clock even with some minor propagation delay differences in SYSREF timing.

Regards,

Hello Derek,

Thank you for your reply.

Please consider my follow up questions (organized according to the question/response numbers we have used thus far), :

NOTE: At least for the near term, for the 2 slave LMK04828 devices, the only PLL1 Reference Clock Input port available is CLKin0 ( CLKin1 and CLKin2, are not routed to external connectors).  This is what is driving me to use the SYNC input.

1. (ZDM PLL2-only config, with SYNC input) - My apologies, my initial question #1 was meant to include that a SYNC signal, synchronous to the 80MHz CLKin, would be driven by the master to each of the slave devices.  Fortunately, your response spoke to such a case. 
   1. (I recognize you know this, and only included the option to help exhibit the point ) Using a PLL2 PFD frequency of 8MHz is not desirable
   2. In summary, to make the question #1 option work would require a SYNC to meet timing with the slave VCOs)

2. I appreciate your suggestion of setting internal SYSREF divider on the slave devices to 80 MHz and use it as ZDM feedback for PLL2, and synching device clocks to SYSREF divider.  Do you see any problems with this approach given that the only  Reference Clock Input port available for the two slave devices is CLKin0, and that I would have to use the actual SYNC inputs on the slave devices?
3. Nested ZDM sounds like it may be the best solution, putting power and cost aside, would you agree the nested ZDM would be the highest performing and simplest solution (given the device we are discussing and the board constraints I mentioned)?

Two more quick follow on /related questions (number 5 is motivated by inability to adjust external loops filter components in near term for the slave devices)

4.  If I wanted to apply the approach you suggested in  #2 topic (with the SYSREF muxes forwarding SYNC to SDCLKoutY) to a nested ZDM approach (but lets say with a 40MHz input for example)  My thought is yes, but just checking

5. If I were to generate the 160MHz DCLK and 8MHz directly out of the Master in dual PLL mode, and distribute to the CLKin and SYNC inputs of the Slave devices that were configured in distribution mode , I would expect matched delay between the two slave devices, yes? I expect this would require some manual delay adjustments on the sysref paths, but those would be the same between the slave devices.

Thanks

Hello usethewrench,

Thanks for your patience, someone from the team or myself will get back to you on your questions.

Thanks,

Vibhu

I appreciate the heads up and am looking forward to it

Thank you for getting back to me and for answering my follow up questions.  I have 1 left.

For the architecture we have been discussing, the two slave devices are constrained to be LMK04828, but there is flexibility for the master to use an LMK04832, or perhaps an LMK04821.

If I do use the Master's PLL2, I do not anticipate ever needing VCO greater than 2GHz, with all my foreseen output clocks being one of the following depending on the design(only one of these for a given design): 200MHz, 250MHz, 400MHz.

For the master then, does the seemingly improved overall performance of LMK04832 become best choice, even though I would have to operate it with higher VCO of 3GHz and higher N2 value?  Or would I be better off  sticking with the LMK04828 or LMK04821 for the master to benefit from it having a nice VCO range around 2GHz?  I have also been looking at the LMK04616 to see how t fits into this mix.

I am working through simulations between the LMK04828 and the LMK04832 for a few different approaches, but I cannot readily do so for the LMK04821 and LMK04616, and I need to purchase within a couple days.  With this in mind, If you can point out any discriminating factors, recommendations, or guidance for choosing a Master between the LMK04828 (or LMK04821), LMK04832, and LMK04616, I would be grateful.  (I also shouldn't have any more questions for a while =). 

Thanks!

Hello Derek,

That was very helpful, thanks for the insight.

When you said "the learning curve on these devices can be steep, especially for the supporting software," was that comment specific to the LMK04616 and LMK04610, meaning they are more of a handful than the LMK04828/LMK04832, or were you simply saying that using the LMK04616 would mean learning about an additional family of devices?

I guess one more issue, unfortunately, for the hardware I have available in near term, the slave LMK04828 devices are setup to receive only single ended reference clocks.  It looks like the LMK04616 wouldn't be able to drive that as well as the LMk04832, speaking in terms of the max frequency it can drive single ended and the  span of the available input  voltage range it would use (speaking in terms of directly driving), which could be rephrased for this discussion as saying the LMK04616 slew rate would be lower, and thus the phase noise would be degraded. That sound right?

Thanks

Certainly I am with you as far as slew rate being a rate of change, but it didnt appear to me that the LMK04616 LVCMOS Tr and Tf were any shorter (for the same load, the 4616 datasheet load specifies less than half the capacitance  specified in the the LMK04832 datasheet) , with relatively similar or longer Tr and Tf assumed, it would seem that the lower swing would give lower slew. 

You mentioned the idea of meeting the minimum slew rate, do we not expect performance to start to drop off with slew rate well before we reach the minimum?  Certainly you didnt say otherwise, but I imagined I should stay well above the lower limit.

Thank you for your suggestion regarding the HCSL.  The situation is compounded by the slave boards have available for the near term, the reference clock provided to the slave boards is put through a 3dB attenuator.

By "terminating the unused leg of the differential pair at the IC"  I would think you mean to do this near the LMK4828, correct?  Unfortunately that is not feasable because the slave board interconnect only accommodates a single ended input.

To finish off, unless there are any surprises in your next response it seems like the LMK04832 is the best choice for us (please do let me know if you think otherwise from what we have talked about). 

Thanks again

Thanks for everything!