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.

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

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

Reply to
John Larkin
Loading thread data ...

"John Larkin" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

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

Reply to
Antti Lukats

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

Reply to
Jim Granville

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

Reply to
John Larkin

"John Larkin" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

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

Reply to
Antti Lukats

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.

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

Reply to
John Larkin

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.

Reply to
John_H

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

Reply to
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

Reply to
John Larkin

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.

Reply to
Symon

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

Reply to
Peter Alfke

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.

--
Bill Sloman, Nijmegen
Reply to
bill.sloman

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

Reply to
John Larkin

The unbonded pad thing sounds slick. I argued to use a real pin in-and-out as the delay element, but certain stingy engineers around here are unwilling to give up one of their two available test points.

John

Reply to
John Larkin

Yes, your main challenge will then be to persuade the tools to keep your delay elements... What is the pin-delay on the part - you could use that feature, enable it on your pin, drive another nearby pin(s) (non bonded?) and then use those as the S/R time-shutters.

-jg

Reply to
Jim Granville

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

Reply to
Rich Grise

I sent you some stuff from my Hotmail account. If your spam filter blocks it, let me know. Best, Syms.

Reply to
Symon

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

--
Ben Jackson

http://www.ben.com/
Reply to
Ben Jackson

Oooooohhhh, nice possibility here ! Great idea, Ben.

Reply to
John_H

Yeah, that would work. I think we do have a few crossover lines, with

0 ohm jumper/resistor pads along the way!

John

Reply to
John Larkin

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.