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

    Why? What's a *rational* reason why we shouldn't use the clock
    deglitcher? It has made the logic perfectly reliable, it makes sense,
    it absolutely solves a problem, and it provides a clean, easy, safe
    field upgrade: the user replaces an eprom, and if it passes its
    powerup checksum, and then the FPGA configures, it's absolutely fixed.

    Terms like "unacceptable" and "good engineering practice" and
    "hardware problem" are just dogma. If we've fixed the clock problem to
    the point where it has no significant contribution to product MTBF,
    what's wrong with the fix? Kluging the boards would be a bigger
    reliability hazard, what with parts and wires hanging off.


    OK: *rational* reason?

    John
     
  2. John Larkin

    John Larkin Guest

    I saw one partially assembled at the P&W maintanance training
    facility. It was a 70,000 pound thrust fanjet, with about a 12'
    diameter front fan. Just outside the scoop is a roughly 2 foot wide,
    14' diameter, 4" thick kevlar-epoxy band, nice translucent amber. If
    the thing throws a blade, it's supposed to catch it. They *do* test
    this, revving up the engine (I think they spin it with an electric
    motor) and using explosives to break the blades off the hub. I'd love
    to see that test.

    I'm just finishing up a VME tach/overspeed shutdown module for GE. It
    *will* be responsible for not blowing up engines.

    John
     
  3. Joerg

    Joerg Guest

    Hello John,
    If you have to live with a clock that comes in via a noisy channel, yes.
    Just not to fix an on-board problem. In medical the lawyers would be all
    over us if something happens and an expert witness finds out.

    Regards, Joerg
     
  4. Guest

    I've heard that one before.
    Not knowing the Fpga or what you were doing with it, I was never likely
    to contribute anything interesting on that front anyway.
    He seemed to be the top guru on comp.arch.fpga when I last looked. I've
    referenced him on sci.electronics.design from time to time - Tues, Mar
    2 2004 5:55 am would be the most recent one. It looks as if I first ran
    into him in 1997.
    The VMTX55 coax is remarkably discreet, particularly if you glue it
    down. You might use some kind of buffer to drive it - whence my
    transistors. If the Fpga could accept LVDS signal levels, you wouldn't
    need anything like as much voltage swing and might get away with
    something really evil, like a resistive divider.
     
  5. Jeeze, I wonder why so few real-world issues and solutions are
    discussed here.


    Best regards,
    Spehro Pefhany
     
  6. Nico Coesel

    Nico Coesel Guest

    Xilinx is good with keeping information under their hat. One of the
    projects I'm currently working on needs a re-design of the PCB because
    the pin arrangement I had in mind is simply not possible. But the
    datasheet and application notes don't mention a word about limits on
    IOBs.
     
  7. John  Larkin

    John Larkin Guest

    Can you be more specific about what went wrong? I thought I knew all
    the (many) rules about i/o pin behavior and grouping. It's quite a
    puzzle already.

    We always pre-assign pins based on what the pcb layout prefers, and
    design the fpga concurrently with the pcb layout, or more often after
    it's been sent out to etch. Your situation sounds scairy.

    I wonder if anyone has ever kluged a bga layout, sort of like one of
    those jellyfish with a thousand tentacles.

    John
     
  8. Falk Brunner

    Falk Brunner Guest

    Really? I doubt it. And NO, Iam not paid by Xilinx ;-)
    What was the problem? Often enought, people tend to just fly over the
    datasheets, instead of studing them carefully. All those tiny little
    footnotes . . .

    Regards
    Falk
     
  9. John_H

    John_H Guest

    Since I've never had an IOB problem in the several generations of Xilinx
    families I've designed with, what information was lacking from your
    perspective? (And what device family?)
     
  10. Keith

    Keith Guest

    Whatever people's opinion on the validity of the fix, I think that it's
    a good time for your engineering team to do some introspection. Think
    about why this problem wasn't detected before shipping the boards to
    customers? Should you do some signal integrity checks when bringing up
    new boards? Have you run the boards in a thermal chamber? Does it make
    sense to vary the supply voltages too? Should you develop a checklist
    so that it won't happen again? Etcetera...
     
  11. John Larkin

    John Larkin Guest

    We only sent one V450 to a customer, and that was a freebie, so that
    they could start writing drivers. We knew something was sometimes
    slightly funny, but it mostly worked, and we told the guy that it was
    a beta and would likely need changes. It was during testing here that
    we looked into the strangeness in detail and found the clock problem.

    There are about 10 V470's in the field. They have the same clock and
    fpga's and the same basic layout, but for some reason they all work
    fine. We will nevertheless upgrade them with the clock deglitcher.

    And we sure will be more careful about oscillators and clock
    distribution in the future... everything's getting too fast. It was
    probably the move of the ground plane to layer 5 of 6 (the clock is
    mostly routed on 6), and the fast/weak xo, that caused the problem.
    Clock-on-the-bottom isn't ideal for noise immunity, either.

    Here's the gadget, but you can't see anything relevant in this pic,
    just barely the last FPGA in the clock string at the top...

    http://www.highlandtechnology.com/DSS/V470DS.html

    The xo is near the bottom, between the metal cover and the eprom, the
    dark thing poking out.

    John
     
  12. Nico Coesel

    Nico Coesel Guest

    I've designed a DDR200 memory interface in a Spartan3 200k gates
    device. A quick introduction: DDR memory has a bi-directional data
    clock (DQS) which is driven by the memory when data is read and driven
    by the FPGA when the data is written into the memory. This means I
    need to use a local clock for every byte lane (4 lanes in total) to
    clock the data into the device or drive DQS from the internal clock.
    This caused 2 problems:

    1) It turns out not every pin can be routed efficiently to form a low
    delay local clock to clock adjacent pins. Worse, only the top and
    bottom sides of the FPGA (the clock pins are on the left and right
    sides) feature real fast routing between IOBs. Determining the right
    pins to use is a trial-and-error process.

    2) It also appears most IOBs are actually implemented as a dual IOB
    elements which share certain pins, including the clock pin. This means
    that it is not possible to have a DQS line share a 'dual IOB' with a
    data pin since two different clocks are required.

    I can't find any references to these limitations in the datasheet. A
    DDR memory interface application note makes a short notice of some
    limitations on placement, but thats all there is.

    I did manage to bypass these problems on my prototype with some
    additional wiring to connect the DQS to some unused pins and use an
    internal clock to capture the data. This works for now, but I don't
    want to put this solution into a production device.
    I did the same. I designed the PCB first after studying the FPGA
    datasheet thouroughly. I even created the possibility to use the DCI
    (digitally controlled impedance).
     
  13. Nico Coesel

    Nico Coesel Guest

    Another example: Several years ago I made JTAG programming routines
    for a Spartan 2 according to Xilinx application notes (verified bit by
    bit with a logic analyzer). For some reason these routines didn't work
    on a Spartan 2E device. I got it working in the end by thinking
    logically on how the device should be initialized to accept a
    configuration, but the result is definitely not according to Xilinx's
    documentation.
     
  14. Joerg

    Joerg Guest

    Hello John,
    If you don't have one already get a fast FET probe. I find that an
    indispensable tool to check fast clocks and stuff. The usual resistive
    divider into a coax works as well but it's more clumsy. Good FET probes
    come with neat low inductance connection tools.

    Nice. You guys sure do clean mechanical designs. At one client we
    provided a phone jack at the front through which the boards could be
    diagnosed and SW-upgraded. We even had some where you could connect a
    touch-tone phone and use its keypad to change some settings.

    That was in the early 90's. Nowadays I guess it would be a USB jack or,
    gasp, a Bluetooth link.

    Regards, Joerg
     
  15. John  Larkin

    John Larkin Guest


    We have a TDS3052 (500 MHz) scope with the 1 GHz fet probes. Next
    would be the big ole 7104 (1 GHz) analog scope, with a 1 GHz fet
    probe. Our ultimate weapon is an 11801 with an SD-14 sampling head,
    ..25 pF and 3 GHz at the probe tip. I love scopes.

    Interestingly, the fpga glitch stopped when the TDS probe was touched
    on the clock pin of the 2nd FPGA, which added about 0.5 pF.

    John
     
  16. Ken Smith

    Ken Smith Guest

    More likely it would be a costly blind-via PCB that sits between the BGA
    and the base PCB. (Vomit)

    When I do a board with CPLD on it, I sometimes wire the unused pins
    together in some random arrangement. You can't get fast signals out and
    back but you can do a few slow ones.

    On my current project I'm up to 380 out of 512 used. This is making me
    nervous.
     
  17. Then I'll put the hex on this, by asking :
    " What could marketing possibly dream up, that could use more than
    the 132 spare pins !?" :)

    -jg
     
  18. Rob

    Rob Guest

    Interestingly, the fpga glitch stopped when the TDS probe was touched
    I hate when that happens :)
     
  19. Phil Hays

    Phil Hays Guest

    The change in stackup might have made the problem worse, but
    daisy-chained clocks are a bad idea with high speed logic. It is
    better to star route them, with equal length lines from the clock
    driver to each destination with source termination resisters. For a
    fanout greater than 1, don't use the oscillator output directly, use
    it to drive a higher drive gate.

    Daisy chaining clocks is bad for signal integrity and for clock skew.
     
  20. Fred Bartoli

    Fred Bartoli Guest

    On time we had a CPLD interfacing two asics together.
    Debugged the protos/first runs, temperature tests,... All OK.
    Then we had one particular board, tested OK in July/August which developped
    random failure when coming back from vacation in september.
    A bit of investigation revealed that the asic interface wasn't behaving
    according to the datasheet (wrong sampling clock front IIRC).
    It worked OK with the July/August high temperatures (timings were marginally
    OK). In September not anymore.

    Whew, a few days later the client was launching a first 1000 boards run
    (CPLD soldered and not ISP). The boards were HDSL repeaters installed
    everywhere, often in particularly hard to access places.
     
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

-