deglitching a clock

We have a perfect-storm clock problem. A stock 16 MHz crystal
oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged
linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5"
apart. The clock trace is 8 mils wide, mostly on layer 6 of the board,
the bottom layer. We did put footprints for a series RC at the end (at
Fpga2) as terminators, just in case.

Now it gets nasty: for other reasons, the ground plane was moved to
layer 5, so we have about 7 mils of dielectric under the clock
microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of
tiny stubs, and a couple of vias, and we're at 50 ohms, or likely
less.

And the crystal oscillator turns out to be both fast and weak. On its
rise, it puts a step into the line of about 1.2 volts in well under 1
ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1,
the clock has a nasty flat spot on its rising edge, just about halfway
up. And it screws up, of course. The last FPGA, at the termination, is
fine, and the CPU is ancient 99-micron technology or something and
couldn't care less.

Adding termination at Fpga2 helps a little, but Fpga1 still glitches
now and then. If it's not truly double-clocking then the noise margin
must be zilch during the plateau, and the termination can't help that.

One fix is to replace the xo with something slower, or kluge a series
inductor, 150 nH works, just at the xo output pin, to slow the rise.
Unappealing, as some boards are in the field, tested fine but we're
concerned they may be marginal.

So we want to deglitch the clock edges *in* the FPGAs, so we can just
send the customers an upgrade rom chip, and not have to kluge any
boards.

Some ideas:

1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
maybe, and use the second flop's output as the new clock source. A
Xilinx fae claims this won't work. As far as we can interpret his
English, the DCM is not a true PLL (ok, then what is it?) and will
propagate the glitches, too. He claims there *is* no solution inside
the chip.

2. Run the clock in as a regular logic pin. That drives a delay chain,
a string of buffers, maybe 4 or 5 ns worth; call the input and output
of the string A and B. Next, set up an RS flipflop; set it if A and B
are both high, and clear it if both are low. Drive the new clock net
from that flop. Maybe include a midpoint tap or two in the logic, just
for fun.

3. Program the clock logic threshold to be lower. It's not clear to us
if this is possible without changing Vccio on the FPGAs. Marginal at
best.


Any other thoughts/ideas? Has anybody else fixed clock glitches inside
an FPGA?

John

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im 
Newsbeitrag news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com...
> We have a perfect-storm clock problem. A stock 16 MHz crystal
> oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged
> linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5"
> apart. The clock trace is 8 mils wide, mostly on layer 6 of the board,
> the bottom layer. We did put footprints for a series RC at the end (at
> Fpga2) as terminators, just in case.
>
> Now it gets nasty: for other reasons, the ground plane was moved to
> layer 5, so we have about 7 mils of dielectric under the clock
> microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of
> tiny stubs, and a couple of vias, and we're at 50 ohms, or likely
> less.
>
> And the crystal oscillator turns out to be both fast and weak. On its
> rise, it puts a step into the line of about 1.2 volts in well under 1
> ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1,
> the clock has a nasty flat spot on its rising edge, just about halfway
> up. And it screws up, of course. The last FPGA, at the termination, is
> fine, and the CPU is ancient 99-micron technology or something and
> couldn't care less.
>
> Adding termination at Fpga2 helps a little, but Fpga1 still glitches
> now and then. If it's not truly double-clocking then the noise margin
> must be zilch during the plateau, and the termination can't help that.
>
> One fix is to replace the xo with something slower, or kluge a series
> inductor, 150 nH works, just at the xo output pin, to slow the rise.
> Unappealing, as some boards are in the field, tested fine but we're
> concerned they may be marginal.
>
> So we want to deglitch the clock edges *in* the FPGAs, so we can just
> send the customers an upgrade rom chip, and not have to kluge any
> boards.
>
> Some ideas:
>
> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
> maybe, and use the second flop's output as the new clock source. A
> Xilinx fae claims this won't work. As far as we can interpret his
> English, the DCM is not a true PLL (ok, then what is it?) and will
> propagate the glitches, too. He claims there *is* no solution inside
> the chip.
>
> 2. Run the clock in as a regular logic pin. That drives a delay chain,
> a string of buffers, maybe 4 or 5 ns worth; call the input and output
> of the string A and B. Next, set up an RS flipflop; set it if A and B
> are both high, and clear it if both are low. Drive the new clock net
> from that flop. Maybe include a midpoint tap or two in the logic, just
> for fun.
>
> 3. Program the clock logic threshold to be lower. It's not clear to us
> if this is possible without changing Vccio on the FPGAs. Marginal at
> best.
>
>
> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
> an FPGA?
>
> John
>

you can run a genlocked NCO clocked from in-fabric onchip oscillator. your 
internal recovered clock will have jitter +-1 clock period of the ring 
oscillator (what could be as high as about 370MHz in S3), you might need a 
some sync logic that will ensure the 16mhz clock edges are only used to 
adjust the NCO.

using DLL/DDM possible want work as the FAE said, DCMs require decent clock 
to operate.

Antti 

John Larkin wrote:

> Some ideas:
> 
> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
> maybe, and use the second flop's output as the new clock source. A
> Xilinx fae claims this won't work. As far as we can interpret his
> English, the DCM is not a true PLL (ok, then what is it?) and will
> propagate the glitches, too. He claims there *is* no solution inside
> the chip.
> 
> 2. Run the clock in as a regular logic pin. That drives a delay chain,
> a string of buffers, maybe 4 or 5 ns worth; call the input and output
> of the string A and B. Next, set up an RS flipflop; set it if A and B
> are both high, and clear it if both are low. Drive the new clock net
> from that flop. Maybe include a midpoint tap or two in the logic, just
> for fun.
> 
> 3. Program the clock logic threshold to be lower. It's not clear to us
> if this is possible without changing Vccio on the FPGAs. Marginal at
> best.
> 
> 
> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
> an FPGA?

Enable the schmitt option on the pin :)
Sorry...

Since the issue is 'local', I'd fix it locally, and 2. sounds 
preferable. You know the CLK freq, so can choose the delay banding.

-jg

On Mon, 27 Mar 2006 22:35:31 +0200, "Antti Lukats"
<antti@openchip.org> wrote:

>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im 
>Newsbeitrag news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com...
>> We have a perfect-storm clock problem. A stock 16 MHz crystal
>> oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged
>> linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5"
>> apart. The clock trace is 8 mils wide, mostly on layer 6 of the board,
>> the bottom layer. We did put footprints for a series RC at the end (at
>> Fpga2) as terminators, just in case.
>>
>> Now it gets nasty: for other reasons, the ground plane was moved to
>> layer 5, so we have about 7 mils of dielectric under the clock
>> microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of
>> tiny stubs, and a couple of vias, and we're at 50 ohms, or likely
>> less.
>>
>> And the crystal oscillator turns out to be both fast and weak. On its
>> rise, it puts a step into the line of about 1.2 volts in well under 1
>> ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1,
>> the clock has a nasty flat spot on its rising edge, just about halfway
>> up. And it screws up, of course. The last FPGA, at the termination, is
>> fine, and the CPU is ancient 99-micron technology or something and
>> couldn't care less.
>>
>> Adding termination at Fpga2 helps a little, but Fpga1 still glitches
>> now and then. If it's not truly double-clocking then the noise margin
>> must be zilch during the plateau, and the termination can't help that.
>>
>> One fix is to replace the xo with something slower, or kluge a series
>> inductor, 150 nH works, just at the xo output pin, to slow the rise.
>> Unappealing, as some boards are in the field, tested fine but we're
>> concerned they may be marginal.
>>
>> So we want to deglitch the clock edges *in* the FPGAs, so we can just
>> send the customers an upgrade rom chip, and not have to kluge any
>> boards.
>>
>> Some ideas:
>>
>> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
>> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
>> maybe, and use the second flop's output as the new clock source. A
>> Xilinx fae claims this won't work. As far as we can interpret his
>> English, the DCM is not a true PLL (ok, then what is it?) and will
>> propagate the glitches, too. He claims there *is* no solution inside
>> the chip.
>>
>> 2. Run the clock in as a regular logic pin. That drives a delay chain,
>> a string of buffers, maybe 4 or 5 ns worth; call the input and output
>> of the string A and B. Next, set up an RS flipflop; set it if A and B
>> are both high, and clear it if both are low. Drive the new clock net
>> from that flop. Maybe include a midpoint tap or two in the logic, just
>> for fun.
>>
>> 3. Program the clock logic threshold to be lower. It's not clear to us
>> if this is possible without changing Vccio on the FPGAs. Marginal at
>> best.
>>
>>
>> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
>> an FPGA?
>>
>> John
>>
>
>you can run a genlocked NCO clocked from in-fabric onchip oscillator. your 
>internal recovered clock will have jitter +-1 clock period of the ring 
>oscillator (what could be as high as about 370MHz in S3), you might need a 
>some sync logic that will ensure the 16mhz clock edges are only used to 
>adjust the NCO.

Nice idea. But I do need the 16 MHz to be long-term correct, although
duty cycle and edges could jitter a bit and not cause problems. So I
could build an internal ring oscillator and use that to resync the
incoming 16 MHz clock (dual-rank d-flops again) on the theory that the
input glitches will never last anything like the 300-ish MHz resync
clock period. And that's even easier.

Thanks for the input,

John

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im 
Newsbeitrag news:0gkg22t80t0838e2odqlfet8h3pror7np4@4ax.com...
> On Mon, 27 Mar 2006 22:35:31 +0200, "Antti Lukats"
> <antti@openchip.org> wrote:
>
>>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im
>>Newsbeitrag news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com...
>>> We have a perfect-storm clock problem. A stock 16 MHz crystal
>>> oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged
>>> linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5"
>>> apart. The clock trace is 8 mils wide, mostly on layer 6 of the board,
>>> the bottom layer. We did put footprints for a series RC at the end (at
>>> Fpga2) as terminators, just in case.
>>>
>>> Now it gets nasty: for other reasons, the ground plane was moved to
>>> layer 5, so we have about 7 mils of dielectric under the clock
>>> microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of
>>> tiny stubs, and a couple of vias, and we're at 50 ohms, or likely
>>> less.
>>>
>>> And the crystal oscillator turns out to be both fast and weak. On its
>>> rise, it puts a step into the line of about 1.2 volts in well under 1
>>> ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1,
>>> the clock has a nasty flat spot on its rising edge, just about halfway
>>> up. And it screws up, of course. The last FPGA, at the termination, is
>>> fine, and the CPU is ancient 99-micron technology or something and
>>> couldn't care less.
>>>
>>> Adding termination at Fpga2 helps a little, but Fpga1 still glitches
>>> now and then. If it's not truly double-clocking then the noise margin
>>> must be zilch during the plateau, and the termination can't help that.
>>>
>>> One fix is to replace the xo with something slower, or kluge a series
>>> inductor, 150 nH works, just at the xo output pin, to slow the rise.
>>> Unappealing, as some boards are in the field, tested fine but we're
>>> concerned they may be marginal.
>>>
>>> So we want to deglitch the clock edges *in* the FPGAs, so we can just
>>> send the customers an upgrade rom chip, and not have to kluge any
>>> boards.
>>>
>>> Some ideas:
>>>
>>> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
>>> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
>>> maybe, and use the second flop's output as the new clock source. A
>>> Xilinx fae claims this won't work. As far as we can interpret his
>>> English, the DCM is not a true PLL (ok, then what is it?) and will
>>> propagate the glitches, too. He claims there *is* no solution inside
>>> the chip.
>>>
>>> 2. Run the clock in as a regular logic pin. That drives a delay chain,
>>> a string of buffers, maybe 4 or 5 ns worth; call the input and output
>>> of the string A and B. Next, set up an RS flipflop; set it if A and B
>>> are both high, and clear it if both are low. Drive the new clock net
>>> from that flop. Maybe include a midpoint tap or two in the logic, just
>>> for fun.
>>>
>>> 3. Program the clock logic threshold to be lower. It's not clear to us
>>> if this is possible without changing Vccio on the FPGAs. Marginal at
>>> best.
>>>
>>>
>>> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
>>> an FPGA?
>>>
>>> John
>>>
>>
>>you can run a genlocked NCO clocked from in-fabric onchip oscillator. your
>>internal recovered clock will have jitter +-1 clock period of the ring
>>oscillator (what could be as high as about 370MHz in S3), you might need a
>>some sync logic that will ensure the 16mhz clock edges are only used to
>>adjust the NCO.
>
> Nice idea. But I do need the 16 MHz to be long-term correct, although
> duty cycle and edges could jitter a bit and not cause problems. So I
> could build an internal ring oscillator and use that to resync the
> incoming 16 MHz clock (dual-rank d-flops again) on the theory that the
> input glitches will never last anything like the 300-ish MHz resync
> clock period. And that's even easier.
>
> Thanks for the input,
>
> John
>
the gen locked NCO would be cycle accurate too, ok I meant you would fine 
adjust the NCO to track the 16mhz
but given and higher clock you can build different deglitch circuitries 
without the need of an full digital PLL technique

antti

On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>John Larkin wrote:
>
>> Some ideas:
>> 
>> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
>> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
>> maybe, and use the second flop's output as the new clock source. A
>> Xilinx fae claims this won't work. As far as we can interpret his
>> English, the DCM is not a true PLL (ok, then what is it?) and will
>> propagate the glitches, too. He claims there *is* no solution inside
>> the chip.
>> 
>> 2. Run the clock in as a regular logic pin. That drives a delay chain,
>> a string of buffers, maybe 4 or 5 ns worth; call the input and output
>> of the string A and B. Next, set up an RS flipflop; set it if A and B
>> are both high, and clear it if both are low. Drive the new clock net
>> from that flop. Maybe include a midpoint tap or two in the logic, just
>> for fun.
>> 
>> 3. Program the clock logic threshold to be lower. It's not clear to us
>> if this is possible without changing Vccio on the FPGAs. Marginal at
>> best.
>> 
>> 
>> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
>> an FPGA?
>
>Enable the schmitt option on the pin :)

Don't I wish! There is a programmable delay element in the IO block,
but it's probably a string of inverters, not an honest R-C delay, so
it likely can't be used to lowpass the edge. We're not sure.

I wish they'd tell us a little more about the actual electrical
behavior of the i/o bits. I mean, Altera and Actel and everybody else
has snooped all this out already.

>Sorry...
>
>Since the issue is 'local', I'd fix it locally, and 2. sounds 
>preferable. You know the CLK freq, so can choose the delay banding.

That's looking promising; we're testing that one now. Gotta figure how
many cells it takes to delay 5 ns. (We'll just xor the ends and bring
that out to a test point.)

John

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com...
> We have a perfect-storm clock problem. A stock 16 MHz crystal
> oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged
> linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5"
> apart. The clock trace is 8 mils wide, mostly on layer 6 of the board,
> the bottom layer. We did put footprints for a series RC at the end (at
> Fpga2) as terminators, just in case.
>
> Now it gets nasty: for other reasons, the ground plane was moved to
> layer 5, so we have about 7 mils of dielectric under the clock
> microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of
> tiny stubs, and a couple of vias, and we're at 50 ohms, or likely
> less.
>
> And the crystal oscillator turns out to be both fast and weak. On its
> rise, it puts a step into the line of about 1.2 volts in well under 1
> ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1,
> the clock has a nasty flat spot on its rising edge, just about halfway
> up. And it screws up, of course. The last FPGA, at the termination, is
> fine, and the CPU is ancient 99-micron technology or something and
> couldn't care less.
>
> Adding termination at Fpga2 helps a little, but Fpga1 still glitches
> now and then. If it's not truly double-clocking then the noise margin
> must be zilch during the plateau, and the termination can't help that.
>
> One fix is to replace the xo with something slower, or kluge a series
> inductor, 150 nH works, just at the xo output pin, to slow the rise.
> Unappealing, as some boards are in the field, tested fine but we're
> concerned they may be marginal.
>
> So we want to deglitch the clock edges *in* the FPGAs, so we can just
> send the customers an upgrade rom chip, and not have to kluge any
> boards.
>
> Some ideas:
>
> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
> maybe, and use the second flop's output as the new clock source. A
> Xilinx fae claims this won't work. As far as we can interpret his
> English, the DCM is not a true PLL (ok, then what is it?) and will
> propagate the glitches, too. He claims there *is* no solution inside
> the chip.
>
> 2. Run the clock in as a regular logic pin. That drives a delay chain,
> a string of buffers, maybe 4 or 5 ns worth; call the input and output
> of the string A and B. Next, set up an RS flipflop; set it if A and B
> are both high, and clear it if both are low. Drive the new clock net
> from that flop. Maybe include a midpoint tap or two in the logic, just
> for fun.
>
> 3. Program the clock logic threshold to be lower. It's not clear to us
> if this is possible without changing Vccio on the FPGAs. Marginal at
> best.
>
>
> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
> an FPGA?
>
> John

Kludge the boards.

The DCM is based on tapped delay lines - the old "Delay Locked Loop" with 
added functionality.  If you have a glitch go in, a glitch will come out.

A bad clock is a bad clock.  You *might* be able to seriously mess with the 
signal by using the KEEPER attribute to push the Spartan3 I/O into a 
schmidt-like behavior but it isn't a good fix, just a punt.  You might also 
try backdriving the pin with a 2mA setting (*not* 2mA at opposite rail - 
check the IBIS model) to push the threshold up or down, but again - this is 
a mess.  It's much better to change the board; my own recommendation is to 
change the oscillator to something with some strength. 

John Larkin wrote:
>>
> And the crystal oscillator turns out to be both fast and weak. On its
> rise, it puts a step into the line of about 1.2 volts in well under 1
> ns, and doesn't drive to the Vcc rail until many ns later.

Why would the signal round-trip delay be several ns,  at 6" or 15 cm
per ns one-way propagation on a pc-board ?
The flat spot at 1.2 V is usually the result of a matched (weak) driver
achieving half-amplitude driving the transmission line, and waiting for
the reflection coming back from the far end. But "many nanoseconds ???
Peter Alfke

On 27 Mar 2006 13:29:02 -0800, "Peter Alfke" <peter@xilinx.com> wrote:

>
>John Larkin wrote:
>>>
>> And the crystal oscillator turns out to be both fast and weak. On its
>> rise, it puts a step into the line of about 1.2 volts in well under 1
>> ns, and doesn't drive to the Vcc rail until many ns later.
>
>Why would the signal round-trip delay be several ns,  at 6" or 15 cm
>per ns one-way propagation on a pc-board ?
>The flat spot at 1.2 V is usually the result of a matched (weak) driver
>achieving half-amplitude driving the transmission line, and waiting for
>the reflection coming back from the far end. But "many nanoseconds ???
>Peter Alfke

Well, two maybe. Is two "many"? What with trace routing and capacitive
pin loading and vias and the pcb dielectric itself, we're talking
velocities well under half of c. The plateau is real as sin, viewed on
a 500 MHz scope with a fet probe.

John

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:eukg22d156r3lq8ke0l63nt7mdvv6fh818@4ax.com...
>>
>>Since the issue is 'local', I'd fix it locally, and 2. sounds
>>preferable. You know the CLK freq, so can choose the delay banding.
>
> That's looking promising; we're testing that one now. Gotta figure how
> many cells it takes to delay 5 ns. (We'll just xor the ends and bring
> that out to a test point.)
>
John,
I've done option 2 before on a sine wave oscillator fed to an FPGA. I used 
the delay element within some unbonded IOBs to get the delay. (Drive signal 
out on O/P, get it back through I/P delay. NB. turn off DRC check in 
bitgen.) I figured it would be more likely to carry on working with newer 
versions of software. Each new version comes up with more fiendish ways to 
remove delay chains!
Good luck, Syms.