deglitching a clock

John Larkin wrote:
> On 27 Mar 2006 15:00:52 -0800, bill.sloman@ieee.org wrote:
>
> >
> >John Larkin wrote:
> >> We have a perfect-storm clock problem.

<snip>

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

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

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.

-- 
Bill Sloman, Nijmegen

On 28 Mar 2006 01:07:52 -0800, bill.sloman@ieee.org wrote:

>
>John Larkin wrote:
>> On 27 Mar 2006 15:00:52 -0800, bill.sloman@ieee.org wrote:
>>
>> >
>> >John Larkin wrote:
>> >> We have a perfect-storm clock problem.
>
><snip>
>
>> 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.
>
>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.

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.

>
>Have you tried another brand of 16MHz clock oscillator? Farnell have
>heaps of alternative parts avaialble off the shelf  in a variety of
>packages.

What's a Farnell?


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

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,

> 
>>Have you tried another brand of 16MHz clock oscillator? Farnell have
>>heaps of alternative parts avaialble off the shelf  in a variety of
>>packages.
> 
> What's a Farnell?
> 

Bill is in Europe. Farnell is one of the distributors over there and 
AFAIK cooperates with Newark on this side of the pond.

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

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

http://www.analogconsultants.com

On Mon, 27 Mar 2006 16:48:20 -0800, "Symon" <symon_brewer@hotmail.com>
wrote:

>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
> >>
>>
>> The unbonded pad thing sounds slick. I argued to use a real pin
>> in-and-out as the delay element, but certain stingy engineers around
>> here are unwilling to give up one of their two available test points.
>>
>> John
>>
>I sent you some stuff from my Hotmail account. If your spam filter blocks 
>it, let me know.
>Best, Syms. 
>

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

On Tue, 28 Mar 2006 11:37:44 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>John Larkin wrote:
>> On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville
>>>Enable the schmitt option on the pin :)
>> 
>> 
>> 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.
>> 
>>>
>>>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.
>> 
>> 
>> 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.)
>
>  Yes, your main challenge will then be to persuade the tools to keep 
>your delay elements...
>  What is the pin-delay on the part - you could use that feature,
>enable it on your pin, drive another nearby pin(s) (non bonded?)
>and then use those as the S/R time-shutters.
>-jg


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

On 28 Mar 2006 10:29:55 -0800, "Jeff Brower" <jbrower@signalogic.com>
wrote:

>John-
>
>Bill Sloman has a point, you shouldn't be so hard on him.

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.

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

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.

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

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

On Tue, 28 Mar 2006 17:37:31 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Hello John,
>
>> 
>>>Have you tried another brand of 16MHz clock oscillator? Farnell have
>>>heaps of alternative parts avaialble off the shelf  in a variety of
>>>packages.
>> 
>> What's a Farnell?
>> 
>
>Bill is in Europe. Farnell is one of the distributors over there and 
>AFAIK cooperates with Newark on this side of the pond.

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.


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

Cruel but true.

John

On Tue, 28 Mar 2006 08:17:23 -0800, John Larkin wrote:
...
> Spare me your armchair theorizing; it's not a "hardware problem" or a
> "software problem", it's just a problem. 
...

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

John Larkin wrote:
> On 28 Mar 2006 01:07:52 -0800, bill.sloman@ieee.org wrote:
>
> >
> >John Larkin wrote:
> >> On 27 Mar 2006 15:00:52 -0800, bill.sloman@ieee.org wrote:
> >>
> >> >
> >> >John Larkin wrote:
> >> >> We have a perfect-storm clock problem.
> >
> ><snip>
> >
> >> 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.
> >
> >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.
>
> 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.

So the Fpga to Fpga routing worked - good.

> >Have you tried another brand of 16MHz clock oscillator? Farnell have
> >heaps of alternative parts avaialble off the shelf  in a variety of
> >packages.
>
> What's a Farnell?

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.

> >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.
>
> I already explained: it's too fast and too weak to drive our
> low-impedance clock line.

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

> It's wildly improbably that a $1.50, 16 MHz
> xo would deliberately include a series terminator... what value would
> they pick?

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.

>And I already explained, several times, we don't want to
> recall all the units in the field.

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.

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

Much more professional-looking, provided that it works.

-- 
Bill Sloman, Nijmegen