The problem with these two words (over / undershoot) is that they can be used
from different view points.
I think we all agree that overshooting means going over a specified goal.
Following this logic, undershooting should mean going under that specified goal
or not reaching it. In terms of signal integrity this could be translated to:
a) overshoot - caused by a buffer that is too strong,
b) undershoot - caused by a buffer that is too weak.
This viewpoint uses the desired voltage level of the transition as the
determining factor in choosing one of those two words. Case b) above, however,
could also be described with different words all together, such as "the signal
takes several round trips to switch", or "the ledging or staircase like waveform
of the driver shows up at the receiver".
A different viewpoint uses the words over / undershoot based on the direction of
a) overshoot - caused by a buffer that is too strong for a rising edge,
b) undershoot - caused by a buffer that is too strong for a falling edge.
In this case we are referring to the case when the buffer is too trong with both
words, so we loose the ability to describe the weak buffer case. (But remember
we can still talk about that case with different words as I did above).
Both of these viewpoints are valid and correct, so I don't see anything wrong
with using the word overshoot instead of for undershoot.
In my experience, however, the slow buffer case is usually talked about with
those alternate phrases I used above. So because of the additional
(directional) information I like to use over / undershoot as follows:
Overshoot is a signal that goes above the supply rail,
Undershoot is a signal that goes below the ground rail, and
Ringback is what happens after an over or undershoot event,
when the signal comes back from over or undershooting
and finds itself way inside the rails.
However, the term undershoot is some times also used for ringback (as defined
above). (I know of a CAD tool vendor who does it that way). I don't see how
this makes sense, because it is a completely different phenomena. Ringback is
the result of over/undershoot and would not happen without it. So referring to
it as undershoot makes no sense to me. (If someone can give me a good reason
why ringback should be called undershoot, I might change my mind).
Another opinion I would like to air out here is regarding how overshoot is
measured (in the lab as well as simulations). I prefer to measure the overshoot
with respect to the supply voltage and NOT with respect to the ground, as so
many like to measure it that way! After all, the delta between the peak and the
rail is what is important, and that is how undershoot is also measured. In
order to be able compare overshoot and undershoot in a meaningful way they need
to be measured similarly. Many times the providers of overshoot data do not
specify what the supply was (i.e. nominal, minimum, maximum, etc) so it is
really difficult to guess what the real overshoot delta was if the data is
presented with respect to ground. Don't even mention the wide variety of supply
and termination voltages out there these days (5.0 V, 3.3 V, 2.5 V, 1.8 V, 1.5
I have a question. When the term "undershoot" is used
on this mail group is it to be interpreted as "negative overshoot"?
Or in fact are some engineers having undershoot problems?
My experience would indicate that most persons referring to
undershoot really mean overshoot below 0V.
Text item: External Message Header
The following mail header is for administrative use
and may be ignored unless there are problems.
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
Content-Type: text/plain; charset=us-ascii
X-Priority: 3 (Normal)
Subject: [SI-LIST] : Overshoot/Undershoot
To: Si List <si-list@silab.Eng.Sun.COM>
X-Mailer: Mozilla 4.01 [en] (Win95; U)
From: Bill Dempsey <firstname.lastname@example.org>
Date: Mon, 23 Feb 1998 15:05:06 -0600
Received: from canyon.dnaent.com (canyon.dnaent.com [192.168.1.63]) by renner.dn
aent.com (8.6.12/8.6.12) with ESMTP id PAA20661 for <si-list@silab.Eng.Sun.COM>;
Mon, 23 Feb 1998 15:06:12 -0600
Received: from dnaent.com (uucp@localhost) by pyxis.dnaent.com (8.6.12/8.6.12) w
ith UUCP id PAA20174 for si-list@silab.Eng.Sun.COM; Mon, 23 Feb 1998 15:17:29 -0
Received: from pyxis.dnaent.com (pyxis.dnaent.com [126.96.36.199])
by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA08251
for <si-list@silab.Eng.Sun.COM>; Mon, 23 Feb 1998 13:11:32 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [188.8.131.52])
by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA13005
for <si-list@silab.Eng.Sun.COM>; Mon, 23 Feb 1998 13:11:36 -0800
Received: from Eng.Sun.COM by silab.eng.sun.com (SMI-8.6/SMI-SVR4)
id NAA21108; Mon, 23 Feb 1998 13:13:09 -0800
Received: by silab.eng.sun.com (SMI-8.6/SMI-SVR4)
id NAA21112; Mon, 23 Feb 1998 13:13:12 -0800
Received: from silab.eng.sun.com (silab.Eng.Sun.COM [184.108.40.206])
by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA20728;
Mon, 23 Feb 1998 13:37:07 -0800
Received: from Eng.Sun.COM (engmail1 [220.127.116.11]) by mercury.Sun.COM (SMI-8.6
/mail.byaddr) with SMTP id NAA00027; Mon, 23 Feb 1998 13:37:15 -0800
Received: from mercury.Sun.COM (mercury.Sun.COM [18.104.22.168])
by thalia.fm.intel.com (8.8.6/8.8.5) with SMTP id NAA04496
for <Arpad_Muranyi@ccm.fm.intel.com>; Mon, 23 Feb 1998 13:59:33 -0800 (PST)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [22.214.171.124]) by fmm
ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id NAA24116 for <Arpad_Muranyi@ccm.fm.
intel.com>; Mon, 23 Feb 1998 13:56:01 -0800 (PST)