From: S. Weir ([email protected])
Date: Thu May 10 2001 - 12:33:50 PDT
Arpad,
I believe that the motive behind current drivers is that the driver
tolerances don't burn us so badly as they potentially can with a voltage
mode driver. A voltage mode driver with a real internal impedance,
requires either a direct match to the trace or a matching series
resistor. Variations in the internal impedance directly affect the match,
and therefore reflections whether that comes from the driver, or the package.
A current mode driver is going to be completely dominated by the shunt
resistor. There is a bit of a devil in packaging that matching resistor,
and as I understand it, current mode drivers are power hungry.
Regards,
Steve.
At 11:50 AM 5/10/01 -0700, you wrote:
>An ideal current source has an IV curve which is a horizontal line
>on a current vs. voltage plot. In my experiments I proved it to
>myself that the end of a transmission line sees the slope (derivative)
>of the IV curve as the termination impedance. The impedance of
>an ideal current source is infinite, in other words it looks
>like an open to the transmission line.
>
>My question is, what makes some people feel that it is a good thing
>to 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 curves
>such as a resistor's IV curve? Am I missing something?
>Remember, the driver is also a terminator on the T-line while
>it is driving...
>
>Arpad Muranyi
>Intel 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!?
>><http://auctions.yahoo.com/>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