From: Vinu Arumugham ([email protected])
Date: Thu May 10 2001 - 13:11:28 PDT
Terminating both ends of the T-line is good but not always necessary.
The "ideal current source", I think only describes part of the driver.
Most drivers either have built in 50 ohm pull-up (or pulldown) resistors
or require such external resistors at the driver end, especially when
they are AC coupled to the receiver.
Thanks,
Vinu
"Muranyi, Arpad" wrote:
> An ideal current source has an IV curve which is a horizontal lineon
> a current vs. voltage plot. In my experiments I proved it tomyself
> that the end of a transmission line sees the slope (derivative)of the
> IV curve as the termination impedance. The impedance ofan ideal
> current source is infinite, in other words it lookslike an open to the
> transmission line.My question is, what makes some people feel that it
> is a good thingto have current source like drivers for high speed
> signaling?Wouldn't it be better to have matched impedance terminations
> at***both*** ends of the T-line which implies linear IV curvessuch as
> a resistor's IV curve? Am I missing something?Remember, the driver is
> also a terminator on the T-line whileit is driving...Arpad
> MuranyiIntel
> Corporation=====================================================================
> -----Original Message-----
> From: C. Kumar [mailto:[email protected]]
> Sent: Friday, May 04, 2001 6:12 AM
> To: Willis, Ken; 'Mark Alexander'
> Cc: [email protected]
> Subject: RE: [SI-LIST] : IBIS or SPICE examples
>
> I agree with Ken's excellent response. In fact most high speed drivers
> should behave close to ideal current sources. Otherwise the device
> will be in deep trouble.
>
> However advanced modeling will require "structural" circuits.
> Specctraquest has this ability with a comprehesive suite of controlled
> sources which we use extensively.
>
> "Willis, Ken" <[email protected]> wrote:
>
> Hi Mark,
>
> I have run into a couple of chip suppliers that indicate
> things the
> other way around, which I found interesting. In this
> particular
> case, I had put in a request for a model, and eventually got
> to
> the model developer. His opinion was that for the high speed
>
> (2.5 GHz) data rates we were talking about, the driver HAD
> to be very
> linear and symmetric by definition. His take on it was that
> when
> looking at these kinds of speeds, the driver model actually
> became
> simpler and the interconnect model becomes much more
> detailed and complex.
> He felt the result would be "interconnect-dominant" rather
> than
> "device-dominant". He gave me the IBIS data I asked for and
> some
> details on the package. I was able to model all this up, run
> a quick
> pseudo-random data pattern down there, and get some eye
> patterns that
> were very close to what we had in the lab. We wer! ! ! ! e
> able to track down
> some stubbing problems inside the receiving package that
> were closing
> the eyes down a bit as well. So it seems in certain
> applications you may
> be OK using IBIS style models for some pretty high speed
> applications.
>
> A couple of important caveats (of course). Power and ground
> problems did
> not seem to be an issue in this application. And the loss
> tangent values
> are very important to get proper results. Also it is
> critical to model
> vias in detail, including the stubbing that has been
> discussed at length
> here. I used the spice subcircuit capability of
> SPECCTRAQuest
> quite a bit for modeling complex passive stuff like
> packages, vias, etc.
> Your results will be very dependent on how well you can
> model these things.
> So it wasn't push button "out-of-the-box" tool usage, there
> was some
> stuff to do under the hood, but it worked pretty well. At
> any rate, there
> is another data point for you on behavioral vs. structural
> device mod! ! ! ! eling.
> I'm sure there are cases in which structural modeling is
> mandatory, but this
> didn't seem to be one of them. As always it will be
> dependent on your
> specific
> application, and your mileage will vary.
>
> Ken
>
>
> -----Original Message-----
> From: Mark Alexander [mailto:[email protected]]
> Sent: Thursday, May 03, 2001 11:48 AM
> To: Todd Westerhoff
> Cc: [email protected]
> Subject: [SI-LIST] : IBIS or SPICE examples
>
>
> Todd et al,
>
> Many of us are familiar with the fundamental differences
> between SPICE and
> IBIS
> -- one is difficult and highly accurate, the other is simple
> and moderately
> accurate. What might be more useful in this discussion is
> information from
> personal design experience about when you would use one
> versus the other.
>
> For example, up until recently my department used IBIS
> exclusively for our
> board
> design and simulation. These boards involved single-ended
> signals running
> from0 to 200 Mhz and differential signals up to 840 Mhz.
> However as we move
> into
> the world of high-speed serial channels at 3, 5 and 10 Ghz,
> the ice on the
> IBIS
> pond gets a bit thin.
>
> Right now we're running both SPICE and IBIS simulations of
> our systems in
> order
> to make sure we're seeing everything we need to. Our
> concerns stem both
> from
> the general aspect of IBIS's approximate nature, as well as
> the specific
> aspect
> of package modeling. Detailed package modeling within the
> confines of the
> IBIS
> spec is difficult. We see differences in our simulation
> results (between
> SPICE
> and IBIS), though we're just beginning to draw conclusions
> as to what's
> causing
> them and how we can improve the IBIS model.
>
> Others have commented that in order to model systems with a
> non-ideal power
> plane, you have to use SPICE because no one yet makes an
> IBIS simulator that
> can
> handle non-ideal power planes. I'm not very deep in this
> realm! ! ! ! ... can
> anyone
> comment?
>
> -mark
>
>
>
> Todd Westerhoff wrote:
>
> > The answer to your question is: it depends.
> >
> > IBIS is actually a language for characterizing I/O
> behavior that has a
> > defined structure and syntax. That's the long way of
> saying it models a
> > defined subset of all possible I/O behavior. SPICE, on the
> other hand,
> can
> > model anything. Want to model viscous fluid flow through a
> pipe? Sure -
> > come up with the correct electrical equivalent model, and
> SPICE can handle
> > it for you.
> >
> > So, "it depends", means that you have to understand the
> interconnect and
> I/O
> > you want to analyze, and whether or not behavioral analog
> simulation will
> > model enough of the effects properly to give you a
> reasonable answer. If
> > IBIS provides an adequate answer, then by all means, use
> it. And, if IBIS
> > won't give you the detailed answer you want, you still may
> be better! ! ! ! off
> > running IBIS up-front to get you in the ballpark, before
> you run a SPICE
> > analysis. This is especially true if you're running
> pre-route analysis
> and
> > looking at a number of different scenarios. We regularly
> analyze hundreds
> > and thousands of "variations" at a time using IBIS models,
> receiving
> answers
> > within minutes. You can imagine what the turnaround time
> would be if we
> > were doing things differently.
> >
> > But for I/O structures that IBIS cannot address, SPICE may
> be your only
> > choice. And for critical applications, it's almost always
> worth the
> effort
> > to look at structures with both forms of simulation, to
> make sure the
> > answers correlate.
> >
> > I view simulators as tools. They help you get a job done,
> but you have to
> > understand what their limitations are, how to use them,
> and to which
> > problems they are best applied. Please don't expect a
> simulator or SI
> too! ! ! ! l
> > to give you an answer - because it won't. Its purpose is
> to give you data
> -
> > on which you can base design decisions.
> >
> > Todd.
>
>
> **** To unsubscribe from si-list or si-list-digest: send
> e-mail to
> [email protected]. In the BODY of message put:
> UNSUBSCRIBE
> si-list or UNSUBSCRIBE si-list-digest, for more help, put
> HELP.
> si-list archives are accessible at http://www.qsl.net/wb6tpu
>
> ****
>
> **** To unsubscribe from si-list or si-list-digest: send
> e-mail to
> [email protected]. In the BODY of message put:
> UNSUBSCRIBE
> si-list or UNSUBSCRIBE si-list-digest, for more help, put
> HELP.
> si-list archives are accessible at http://www.qsl.net/wb6tpu
>
> ****
>
>
> -----------------------------------------------------------------------
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:54 PDT