[SI-LIST] Re: SA12E Vil and Vih

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Tue, 08 Jan 2002 17:33:13 -0500

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.

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.

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.

Mike LaBonte

"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
  

Other related posts: