deglitching a clock

That's not what we did. We designed a clock deglitcher to go inside the FPGA.

John

Enough propagation delays to cover the dwell at the switching threshold, and a state machine to make sure that the clock only changes state once in that interval?

We did my original #2 suggestion, a tapped delay line driven from the pin, driving an r-s flipflop. Set the flop if all the taps are 1s, clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter. The delay line is a string of eight buffers, about 10 ns overall.

We'd have done Peter's circuit if we'd learned of it sooner.

It's interesting that my post evoked two classes of response:

1. It can't be done, don't do it, kluge the boards (also the official Xilinx response!)
2. Yes, and here are my ideas on how you could do it/how I've already done it/interesting asides.

John

Put me *SQUARELY* in category 1. You have a HW problem that demands a re-layout. The kludges presented here may work for quantity 1, but you will have trouble trying to build many of these. And this approach is wholly unacceptable for a product that will ship to customers. 'Deglitchers' are for mechanical switches, not clocks.

There are some basic elements that must work on a digital circuit board, and the 'clock' falls into this category.

Hello John,

That probably depends on what kinds of projects the individual responders usually work on. In my field (medical) I could lose my shirt if I did the digital de-glitcher thing. If it's an application where nothing bad can happen when it chokes or where that condition will always be signaled it might be different. But I wouldn't do it.

Regards, Joerg

John,

I assume before this that the clock was going into a global clock pin? If so, how do you deal with losing the low skew chip-wide network now that you're coming in on a standard I/O pin?

Take care, Rob

Why? What we're doing is perfectly sound, and works exactly as expected.

Too late, a bunch have already been shipped.

Bit who gets to decide "unacceptable"? And who enforces it?

Is that an Federal law or something? Are all those millions of Sonet clock-recovery PLLs out there illegal?

Right; it works fine now.

John

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.

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

Don't answer him.

He just likes to see who can piss the farthest.

OK ;-)

...Jim Thompson

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,

I'm just finishing up a VME tach/overspeed shutdown module for GE. It

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