Clock distribution /Resynchronizing

Hi all,
I would like to create and distribute a master clock and sync pulses to a n
umber of boxes throughout a system. There will be some skew between the sig
nals, of unknown sign. Probably the clock will be 24.576MHz and sync will b
e in the kHz range.
At the receiving nodes the clocks have to be de-jittered and preferably the
two (or more) signals aligned with each other.
Right now it looks to me like the sensible way to do it is to use a zero de
lay buffer, feed that into an FPGA and clock off both the rising and fallin
g edges of a single clock signal (or alternatively to use just one edge of
a two phase clock, but that increases the complexity). The signals are used
to clock and synchronize very precise Delta-Sigma ADCs.
Is clocking off both edges of an input signal a kosher approach to generati
ng and relaying clocks? How should this be handled with the dedicated clock
input pins?
Looking at using a Lattice Mach02.
Thanks
--sp
Reply to
Spehro Pefhany
Loading thread data ...
A few details are missing from your post, but I'll make some assumptions an d go from there. I'm assuming your 'boxes' are at least physically separat e boards or maybe different systems entirely. That means you need to concer n yourself with grounding between the two systems which typically then lead s to using differential I/O for signaling. If that is the case, then a reli able mechanism is to use something like SERDES parts which greatly simplifi es the receiving end since the output of the SERIES receiver is a clock and parallel data. Very straightforward. SERVES is built into some FPGAs as w ell as commercial dedicated parts.
In general, using both clock edges is not good practice in part because you need to control duty cycle since, unless you use logic and/or flip flops t o generate the clock (another typically bad practice), there is no way to m ake any adjustments. This recommendation of course does not apply to DDR ce lls which are specifically designed for a particular type of net topology t hat I doubt you have here.
Kevin Jennings
Reply to
KJ
and go from there. I'm assuming your 'boxes' are at least physically separ ate boards or maybe different systems entirely. That means you need to conc ern yourself with grounding between the two systems which typically then le ads to using differential I/O for signaling. If that is the case, then a re liable mechanism is to use something like SEDERS parts which greatly simpli fies the receiving end since the output of the SERIES receiver is a clock a nd parallel data. Very straightforward. SERVES is built into some FPGAs as well as commercial dedicated parts.
ou need to control duty cycle since, unless you use logic and/or flip flops to generate the clock (another typically bad practice), there is no way to make any adjustments. This recommendation of course does not apply to DDR cells which are specifically designed for a particular type of net topology that I doubt you have here.
Hi, Kevin:-
Thanks for the response.
Communication is via LVDS between boxes over terminated twisted pairs with isolation at both ends.
I'm probably missing something blindingly obvious here (!) but to simplify it to the essence what I need to do is (re) create a clock and sync signal at each node that looks like this:
formatting link

All nodes get the same clock and the sync is simultaneously (before the act ive clock edge) recognized at each node at the next active input clock edge with a difference of nanoseconds.
The key thing is that the output generated sync signal can't be too close t o the active edge of the clock. I can't just divide the clock by two to use all (say) positive edges because then it could end up off between nodes by half a clock.
Lower end standard clock synthesis chips that I've looked at don't guarante e the phase of the outputs beyond starting them up at the same time, so if they got out of phase they would never correct themselves.
Hopefully that is an adequate description.. I'm trying to create clocks for external use here. So if the "clock" output in the above timing diagram ch anges on the rising edge of the system clock (say with a synchronous divide r) then the sync output must change at least 10ns-15ns before or after the edge (known one or the other).
I took a look at SERDES and they seem to use delay elements rather than alt ernate clock edges to guaranteed the timing. Also probably overkill for thi s application which is not much more than a clock divider chain.
So I guess that's another option- internal or external delay elements to ad d up to the worst-case estimated skew + setup time + safety margin
Reply to
Spehro Pefhany
s and go from there. I'm assuming your 'boxes' are at least physically sep arate boards or maybe different systems entirely. That means you need to co ncern yourself with grounding between the two systems which typically then leads to using differential I/O for signaling. If that is the case, then a reliable mechanism is to use something like SEDERS parts which greatly simp lifies the receiving end since the output of the SERIES receiver is a clock and parallel data. Very straightforward. SERVES is built into some FPGAs as well as commercial dedicated parts.
you need to control duty cycle since, unless you use logic and/or flip flo ps to generate the clock (another typically bad practice), there is no way to make any adjustments. This recommendation of course does not apply to DD R cells which are specifically designed for a particular type of net topolo gy that I doubt you have here.
h isolation at both ends.
y it to the essence what I need to do is (re) create a clock and sync signa l at each node that looks like this:
ctive clock edge) recognized at each node at the next active input clock ed ge with a difference of nanoseconds.
to the active edge of the clock. I can't just divide the clock by two to u se all (say) positive edges because then it could end up off between nodes by half a clock.
tee the phase of the outputs beyond starting them up at the same time, so i f they got out of phase they would never correct themselves.
or external use here. So if the "clock" output in the above timing diagram changes on the rising edge of the system clock (say with a synchronous divi der) then the
n one or the other).
lternate clock edges to guaranteed the timing. Also probably overkill for t his application which is not much more than a clock divider chain.
add up to the worst-case estimated skew + setup time + safety margin
I'm not sure I understand what it is your are trying to do, but 10ns-15ns is ages so just use a faster clock
Reply to
lasselangwadtchristensen
I'm a bit confused. You say you want to use both edges of the clock, but that is only for the sync signal and not for the data??? So this is only so you have the ADCs aligned, but they can't align to the wrong edge of the system clock can they? You just need to tell the ADC which clock cycle is the appropriate starting point for the conversion, no?
I thought this was typically done with the data path. Data is clocked into the chip at some rate related to the main clock, either the same rate or a divided down rate. The data interface has signals to align to the word and to the left/right words that often go to dual (stereo) devices. If the clock is timed correctly and the data path identified the correct clock cycle to sync to, what else do you need?
What ADC chips are you using?
--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman
Hi, Rick:-
Yes, that's right. The ADCs have a conversion ready 1024 clock cycles from the sync and it only needs to be read before it's overwritten.
But if I distribute n times the clock frequency the divider at each box may have some phase difference from the master.
I suppose I could reset the *divider* with the sync pulse and that would ensure (re)synchronization in
ADS1281.
The FPGA has a delay function on the inputs but it tops out at a few ns, not enough to cover the maximum skew with cables and isolators involved.
Reply to
Spehro Pefhany
multiply the clock in the fpga so you have a say 100MHz clock to do the delay
Reply to
lasselangwadtchristensen
These are relatively low frequencies that can be simply distributed to the boxes. LVDS is a good choice.
Why? If you can't transmit two signals and receive them at the other end a nd think that you have to de-jitter them then there is either something you 're not telling us or you are overthinking this.
delay buffer, feed that into an FPGA and clock off both the rising and fall ing edges of a single clock signal
The sensible thing to me would be to simply transmit and receive and use th e two LVDS signal pairs directly.
In your diagram you show that the sync signal is less than one clock cycle wide. I would suggest a single clock cycle wide would be better. Have sync generated on the falling edge (assuming that to be the 'inactive' edge). Th at meets your other requirement of keeping sync transitions away from the a ctive edge.
ting and relaying clocks?
No. If you don't think you can reliably transmit two signals, then why do you think you can generate some clock from one of those transmitted signals ?
Explain why the simplest approach of simply transmitting clock and signal d irectly without anything fancy is not adequate. If you can do that then you 've described the problem to be solved.
Kevin Jennings
Reply to
KJ
I'm afraid I'm not picturing your system fully. The divider for examplsae, this is the first time you've mentioned it.
I worked on an array processor many years ago which distributed high speed signals across a backplane. They distributed the clock via twisted pair which allowed them to adjust the timing by adjusting the length of the wire. This made the machine hard to maintain as every board did not work in every machine. The next generation had serpentine clock traces on the boards with various taps. This allowed the boards to be adjusted to a standard and so interchangeable.
That was how they squeezed very last nanosecond from the chips.
--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.