Even though I agree with most of what you are writing (below), the point in the
previous discussion on using S-parameters was whether they can be applied to
digital switching transistors (logic I/O buffers, Q-switches, etc.) and not
It is true that S-parameters can be derived for multiple operating points for a
nonlinear device, as Brian C. Wadell pointed out. However, I don't know of any
simulator which makes use of these in analog simulations of digital signals.
(SI gurus, correct me if I am not aware of something).
The problem is that if I used a SPICE-like simulator and used a set of
S-parameters to model a 74F245 buffer, the simulator would have to go from one
S-parameter to the next, and next, etc. in the series S-parameters while the
buffer is transitioning high to low. Even though this might not be totally
impossible, I am not aware of a tool that does it. The whole point of the
S-parameters is to be in the frequency domain (amplitude or voltage vs.
frequency) and not in the time domain (voltage vs. time).
The other question I would raise is: For a digital device, what would
constitute the input and output for the S-parameters? Does it make sense to
describe the relationship between the NODES called INPUT and OUTPUT, or would it
make more sense to describe the relationship between GND pin and the output pin
for a pull-down structure part of a digital buffer, for example?
As I said, I might not be aware of tools out there which do these things, so I
would like to hear the opinion of people who know better than myself.
I disagree with Ed that one rarely knows what bandwidth to consider the S
parameters over for package interconnect modeling. If that was the case, we
would not know when to switch from a single lump model to a more elaborate one.
We certainly can measure or
model to determine the output waveform of the driver. We can then compute the
frequency spectrum of the signal. One can then define the required bandwidth
for the model. Of course, it does not have to be a 3dB bandwidth, it can be
anything with which one feels comfortable. Granted the drivers and receivers
are nonlinear. But that does not come into the picture in package interconnect
modeling. The package itself is a linear structure.
Linear system analysis would not yield the correct frequency spectrum of the
driver output when the loading conditions change. But under no load condition,
the driver output should be the fastest and thus with the highest bandwidth.
This can thus be used to establish an upper bound on the bandwidth
of the driver
output under all loading conditions.
By the way, I think I speak for all to suggest subscribers to this list to
update the administrator of any address change ASAP. Otherwise, the amount of
undeliverable, returned messages to sender would eventually discourage people
from posting to the list.
> From email@example.com Thu Sep 5 15:06:23 1996
> Date: Thu, 5 Sep 1996 15:58:21 -0400
> X-Sender: firstname.lastname@example.org
> X-Mailer: Windows Eudora Light Version 1.5.2
> To: email@example.com (Wai Yeung Yip), si-list@silab.Eng.Sun.COM
> From: "Dr. Edward P. Sayre" <firstname.lastname@example.org>
> Subject: Re: Modeling - Fast Tr
> Content-Length: 1952
> I do not agree that s-parameter is the best approach since you rarely know
> what bandwidth to consider the s-parameters over. The microwave idea of a 3
> dB bandwidth has little or no meaning when one is considering the non-linear
> nature and threshold of digital drivers and receivers. Based on many years
> of high performance interconnect design for digital systems, I agree with
> Fabrizio Zanella's approach. It is accurate, and if properly done, does not
> ignore coupling or any other crosstalk effects and is suitable for use in
> either IBIS or SPICE simulations.
> The choice of how big to make the subsections is entirely dependent on the
> "electrical size" of the interconnect and can be directly related to the
> risetime of the signals. The rule of thumb of 10 time samples per risetime
> translates into something like a small fraction of a wavelength of a fifth
> harmonic of the fundamental. Those of us with a background in fields know
> this corresponds to a "electrically small" object in the frequency domain.
> Measurements directly compared to theory shows this to be an excellent
> approach. On the cautionary side, one does not want to over sample the
> connector. More is not always better since the Green's functions describing
> the connector may not converge well of the subsection length is too short.
> The rule of thumb stated above works for most field simulators and has the
> theoretical basis for being correct.
> ed sayre
> | NORTH EAST SYSTEMS ASSOCIATES, INC. |
> | ------------------------------------- |
> | "High Performance Engineering & Design" |
> | Dr. Ed Sayre e-mail: email@example.com |
> | NESA, Inc. http://www.nesa.com/ |
> | 636 Great Road Tel +1.508.897-8787 |
> | Stow, MA 01775 USA Fax +1.508.897-5359 |
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***.
Subject: Re: Modeling - Fast Tr
From: firstname.lastname@example.org (Wai Yeung Yip)
Date: Fri, 6 Sep 96 13:36:05 PDT
Received: from pd35.pkgdoc by pdms (4.1/SMI-4.1)
id AA14533; Fri, 6 Sep 96 13:36:05 PDT
Received: from pdms by mhost.lsil.com id AA26708
(4.1/SMI-4.1 for si-list@silab.Eng.Sun.COM); Fri, 6 Sep 96 13:36:11 PDT
Received: from mhost.lsil.com (mhost.lsil.com [126.96.36.199]) by lsi.lsil.com w
ith SMTP id NAA26869
(8.6.12/IDA-1.6 for <si-list@silab.Eng.Sun.COM>); Fri, 6 Sep 1996 13:36:31 -07
Received: from lsi.lsil.com by venus.Sun.COM (Sun.COM)
id NAA29384; Fri, 6 Sep 1996 13:41:40 -0700
Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
id NAA00945; Fri, 6 Sep 1996 13:41:40 -0700
Received: from Eng.Sun.COM by silab-188.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id NAA07162; Fri, 6 Sep 1996 13:41:39 -0700
Received: from silab-188.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
id SAA27757; Fri, 6 Sep 1996 18:00:23 -0700
Received: by mercury.Sun.COM (Sun.COM)
id SAA22770; Fri, 6 Sep 1996 18:00:58 -0700
Received: from mercury.Sun.COM by calliope.fm.intel.com (8.7.4/10.0i); Sat, 7 Se
p 1996 01:16:59 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [188.8.131.52]) by
fmmail.fm.intel.com (8.7.4/8.7.3) with ESMTP id SAA24853 for <Arpad_Muranyi@ccm.
fm.intel.com>; Fri, 6 Sep 1996 18:15:55 -0700 (PDT)