deglitching a clock

If your application is critical, one could argue that you are in fact obligated to do this to increase clock noise immunity.

But we're just testing jet engines.

John

We now treat that pin as a regular input. After the deglitch logic, we pipe it into a global clock buffer, and it becomes the new 16 MHz master clock for the whole chip.

John

I think I'm in that catagory, though I'd describe my response as saying that it shouldn't be done in software - if for no other reason than that the dwell time at 1.2V eats into your timing error budget - and that the time you'd already spent on looking for a software solution should have been enough to find one (which turns out to have been correct).

Granting that I was fixated on the hardware solution, I did suggest how you might hack the board, based on a problem that I'd been a party to, many years ago.

--
Bill Sloman, Nijmegen

It doesn't. We're running a 300 MHz FPGA at 16 MHz. Pushing the clock edges a few ns one way or the other doesn't matter.

If you reject a concept out of hand, you're not likely to subsequently contribute interesting ideas on how to implement it.

It was. And if we'd waited a few hours, we'd have used Peter Alfke's circuit, which preserves clock edge timing and is quite a bit more elegant than our atrocity. Peter is the senior-stateman Xilinx app engineer (he wrote a lot of their appnotes) and he invented his deglitch thing on the spot for us. Our "official" Xilinx fae was a #1 type, "it shouldn't and can't be done."

I met Peter at the now-departed Foothill Electronic Flea Market, where we both had our heads inside a big cardboard box of old books. After that intimacy, we naturally started talking, and he convinced me that we should dump Actel for Xilinx. He even told me where to get the student version of the software cheap! He had a great line: "I can tell by your hair that you'll prefer schematic entry."

The coax hack wouldn't work, for the exact reason we have trouble with the existing clock net: the xo can't put enough voltage into a 50 ohm line. Besides, the hack would be hideous. If anything is truly "unacceptable" around here, it's ugly boards.

John

I've heard they can be pretty nasty if they overspeed and blow up.

Thanks, Rich

John -- Please, please avoid doing any mission critical or life support design.

And your credentials ?:-)

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

| 1962 | I love to cook with wine. Sometimes I even put it in the food.

Don't answer him.

He just likes to see who can piss the farthest.

OK ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

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

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

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

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.

--
Bill Sloman, Nijmegen

Jeeze, I wonder why so few real-world issues and solutions are discussed here.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

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

Nico Coesel schrieb:

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

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

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