Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination
From: Peters, Stephen (stephen.peters@intel.com)
Date: Thu May 08 2003 - 15:54:37 PDT
Hi Todd, all:
I second Kims' comment: great exposition. I have just one comment - in the
"Notes on Data Derivation Method" section in the back of the IBIS spec (ver
3.2) there is a table that lists the expected voltage range for each curve.
Data for [GND Clamp] table is expected to cover the range GND - POWER to GND
+ POWER, while data for [POWER Clamp] table is expected to cover POWER to
POWER + POWER.
Not sure though if this makes a difference in the problem with s2ibis
extraction (only using the typical VDDQ) or the subsequent simulator
extrapolation of the data.
Regards,
Stephen Peters
Intel Corp.
-----Original Message-----
From: Kim Helliwell [mailto:kimgh@apple.com]
Sent: Thursday, May 08, 2003 1:48 PM
To: Todd Westerhoff
Cc: Ibis-Users (E-mail)
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination
Great exposition; I hadn't thought about that, but it's definitely an issue
that affects me.
Your solutions are, I think, aimed at how to make better models.
I'd be more interested in at least 2 other angles:
1. How to massage models already supplied to me, when I
don't have access to the HSPICE models.
2. How to get simulator makers to address this issue in the simulators
proper, assuming that models won't be "perfect".
On Wednesday, May 7, 2003, at 10:44 PM, Todd Westerhoff wrote:
> Hi all,
>
> This one has been bugging us for a while ... the discussions that took
> place
> last week gave us the opportunity to take another look at this problem
> and
> its different components. I have two solutions to propose, and would
> appreciate feedback from the group.
>
> I apologize in advance for a lengthy email. There's no other way I
> know to
> describe the different components of the problem and the way they
> interact.
>
> To start - the problem is accurately modeling the effect of on-die
> input
> termination, most typically pulling the signal to a value of VDDQ/2,
> which
> would be common for HSTL and SSTL signalling. The resistors in
> question (at
> least in our case) were not discrete components in the package - they
> were
> truly on-die. Hence, the resistance varied with process and was
> non-linear
> over the operating range. Thus, we needed a way to extract the actual
> input
> characteristics using the HSpice model and create the correct model in
> IBIS.
>
> Simple enough, we thought - then it got deep.
>
> To ended up breaking the problem down into three pieces -
>
> 1) The IBIS Specification
> 2) The process of creating models
> 3) How IBIS simulators use the data in the IBIS models
>
>
> 1) The IBIS Specification
> -------------------------
> Please correct me if I'm wrong here, but I believe the IBIS Spec
> doesn't
> list any "standard" for the voltage range over which the behavior of
> the
> [GND Clamp] and [POWER Clamp] should be specified. I took it as a
> given
> that [Pulldown] and [Pullup] curves would range from -VDDQ to 2*VDDQ,
> and,
> until last week, I would have expected to see the same range for the
> power
> and ground clamps. That turned out not to be the case.
>
> I also suspect that the IBIS spec has no comment on just how the
> simulator
> is supposed to combine the data in the two clamp curves, should the
> points
> overlap. That turned out to be a big sticking point.
>
>
> 2) The process of creating models
> ---------------------------------
> There are two classes of people who create IBIS models from HSpice
> simulations:
>
> a) The gurus, who understand IBIS, HSpice and software well enough to
> develop their own tools for extracting and compiling IBIS model data,
> and
>
> b) The rest of us, who use some version of s2ibis2. Usually, it's one
> we've
> compiled ourselves, with some collection of fixes implemented for
> problems
> we have found on our own. I'm going to aim my comments squarely at
> s2ibis2,
> with the assumption that's what most of the IBIS-modelmakers are basing
> their efforts on.
>
> When s2ibis2 was created, the developer noticed an interesting problem
> -
> there is really no good way to separate the ground clamp curve from the
> power clamp curve. With the [Pullup] and [Pulldown] curves, you can
> isolate
> the behavior of transistor from the other by virtue of the output
> state.
> However, if you model the input buffer and sweep the voltage from
> -VDDQ to
> 2*VDDQ, there's really no good way to separate the one clamp curve
> from the
> other.
>
> (When I talk about voltage from this point on, I'm going to use ground
> as a
> reference, unless I specifically state that I'm using a power-based
> voltage
> reference "a la IBIS". I'm also going to assume the ground clamp is
> active
> between -VDDQ and 0V, the "operating region" for the device is between
> 0V
> and VDDQ, and the power clamp is active between VDDQ and 2*VDDQ).
>
> Of course, if you've got a normal input (without termination), the
> input
> current is zero (or essentially so) throughout the operating region, so
> there isn't really any problem. It doesn't much matter where the
> ground
> clamp curve leaves off and the power clamp curve kicks in, because the
> currents at those points are always zero.
>
> However, the presence of on-die termination to VDDQ/2 presents an
> interesting problem. The "zero current" point is somewhere in the
> middle of the operating region, and it's only a single point. The
> power and ground
> clamp curves, when added together, have to accurately represent the
> input's
> characteristic throughout the device's operating region (0 to VDDQ),
> if you
> want to input to behave properly.
>
> So now the question becomes - where does one curve leave off, and the
> other
> begin? Well, s2ibis2 simply implements the ground clamp curve from
> -VDDQ to
> VDDQ, and the power clamp curve from VDDQ to 2*VDDQ. In theory, you
> should
> be able to just attach the two curves together and get the right
> result - or
> at least, that's the assumption s2ibis2 seems to be operating on.
> Remember,
> because the power clamp curve in IBIS is rail-referenced, a sweep from
> VDDQ
> to 2*VDDQ shows up in the IBIS file as from 0 to -VDDQ.
>
> There are a couple of interesting caveats here. First, s2ibis2 ground
> clamp
> curves actually all end at the same point, which is the [typ] value of
> VDDQ.
> Let's assume that we have an HSTL 1.5 driver, whose power rail can
> vary by
> 10%. Thus, the [min] power rail is 1.35V, while the [max] power rail
> is
> 1.65V. In this case, the ground clamp data ends at 1.5V in all three
> cases.
>
> The power clamp curves have the same issue, but in reverse. They are
> supposed to sweep from VDDQ to 2*VDDQ. That's 0 to -VDDQ in IBIS
> terms (the curves really go from -VDDQ to 0 in the IBIS data, because
> voltages are supposed to increase). However, all three curves start
> at the same point,
> which is 2*VDDQ[typ] (-VDDQ[typ] in IBISese), and end at the same
> point,
> which is 0V.
>
> But - and this is a big one - because the power clamp curves are
> rail-referenced, 0V means different things in the different cases. It
> means 1.35V for [min], 1.5V for [typ] and 1.65V for [max]. So - if we
> adjust for
> the rail reference and talk about ground-referenced voltages, the
> voltage
> data points for the power clamp curves range from:
>
> [min] 1.35V to 2.85V
> [typ] 1.5V to 3.0V
> [max] 1.65V to 3.15V
>
> Let's set those side by side with the ground clamp curves and see what
> we
> get:
>
> Ground Clamp Power Clamp
> [min] -1.5V to 1.5V 1.35V to 2.85V
> [typ] -1.5V to 1.5V 1.5V to 3.0V
> [max] -1.5V to 1.5V 1.65V to 3.15V
>
> The [typ] curves complement each other just fine, but there is an
> overlap in
> the [min] data and a gap in the [max] data. We're primarily concerned
> about
> capturing the behavior of the input termination across the entire
> operating
> region here, so this looks like it might be a problem. Of course,
> that is
> determined by how the simulator handles the situation where the clamp
> V-I
> curves overlap or have a gap in them. We didn't expect what we found,
> however.
>
>
> 3) How IBIS simulators use the data in the IBIS models
> ------------------------------------------------------
> Different simulators may well do different things, and I'm not trying
> to say
> I've tested all of them. At least some of them, if not all of them,
> behave
> as I'm describing here.
>
> We suspected an IBIS simulator might "double count" the current in the
> overlap region in the [min]case (between 1.35V and 1.5V), thereby
> making the termination appear twice as strong as it really was (in
> that region).
> We
> didn't know what was going to happen in the [max] case, with a cap in
> the
> data between 1.5 and 1.65V. So - we read the models in and tested
> them.
>
> What we found, empirically, is that the simulator didn't add the
> curves together the way you might expect - taking the data from the
> ground clamp curve between -VDDQ and VDDQ, and the data from the power
> clamp curve between VDDQ and 2*VDDQ. Instead, the simulator *extended
> each curve by
> extrapolation* to cover the entire region from -VDDQ to 2*VDDQ, and
> *THEN*
> added the currents together. In other words, the power clamp curve
> (which,
> at the "IBIS 0V" point, corresponding to VDDQ, has a slope of roughly
> the
> termination value) got extended through the whole operating region
> with a
> slope roughly equal to the termination value. Now, when the simulator
> added
> the contributions of the power and ground clamps in the operating
> region, it
> came up with roughly twice the correct current, making the termination
> appear twice as strong as it really was. We started out thinking there
> might be a small problem in the gap/overlap regions of the [max/min]
> curves,
> and discovered instead that none of the simulation cases were working
> correctly, anywhere in the operating region.
>
> This is a classic case of compartmentalization and assumptions -
> between
> IBIS, s2ibis2 and the IBIS simulators. Bottom line, the basic
> assumption
> was that clamps don't kick in until you go beyond the rail, and the
> overall
> process falls apart in this case as a result.
>
>
> 4) What we can do about it
> --------------------------
> Again, I'm predicating this on the use of s2ibis2 to create IBIS
> models.
> The goal is simple: create an IBIS model that accurately reproduces the
> combined behavior of the clamps and input termination over the range
> from -VDDQ to 2*VDDQ.
>
> Both proposals both rely on the same basis: having s2ibis2 perform a
> single
> input V-I sweep, over the voltage range from -VDDQ to 2*VDDQ. That one
> simulation would capture all the behavior we're concerned about here.
> From
> there, it's just a matter of how you format the data.
>
> Proposal 1) Says that you put the whole kit & kaboodle into the [GND
> Clamp]
> curve and omit the [POWER Clamp] curve entirely. There's really only
> one
> composite input characteristic, anyway; separating it into two sets of
> clamp
> curves is artificial. Having two curves provides benefits in some
> cases,
> but it's hard to argue that those benefits apply here. This is the
> easiest
> solution to implement, and provides the composite curve in one place.
> The
> downside is that some users might object to having the power clamp data
> included in the [GND Clamp] curve, and that some simulation tools
> might also
> have a problem with this. A simulation tool that used a different
> technique
> for combining the curve data might very well have a problem with this
> approach.
>
> Proposal 2) ... which Arpad suggested, was to find the zero-current
> point in
> each of the min-typ-max cases, and assign all negative current to the
> ground
> clamp, and all positive current to the power clamp. You need to make
> sure
> that each clamp curve has two consecutive voltage data points with zero
> current at the correct end of the curve (so that all further points
> are zero
> current by extrapolation). You also need to do the proper voltage
> translations when assigning current to the power clamp curve. The
> advantage
> of this technique is that you end up with two sets of clamp curves as
> most
> people expect, and they add together correctly. This disadvantage is a
> slight increase in process complexity, and the fact that you probably
> won't
> be able to view the overall input behavior in one place.
> Interestingly, the
> IBIS-viewer/model-editor tools seem to allow you to view the combined
> V-I
> characteristics of the output buffers, but don't provide for viewing
> the
> combined characteristics of the power and ground clamp curves on an
> input.
>
> .... so there you have it - s2ibis2 and input termination modeling in
> IBIS,
> as I presently understand it. Corrections to my reasoning, comments
> and
> thoughts on the subject are both welcome and greatly appreciated.
>
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@cisco.com
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake? Life
> gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email majordomo@eda.org with
> |just the appropriate command message(s) in the body:
> |
> | help
> | subscribe ibis <optional e-mail address, if different>
> | subscribe ibis-users <optional e-mail address, if different>
> | unsubscribe ibis <optional e-mail address, if different>
> | unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to ibis-request@eda.org.
> |
> |IBIS reflector archives exist under:
> |
> | http://www.eda.org/pub/ibis/email_archive/ Recent
> | http://www.eda.org/pub/ibis/users_archive/ Recent
> | http://www.eda.org/pub/ibis/email/ E-mail since 1993
>
>
Kim Helliwell
Apple Computer
kimgh@apple.com
408 974 9936
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org with just
|the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Thu May 08 2003 - 17:32:01 PDT