Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination
From: Todd Westerhoff (twesterh@cisco.com)
Date: Fri May 09 2003 - 14:32:34 PDT
Thanks, John!
Can I therefore assume Hyperlynx treats the power clamp curve the way I
described - by extrapolating the endpoint/slope across the operating region?
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"
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Angulo, John
Sent: Friday, May 09, 2003 4:49 PM
To: 'Ibis-Users (E-mail)'
Subject: RE: [IBIS-Users] Modeling input receivers with on-die
termination
Kim, Todd et al.,
The predominant behavior you've found in simulators is based on the
following idea: the [Pullup], [Pulldown], [POWER Clamp] and [GND Clamp] I-V
tables provide characteristics for four independent elements, each connected
between the buffer die pad and a supply rail. Therefore, by KCL, the net
I-V characteristic must be a superposition of all four (of course, you only
worry about one of the [Pullup] and [Pulldown] curves at DC).
The IBIS parser follows this convention when it adds the I-V tables together
in search of I-V/V-T data inconsistencies.
Treating the I-V tables as parameterizations of independent elements with
definite power supply connections allows for ground bounce simulations.
s2ibis2, however, in dumping the DC sweep data from -VDDQ to VDDQ into the
[GND Clamp] and VDDQ to 2*VDDQ into the [POWER Clamp], is treating the clamp
tables as two halves of a single underlying element. This disagrees with
the IBIS parser and limits the potential for simulation of power effects.
So merging the clamp characteristics into one rather than adding them in
parallel would not only mean changing multiple simulators, but also changing
the IBIS parser and loosing some modeling capability. In an effort to avoid
leaving those on-die termination models which already follow the parser and
work with existing simulators high and dry, we might try to examine the
clamp curves and guess which convention they were meant to follow. But this
would probably be too much complexity. Herbert's method for pulling out the
pullup and pulldown resistors and placing them into the appropriate clamp
curves as independent elements is a good "band-aid". Fixing the spice2ibis
process would be the ultimate solution.
John Angulo
Hyperlynx Products
Mentor Graphics Corp.
john_angulo@mentor.com
425-869-2320
-----Original Message-----
From: Kim Helliwell [mailto:kimgh@apple.com]
Sent: Friday, May 09, 2003 11:15 AM
To: tom@teraspeed.com
Cc: 'Todd Westerhoff'; 'Ibis-Users (E-mail)'
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination
Tom:
I completely agree with making the models correct.
Todd was answering my earlier question of what to
do when a vendor supplied model is NOT correct.
For that case, a band aid is needed, particularly when
the vendor is recalcitrant about fixing the model...
On Friday, May 9, 2003, at 10:19 AM, Tom Dagostino wrote:
> This sounds like a band aid, not a solution. Let's make the models
> correct
> and not double count the currents.
>
> Tom Dagostino
> Teraspeed Consulting Group LLC Teraspeed Consulting Group LLC
> 2926 SE Yamhill St. Device Modeling Division
> Portland, OR 97214 13610 SW Harness Lane
> Beaverton, OR 97008
> http://www.teraspeed.com 503-430-1065
> tom@teraspeed.com
>
>
> -----Original Message-----
> From: owner-ibis-users@server.eda.org
> [mailto:owner-ibis-users@server.eda.org]On Behalf Of Todd Westerhoff
> Sent: Friday, May 09, 2003 8:06 AM
> To: Ibis-Users (E-mail)
> Subject: RE: [IBIS-Users] Modeling input receivers with on-die
> termination
>
>
> Kim, et al,
>
> I'm a little surprised that none of the tool vendors have checked in
> by this
> point. I've had users tell me what the different tools do, but no
> word from
> the tool-makers themselves.
>
> It seems to me the rub is that s2ibis2 assumes the clamp curves will be
> "added" one way (which is backed up, at least partially, by the IBIS
> spec,
> as noted by Stephen) - and the simulators do something else by
> extrapolating
> the power clamp curve. Simply put, s2ibis2 assumes that clamp current
> should be zero if voltage point is not specified in the particular
> clamp
> curve - the simulators do not.
>
> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
> Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
> corresponding entry for the current. Done. (this takes care out
> double-counting and the overlap case)
> 4. If the voltage point does not exist in the first curve, check the
> second.
> If the voltage point exists, take the corresponding current value.
> Done.
> 5. Only when the voltage point exists in neither curve (the gap case),
> extend
> each curve by extrapolation to find the current at the point in
> question.
> This will provide two (potentially slightly different) current
> values -
> use the average of the two.
>
> If the simulators worked this way, we wouldn't have to change s2ibis2
> at all
> (or, so it seems to me). The proposal 1 technique from my original
> mail
> would still work, but proposal 2 would need to be modified so that the
> individual curves ended once they hit the zero current point.
>
> 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
>
> |------------------------------------------------------------------
> |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
|------------------------------------------------------------------
|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 : Fri May 09 2003 - 14:43:11 PDT