deglitching a clock

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 Larkin wrote:
> 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.

-- 
Bill Sloman, Nijmegen

On 27 Mar 2006 15:00:52 -0800, bill.sloman@ieee.org wrote:

>
>John Larkin wrote:
>> 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.


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

On Mon, 27 Mar 2006 14:31:13 -0800, "Symon" <symon_brewer@hotmail.com>
wrote:

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

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

John Larkin wrote:
> On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville
>>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.
> 
>>
>>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.)

  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

On Mon, 27 Mar 2006 14:21:16 -0800, John Larkin wrote:
> 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.
> 

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

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
 >>
>
> 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
>
I sent you some stuff from my Hotmail account. If your spam filter blocks 
it, let me know.
Best, Syms. 

On 2006-03-27, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
> 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.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

"Ben Jackson" <ben@ben.com> wrote in message 
news:slrne2h2ga.2ulk.ben@saturn.home.ben.com...
> On 2006-03-27, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> 
> wrote:
>> 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.
>
> -- 
> Ben Jackson
> <ben@ben.com>
> http://www.ben.com/


Oooooohhhh, nice possibility here !
Great idea, Ben. 

On Mon, 27 Mar 2006 18:57:46 -0600, Ben Jackson <ben@ben.com> wrote:

>On 2006-03-27, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>> 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.

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

John