EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Clock distribution /Resynchronizing

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Clock distribution /Resynchronizing

Spehro Pefhany
Guest

Tue Jan 23, 2018 6:20 pm   



Hi all,

I would like to create and distribute a master clock and sync pulses to a number of boxes throughout a system. There will be some skew between the signals, of unknown sign. Probably the clock will be 24.576MHz and sync will be 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 delay buffer, feed that into an FPGA and clock off both the rising and falling 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 generating and relaying clocks? How should this be handled with the dedicated clock input pins?

Looking at using a Lattice Mach02.

Thanks
--sp

KJ
Guest

Tue Jan 23, 2018 11:52 pm   



A few details are missing from your post, but I'll make some assumptions and go from there. I'm assuming your 'boxes' are at least physically separate boards or maybe different systems entirely. That means you need to concern 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 SERDES parts which greatly simplifies 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.

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 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.

Kevin Jennings

Spehro Pefhany
Guest

Wed Jan 24, 2018 2:59 am   



On Tuesday, 23 January 2018 16:52:05 UTC-5, KJ wrote:
Quote:
A few details are missing from your post, but I'll make some assumptions and go from there. I'm assuming your 'boxes' are at least physically separate boards or maybe different systems entirely. That means you need to concern 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 simplifies 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.

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 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.

Kevin Jennings


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:

https://i.imgur.com/y5oBOO7.png

All nodes get the same clock and the sync is simultaneously (before the active 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 to 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 guarantee 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 changes on the rising edge of the system clock (say with a synchronous divider) 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 alternate clock edges to guaranteed the timing. Also probably overkill for this application which is not much more than a clock divider chain.

So I guess that's another option- internal or external delay elements to add up to the worst-case estimated skew + setup time + safety margin


Guest

Wed Jan 24, 2018 11:20 pm   



Den onsdag den 24. januar 2018 kl. 01.59.31 UTC+1 skrev Spehro Pefhany:
Quote:
On Tuesday, 23 January 2018 16:52:05 UTC-5, KJ wrote:
A few details are missing from your post, but I'll make some assumptions and go from there. I'm assuming your 'boxes' are at least physically separate boards or maybe different systems entirely. That means you need to concern 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 simplifies 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.

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 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.

Kevin Jennings

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:

https://i.imgur.com/y5oBOO7.png

All nodes get the same clock and the sync is simultaneously (before the active 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 to 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 guarantee 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 changes on the rising edge of the system clock (say with a synchronous divider) 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 alternate clock edges to guaranteed the timing. Also probably overkill for this application which is not much more than a clock divider chain.

So I guess that's another option- internal or external delay elements to 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

rickman
Guest

Thu Jan 25, 2018 8:51 am   



Spehro Pefhany wrote on 1/23/2018 7:59 PM:
Quote:
On Tuesday, 23 January 2018 16:52:05 UTC-5, KJ wrote:
A few details are missing from your post, but I'll make some assumptions and go from there. I'm assuming your 'boxes' are at least physically separate boards or maybe different systems entirely. That means you need to concern 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 simplifies 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.

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 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.

Kevin Jennings

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:

https://i.imgur.com/y5oBOO7.png

All nodes get the same clock and the sync is simultaneously (before the active 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 to 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.


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?


> Lower end standard clock synthesis chips that I've looked at don't guarantee 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.

What ADC chips are you using?


Quote:
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 changes on the rising edge of the system clock (say with a synchronous divider) 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 alternate clock edges to guaranteed the timing. Also probably overkill for this application which is not much more than a clock divider chain.

So I guess that's another option- internal or external delay elements to add up to the worst-case estimated skew + setup time + safety margin




--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Spehro Pefhany
Guest

Thu Jan 25, 2018 10:52 pm   



On Thursday, 25 January 2018 01:51:46 UTC-5, rickman wrote:

Hi, Rick:-

Quote:

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:

https://i.imgur.com/y5oBOO7.png

All nodes get the same clock and the sync is simultaneously (before the active 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 to 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.

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?


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 << 1msec which is probably okay.

But if I program it using both edges of the clock, the waveforms look
great.

Quote:

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?


Lower end standard clock synthesis chips that I've looked at don't guarantee 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.

What ADC chips are you using?


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.
Quote:

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998



Guest

Thu Jan 25, 2018 11:00 pm   



Den torsdag den 25. januar 2018 kl. 21.53.00 UTC+1 skrev Spehro Pefhany:
Quote:
On Thursday, 25 January 2018 01:51:46 UTC-5, rickman wrote:

Hi, Rick:-


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:

https://i.imgur.com/y5oBOO7.png

All nodes get the same clock and the sync is simultaneously (before the active 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 to 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.

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?

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 << 1msec which is probably okay.

But if I program it using both edges of the clock, the waveforms look
great.


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?


Lower end standard clock synthesis chips that I've looked at don't guarantee 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.

What ADC chips are you using?

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.


multiply the clock in the fpga so you have a say 100MHz clock to do the delay

KJ
Guest

Fri Jan 26, 2018 1:47 am   



> 24.576MHz and sync will be in the kHz range.

These are relatively low frequencies that can be simply distributed to the boxes. LVDS is a good choice.

> At the receiving nodes the clocks have to be de-jittered and preferably the two (or more) signals aligned with each other. 

Why? If you can't transmit two signals and receive them at the other end and think that you have to de-jitter them then there is either something you're not telling us or you are overthinking this.

> Right now it looks to me like the sensible way to do it is to use a zero delay buffer, feed that into an FPGA and clock off both the rising and falling edges of a single clock signal

The sensible thing to me would be to simply transmit and receive and use the 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). That meets your other requirement of keeping sync transitions away from the active edge.

> Is clocking off both edges of an input signal a kosher approach to generating 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 directly without anything fancy is not adequate. If you can do that then you've described the problem to be solved.

Kevin Jennings

rickman
Guest

Sat Jan 27, 2018 2:09 am   



Spehro Pefhany wrote on 1/25/2018 3:52 PM:
Quote:
On Thursday, 25 January 2018 01:51:46 UTC-5, rickman wrote:

Hi, Rick:-


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:

https://i.imgur.com/y5oBOO7.png

All nodes get the same clock and the sync is simultaneously (before the active 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 to 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.

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?

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 << 1msec which is probably okay.

But if I program it using both edges of the clock, the waveforms look
great.


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?


Lower end standard clock synthesis chips that I've looked at don't guarantee 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.

What ADC chips are you using?

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.


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,
on the centerline of totality since 1998

elektroda.net NewsGroups Forum Index - FPGA - Clock distribution /Resynchronizing

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map