[SI-LIST] Re: SA12E Vil and Vih
- From: "D. C. Sessions" <si-list@xxxxxxxxxxxxxxxx>
- To: "'SI-LIST'" <si-list@xxxxxxxxxxxxx>
- Date: Sat, 19 Jan 2002 18:04:27 -0700
On Tuesday 08 January 2002 15:33, you wrote:
# So shall we regard the 1v/ns number as a minimum slew rate? The spec
# says to test at that rate. But I don't think it describes the
# implications of having slower or faster slews on the PCB.
The only reason that the number is in the JEDEC spec is to prevent
manufacturers from playing games with it. Use the actual spec for
the parts you intend to use, or set a minimum for qualification. If
you can get away with 1 v/ns of course, you can set that as your
qual threshold. Pretty safe bet these days.
# It turns out I am working with identical strobe and data transmitters
# on a source synchronous bus. So the feedback I am hearing is that
# there should be no need to account for input switch time uncertainty
# by timing to Vil and Vih. The signals will be similar enough to
# warrant timing to Vref.
Exactly.
# The HSTL spec also requires no more than 2% AC noise on Vref. This
# equates to 18mV for Vref=0.9V, or 18pS of time shift at a 1V/ns slew
# rate. Does that eat into my timing margin, or is it already built
# into the specified setup and hold times? It is a small value, but
# I am curious if chip timing is developed with that error in mind.
I can't speak for other I/O designers, but I always characterize mine
across the full range of input conditions. The max/min timings
include stuff like common-mode range. In your case, the noise
should be part of the rise/fall symmetry issue, which is either
accounted for as a sum or else you have the tools to solve it.
We don't always have full statistical process models in the first
releases of libraries, so accurate skew numbers may be fuzzy
until the process models mature.
# "D. C. Sessions" wrote:
# >
# > On Monday 07 January 2002 08:13, Mike LaBonte wrote:
# > # Yes, the JEDEC spec says to measure timing at Vref, with no more than
# > # a certain amount of noise on Vref and a certain input slew rate. But:
# > #
# > # a) How much can my input signal deviate from the 1V/ns test signal
# > # slew rate and still get correct timing? Can it be slower? Faster?
# >
# > The 1v/ns number is there to prevent manufacturers from making their
# > devices look better than they are by using 30 ps edges on the inputs
# > during characterization.
# >
# > # b) What procedures do chip manufacturers follow to insure that timing
# > # specs account for the range of input conditions? Do ASIC designers
# > # follow the same or similar procedures?
# >
# > As a rule, if your edges aren't egregiously slow they won't affect delay.
# > If they *are* egregiously slow, the impact on delay is not easily specified.
# >
# > # Point (b) stems from the fact that the HSTL buffer specification has an
# > # impact on how chip timing is specified. Do the chip timing tools actually
# > # consider worst case input conditions? Tools like Einstimer have provisions
# > # for input slew rate checking, but I am not convinced that it is used
# > # effectively.
# >
# > At present, if you have a source-synchronous system and reasonable
# > receivers, the delay mismatch between paths is minimal as long as the
# > edge rates (etc.) are similar between lanes. If you're depending on some
# > value of matching between dissimilar lanes, you'd best have sharp
# > edges, which will reduce the impact of edge rates.
# >
# > If you can't guarantee either of these conditions, you're going to have to
# > SPICE the whole stinking mess, because at present there isn't any other
# > viable way to characterize the impact on input timing of nonideal waveforms.
# > (Which, as anyone in either JEDEC or IBIS can tell you, has been one of
# > my pet peeves for at least the last four years.)
# >
# > --
# > | I'm old enough that I don't have to pretend to be grown up.|
# > +----------- D. C. Sessions <dcs@xxxxxxxxxxxxxxxx> ----------+
# ------------------------------------------------------------------
# To unsubscribe from si-list:
# si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
#
# or to administer your membership from a web page, go to:
# //www.freelists.org/webpage/si-list
#
# For help:
# si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
#
# List archives are viewable at:
# //www.freelists.org/archives/si-list
# or at our remote archives:
# http://groups.yahoo.com/group/si-list/messages
# Old (prior to June 6, 2001) list archives are viewable at:
# http://www.qsl.net/wb6tpu
#
#
#
--
| The race is not always to the swift, nor the battle to the strong. |
| Because the slow, feeble old codgers like me cheat. |
+--------------- D. C. Sessions <dcs@xxxxxxxxxxxxxxxx> --------------+
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
