Connect with us

deglitching a clock

Discussion in 'Electronic Design' started by John Larkin, Mar 27, 2006.

Scroll to continue with content
  1. John Larkin

    John Larkin Guest

    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

    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

    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

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

  2. Enable the schmitt option on the pin :)

    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.

  3. John Larkin

    John Larkin Guest

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

  4. John_H

    John_H Guest

    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.
  5. Peter Alfke

    Peter Alfke Guest

    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
  6. John Larkin

    John Larkin Guest

    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.

  7. Peter Alfke

    Peter Alfke Guest

    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

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

    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

    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.
  9. John Larkin

    John Larkin Guest

    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.

  10. Rich Grise

    Rich Grise Guest

    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!
  11. Ben Jackson

    Ben Jackson Guest

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

    John_H Guest

    Oooooohhhh, nice possibility here !
    Great idea, Ben.
  13. John  Larkin

    John Larkin Guest

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

  14. Guest

    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

    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.
  15. John  Larkin

    John Larkin Guest

    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.
    What's a Farnell?

    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.

  16. Joerg

    Joerg Guest

    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.
    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
  17. Jeff Brower

    Jeff Brower Guest


    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.

  18. John Larkin

    John Larkin Guest

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

    The current fix tests good and sure looks solid.

  19. John Larkin

    John Larkin Guest

    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.

    Cruel but true.

  20. Rich Grise

    Rich Grise Guest


    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!


Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day