Severe Overshoot Mailbag

I received a number of interesting emails in response to a previous newsletter on Severe Overshoot. Here are some of the most interesting.

Best Regards,
Dr. Howard Johnson

Today I received your "severe overshoot" article and wanted to offer up my experiences.

I have found that some 3.3 V parts with 5 V tolerant inputs can survive at least 5 V on their inputs but use a string of diodes to clamp the input to not much more than 5 V.

Alas, the clamp diode string proved our undoing because when the overshoot was clamped, it shot current into the VCC net, adding noise to the internal PLL circuitry. Lowering the input levels to 3.3 V greatly improved clock recovery performance.

Of course, this clamp-injected noise could be an issue anytime an input approached the clamp limits for a part. In a recent PLL design, I used a differential pair to create a 1 V to 4 V input swing into a 5 V 74AC86, whose *analog* output became the raw material for the analog loop filter.

It's amazing how many PLL designs use a fairly noisy VCC and then add more noise due to full- amplitude inputs, and then wonder why there is so much jitter. (Using a spike-output phase detector instead of an XOR-output phase detector would nearly eliminate the power-supply-induced noise, but one must then face the "dead band" in the phase- detector characteristic.)

Please keep your thought-provoking articles coming.

I have a comment about undershoots. I have taken over some designs here, and there were and are some undershoots. A few problems undershoots cause:

Besides simple ringing and timing issues due to undershoot, and possible damage to inputs, there are more subtle effects, such as:

Undershoot on some lines on some SRAM chips will cause "weak writes", where data are written into the chip, and then you have it - data in some location, appearing outta nowhere. Dampen the shoot, and the effect disappears.

Some state machines in some ISP FPGA's that provide for in-circuit programmability, will go haywire because of an undershoot, and then you wonder - hell, the prog cycle on this thing is 250 kHz, damn slow, and it won't program correctly. Then you find an undershoot on the clock-data pulses.

One could continue forever with this.

Unfortunately, especially in cases of taking over something, it is not always possible to do everything by the book.

Say I have a daughter board on my board that has 4 chips to program on it, and they are not really lumped. It's a daisy-chain. Whatever I do, my clock- signal looks ugly.

Well, that's it. Good luck and GOOD TERMINATION!

First, let me explain that I have been working with high speed signals for over ten years and am still learning every day and especially from these High Speed Design notes which I read religiously.

My only comment is a simple one that Dr. Johnson did not mention, which is to make sure you are measuring the overshoot correctly. You can get overshoot on the scope that is not really there by using long ground leads on your scope probe which is due to the added inductance of the leads which Dr. Johnson has talked about many times.

I feel this is the first thing that should have been mentioned. I am presently working with several young engineers who have made this mistake and were seriously concerned about an overshoot problem of about 2 volts that was not there. Measured correctly, the overshoot was really only about 1/2 volt.

I assume you are using FET probes to a high bandwidth scope with short leads. For high speed signals, picosecond rise times, we don't even use leads, we use low impedance pins so that our total return path is less than 1/2 inch.