Maker Pro
Maker Pro

deglitching a clock

J

John Larkin

Jan 1, 1970
0
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
 
J

Jim Granville

Jan 1, 1970
0
John said:
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
 
J

John Larkin

Jan 1, 1970
0
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
 
J

John_H

Jan 1, 1970
0
John Larkin said:
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.
 
P

Peter Alfke

Jan 1, 1970
0
John said:
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
 
J

John Larkin

Jan 1, 1970
0
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
 
P

Peter Alfke

Jan 1, 1970
0
John, here is an idea that eliminates the impact of fast clockglitches:

It uses one LUT plus some routing delay outside the LUT.
Inside the LUT implement a latch plus an AND condition which drives
set, and an other AND to drive reset.
Drive one input of the set AND gate with the inverted clock, the other
input with the delayed Q.
Drive one input of the reset AND gate with the clock and the other with
the inversion of the delayed Q.
The inverters all get folded into the LUT. Q is your cleaned-up clock
signal.

Thus you can only set the latch if it had been reset for awhile, and
you can only reset it if it had been set for awhile.
All in one LUT with 3 inputs: incoming clock, Q output direct, Q output
delayed (somehow...)
(The synthesizer may not like this feedback arangement.)

This (untried) circuit does of course not solve the time uncertainty
due to the flat spot, but it avoids double-triggering.
Peter Alfke

Peter Alfke
 
John said:
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.

I'm with Peter Alfke. Fpga1 is seeing the half-heght pulse on its way
to the end of the line to be reflected back to give you the full height
pulse.

I'd be looking at minor surgery on the board to give Fpga1 its own
private track (or length of VMTX55 1.17mm OD 50R coax cable). I don't
think that the crystal-oscillator output is necessarily weak - it
sounds more as if some clown has embedded a source terminating resistor
inside the package. You might find it worthwhile to extend the minor
surgery to the point of adding a few SOT-23 wideband transistors
(BFR93, BFT93?) to buffer the clock signal. Don't forget the 33R
base-stoppers on the wideband transistors if you do go down this route.

We got forced into this sort of cut and link work to get a prototype
GaAs board working when the PC department mispositioned the -2V plane
that should have been directly under the tracks distributing an 800MHz
ECL-level clock - the clock ended up being distributed on VMTX55 links,
which looked a bit strange, but worked remarkably well.
 
J

John Larkin

Jan 1, 1970
0
I'm with Peter Alfke. Fpga1 is seeing the half-heght pulse on its way
to the end of the line to be reflected back to give you the full height
pulse.

I'd be looking at minor surgery on the board to give Fpga1 its own
private track (or length of VMTX55 1.17mm OD 50R coax cable). I don't
think that the crystal-oscillator output is necessarily weak - it
sounds more as if some clown has embedded a source terminating resistor
inside the package. You might find it worthwhile to extend the minor
surgery to the point of adding a few SOT-23 wideband transistors
(BFR93, BFT93?) to buffer the clock signal. Don't forget the 33R
base-stoppers on the wideband transistors if you do go down this route.

We got forced into this sort of cut and link work to get a prototype
GaAs board working when the PC department mispositioned the -2V plane
that should have been directly under the tracks distributing an 800MHz
ECL-level clock - the clock ended up being distributed on VMTX55 links,
which looked a bit strange, but worked remarkably well.


If we wanted to spin the board layout, we could just put in the
risetime-limiting inductor, or add a meaty clock buffer, or better yet
add a series resistor, with maybe an optional cap to ground, to slow
down the sig on the clock line, and then add a Tiny Logic schmitt
buffer at each chip. But as I noted, the challenge here is to find a
software-only fix.

John
 
R

Rich Grise

Jan 1, 1970
0
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.

I fear there may be no quick fix. The waveform you've described sounds
almost exactly like what I've seen on a TDR (except, of course, at 6"
rather than 8 feet :) ) so I'm surmising that there's some transmission
line mismatch that's giving you that nasty reflection.

But impedance matching a clock line on an 8-layer board is way out of
my league. )-;

Good Luck!
Rich
 
B

Ben Jackson

Jan 1, 1970
0
We have a perfect-storm clock problem. A stock 16 MHz crystal
oscillator drives a CPU and two Spartan3 FPGAs.
... 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

Got any spare interconnects between FPGA2 and FPGA1? A new bitstream
could ignore the clock at FPGA1 and get it from FPGA2.
 
J

John_H

Jan 1, 1970
0
Ben Jackson said:
Got any spare interconnects between FPGA2 and FPGA1? A new bitstream
could ignore the clock at FPGA1 and get it from FPGA2.


Oooooohhhh, nice possibility here !
Great idea, Ben.
 
J

John Larkin

Jan 1, 1970
0
Got any spare interconnects between FPGA2 and FPGA1? A new bitstream
could ignore the clock at FPGA1 and get it from FPGA2.

Yeah, that would work. I think we do have a few crossover lines, with
0 ohm jumper/resistor pads along the way!

John
 
If we wanted to spin the board layout, we could just put in the
risetime-limiting inductor, or add a meaty clock buffer, or better yet
add a series resistor, with maybe an optional cap to ground, to slow
down the sig on the clock line, and then add a Tiny Logic schmitt
buffer at each chip. But as I noted, the challenge here is to find a
software-only fix.

This is the manager talking, rather than the engineer. This is a
hardware problem, and it sounds as if you've already spent more time on
trying to find a software sticking-plaster than is cost-effective.

Have you tried another brand of 16MHz clock oscillator? Farnell have
heaps of alternative parts avaialble off the shelf in a variety of
packages.

If the part you are using really does have a built-in source
termination resistor - which does seem to be the most likely
explanation of the flat spot on the clock waveform at Fpga1 - swapping
to a different manufacturer might cure the problem.
 
J

John Larkin

Jan 1, 1970
0
This is the manager talking, rather than the engineer. This is a
hardware problem, and it sounds as if you've already spent more time on
trying to find a software sticking-plaster than is cost-effective.

Spare me your armchair theorizing; it's not a "hardware problem" or a
"software problem", it's just a problem. We have, in a few hours,
found and tested an excellent FPGA-internal fix that we can pop into a
rom and mail to our customers. We'll include a couple of other nice
firmware improvements, while we're at it. Your definitions of
"manager" and "engineer" do not constrain my latitude to think.
Have you tried another brand of 16MHz clock oscillator? Farnell have
heaps of alternative parts avaialble off the shelf in a variety of
packages.

What's a Farnell?

If the part you are using really does have a built-in source
termination resistor - which does seem to be the most likely
explanation of the flat spot on the clock waveform at Fpga1 - swapping
to a different manufacturer might cure the problem.

I already explained: it's too fast and too weak to drive our
low-impedance clock line. It's wildly improbably that a $1.50, 16 MHz
xo would deliberately include a series terminator... what value would
they pick? And I already explained, several times, we don't want to
recall all the units in the field.

We could have sent them a small ferrite disk, to be glued into the top
of the board over the clock trace (we'd of course furnish a tube of
glue, no extra charge) that would fix it too. But I think the ROM swap
is more professional and managerial.

John
 
J

Joerg

Jan 1, 1970
0
Hello John,
What's a Farnell?

Bill is in Europe. Farnell is one of the distributors over there and
AFAIK cooperates with Newark on this side of the pond.
We could have sent them a small ferrite disk, to be glued into the top
of the board over the clock trace (we'd of course furnish a tube of
glue, no extra charge) that would fix it too. But I think the ROM swap
is more professional and managerial.

Cool. You could ship these in prescription med containers and call it
"Extra Strength Larkinin" or something like that. With luck someone will
later claim that they cure rheumatism and you'd have a new biz line that
probably makes more money than anything before.

Regards, Joerg
 
J

Jeff Brower

Jan 1, 1970
0
John-

Bill Sloman has a point, you shouldn't be so hard on him. Many of our
customers require a summary of what's been changed in a logic upgrade
-- these tend to be the ones who know something about programmable
logic. If we listed "clock deglitch" then there would be a good chance
they would want more information, which might lead to more discussion
about using a delay line based on buffers (or whatever is your fix),
which might lead to us having to update boards in the field with a
hardware fix to a hardware problem (at our cost). If one of my
engineers omitted or lied about what we changed and I found out... well
that's another problem, constrained by ethics and rules and not by
creative thinking.

I hope your fix is solid and based on sound engineering techniques, and
your customer -- if they knew -- would be Ok with it. If so then I've
missed the mark and I apologize in advance for chiming in.

-Jeff
 
J

John Larkin

Jan 1, 1970
0
John-

Bill Sloman has a point, you shouldn't be so hard on him.

Sloman has, for years, followed me around, biting at my ankles,
changing the subject from technical issues to the subject of my
personal mental and nationalistic shortcomings. Our very first
encounter began just that way, and he's kept it up well past the point
of tedium. It's hard to not do what's natural, namely be outright
cruel to him, which would be both easy and satisfying.
Many of our
customers require a summary of what's been changed in a logic upgrade
-- these tend to be the ones who know something about programmable
logic. If we listed "clock deglitch" then there would be a good chance
they would want more information, which might lead to more discussion
about using a delay line based on buffers (or whatever is your fix),
which might lead to us having to update boards in the field with a
hardware fix to a hardware problem (at our cost). If one of my
engineers omitted or lied about what we changed and I found out... well
that's another problem, constrained by ethics and rules and not by
creative thinking.

We've absolutely honest with all our customers. There are ten or so
similar units in the field, working fine, that could some day manifest
the clock glitch problem, and it would be easy to keep quiet and bet
that nothing goes wrong. We're going to tell them about the hazard,
and send them new roms to upgrade the FPGA configs. Our customers,
especially the areospace guys, love this sort of attitude.
I hope your fix is solid and based on sound engineering techniques, and
your customer -- if they knew -- would be Ok with it. If so then I've
missed the mark and I apologize in advance for chiming in.

No apology needed; different companies just have different customer
bases and different policies in cases like this. If it was a TV remote
that hit the wrong channel occasionally below 5 degrees C, I wouldn't
volunteer to replace them all. But our gadgets are testing jet
engines.

The current fix tests good and sure looks solid.

John
 
J

John Larkin

Jan 1, 1970
0
Hello John,


Bill is in Europe. Farnell is one of the distributors over there and
AFAIK cooperates with Newark on this side of the pond.

Oh, I knew that; Bill plugs Farnell in most of his posts. But why
would I buy oscillators from Farnell, when we're 40 miles away from a
zillion distributors in Silicon Valley? And I pointed out, certainly
no more than six or eight times, that I was looking for a fix that did
*not* involve hacking the hardware.

Cool. You could ship these in prescription med containers and call it
"Extra Strength Larkinin" or something like that. With luck someone will
later claim that they cure rheumatism and you'd have a new biz line that
probably makes more money than anything before.

Cruel but true.

John
 
R

Rich Grise

Jan 1, 1970
0
.
Spare me your armchair theorizing; it's not a "hardware problem" or a
"software problem", it's just a problem.
....

Q: How many programmers does it take to change a light bulb?
A: None, that's a hardware problem.

Q: How many engineers does it take to change a light bulb?
A: No problem! We'll fix it in software!

;-)

Cheers!
Rich
 
Top