RE: [IBIS-Users] Re: IV curve sweep range

From: <Aubrey_Sparkman_at_.....>
Date: Sun Jul 17 2005 - 09:31:38 PDT
Andy,
Well said! 

Aubrey Sparkman 
Enterprise Engineering Signal Integrity Team
Dell, Inc. 
Aubrey_Sparkman@Dell.com 
(512) 723-3592

-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On
Behalf Of Andrew Ingraham
Sent: Sunday, July 17, 2005 10:53 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS-Users] Re: IV curve sweep range

I've spoken out about this before, and I still feel the same now.  Here
are my (STRONGLY RECOMMENDED) rule suggestions.

I think it's OK to restrict the required sweep range, but ONLY in the
case where the device (and all other drivers that are likely to be
connected to that net) are designed to be less than rail-to-rail.  Such
as GTL or ECL.

To make that happen, I think IBIS needs to define nominal I/O or Input
voltage parameters, which are not necessarily tied to the supply rails;
and these new parameters are to be used instead of Vcc in the -Vcc to
2*Vcc calculation.

I don't like restricting the sweep range just because the currents get
enormous.  So what if they get enormous.  They are enormous either
because they were derived from faulty SPICE models, or because the
device currents really are huge.  It's not the IBIS model that's broken.

Even though terminated transmission lines may never reach -Vcc or 2Vcc,
the simulator might try those points when the incident wave reaches the
end of the line and it doesn't yet know how much current goes into the
terminators or the clamps.  I don't expect the simulator to converge on
a solution near -Vcc or 2Vcc, but it might TRY values near there.  For
that reason, I think the IBIS data must require tables that go out that
far; or far enough to include the doubling at the end of the
transmission line for reduced voltage swing technologies.

Of course the data points don't need to be equally spaced.  I don't have
a problem with a table having 98 accurate data points that cover all
reasonable signal conditions, and two more on the ends, if the shape is
reasonably well behaved.  And I don't buy the argument that you have to
throw away two good data points to add the ones on the ends.

It may be that the endpoints aren't as accurate as the rest of the
tables, especially if the chip goes into meltdown or convergence
problems prevent getting real data there.  Maybe there should be a way
to indicate that certain datapoints are estimates and have reduced
accuracy compared to the rest of the table?

Regards,
Andy


|------------------------------------------------------------------
|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
Received on Sun Jul 17 09:31:42 2005

This archive was generated by hypermail 2.1.8 : Sun Jul 17 2005 - 09:31:55 PDT