deglitching a clock

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.

John

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

No, I got it, thanks hugely. That raises all sorts of possibilities for the future, what with pad capacitance, tristate drivers, strong and weak pullups, LVDS, all sorts of possible tricks.

John

What's working now is my option #2, delay line with ANDs driving an r-s flop. The delay is eight internal buffers, giving us about 10 ns. We're using the midpoint tap, 5ns out, in the logic too, just in case. We ran tests on two boards, overnight, and it seems to work fine.

We don't care about absolute delay or jitter here; if we did, we'd probably use Peter's circuit, which propagates clock edges but supresses additional transitions for a while. I shoulda thunk of that.

Thanks to everybody for some great ideas. Several of the suggestions (internal ring oscillator, using unbonded pads, Peters's double-edge circuit) are good to know about.

John

John-

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.

-Jeff

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

The current fix tests good and sure looks solid.

John

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.

John

On Tue, 28 Mar 2006 08:17:23 -0800, John Larkin wrote: ...

...

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!

;-)

Cheers! Rich

So the Fpga to Fpga routing worked - good.

The peope who bought Newark. Win Hill got their catalogue years ago - they are just another broad-line distributor. I check out the Digi-Key catalogue from time to time (and don't like it as much) but Farnell's is the one that I've largely memorised.

"Fast" and "weak" is an odd combination - FWIW my impression was that packaged crystal oscillators used regular logic chips.

If they were selling stuff that mostly went onto PCI bus lines, they might read the spec. AMD sold a TTL line driver for years with roughly

22R built into the pull-down side of the output to match the output impedance of the pull-up circuit. Around 22R was commonly used to tame (but not source terminate) outputs driving long buses.

Nobody ever does. Cambridge Instrument's service engineers used to change parts on boards on-site, which wasn't cheap either, and you'd seem to be working working with roughly the same kinds of customers.

Much more professional-looking, provided that it works.

--
Bill Sloman, Nijmegen

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?

--
Bill Sloman, Nijmegen

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

'We tried that before and it didn't work'

'OK, what did you try before'

'He was very good and proved it didn't work with some maths type stuff and it didn't work'

'Yes, but what did he try'

'It didn't work'

'But, what was it'

'It didn't work'

'Have you got the information about it'

'Err, no, err hang on.'

Waits a while. Mouldy thing arrives.

'There you go, see doesn't work'

'OK, let me have a look'

Goes away for a bit of.....

Comes back

'So, the problem is he did it like this'

'Doesn't work'

'Yes... but if you do it like this' Spends some time explaining....

'He was very clever, see... here's the math, it doesn't work. We've tried it before and it doesn't work'

'OK, but if you do it like this then it will work'

'No, we've already tried it and it doesn't work'

'You've tried it the way that I'm suggesting'

'Pardon'

'This way'

'Erm, he was very clever. Look, if you take some time then you can see that it doesn't work... How did you answer the 'Where do you see yourself in five years time' question at the interviev?'

DNA

"Genome" a écrit dans le message de news:sLCWf.25632$ snipped-for-privacy@newsfe4-win.ntli.net...

message

it

that

five

ROFL.

- OK, but I don't understand why it can't work. Please let me try and learn by myself why it can't. ... ...

- Oh, but you made it work. How can it be?

- Oh. That's pretty simple: I just didn't know it couldn't work :-)

--
Thanks,
Fred.

Fred Bartoli schrieb:

Yep. But try better quoting.

I just saw a nice TV show, which ended with the words.

Theory is the thing you can't understand. Practice is the thing you can't explain.

Regards Falk

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

A couple of questions for those who are in 1),

Would you use the Pin-Delay feature on a FPGA, to de-skew click lines from other devices ?

If you are OK with that, suppose John now uses the same Pin-delay feature (chained) on his 'toggle rate governer' - is that then OK ?

-jg