RE: [IBIS-Users] A question on how to handle NA in the min/max columns

From: Walter Katz <wkatz@sisoft.com>
Date: Mon Jul 14 2014 - 15:21:24 PDT
Arpad,

One "CAN" easily make the assumption. The question is: "MAY" one make the
assumption?, or more specifically can one get into deep trouble by making
any engineering decisions based on simulations of Min or Max corners when
all of the Min or Max data is not available.

Walter 


-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Muranyi, Arpad
Sent: Monday, July 14, 2014 6:09 PM
To: IBIS-users
Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max
columns

Walter,

I am questioning whether that assumption can be made.  Here is why:

For example, if the I-V keywords have a complete set of typ/min/max data,
and the waveform tables only have typical, and you assume that the missing
min/max columns in the waveform tables implies that the typical data
should be used for those corners, the different I-V tables will result in
an I-V/V-t mismatch condition.

For one, I wonder if the IBIS parser checks I-V/V-t mismatches in that way
(when certain columns are missing), second, the specification does not
state that in the absence of the min/max columns in these keywords implies
that the typical column should be used.  The spec does say this for some
keywords, but not all keywords.  So I wonder what the intent is in the
spec.  Should all missing corners imply that they are the same as typical,
or should this only apply to those keywords which are independent from
others (which seems to be the way they spec is written)?

Thanks,

Arpad
========================================================================

-----Original Message-----
From: Walter Katz [mailto:wkatz@sisoft.com]
Sent: Monday, July 14, 2014 2:43 PM
To: Muranyi, Arpad; IBIS-users
Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max
columns

Arpad,

What I meant to say is that if all data in an IV or VT Min or Max column
is NA, then assume that all of the data in that column is the same as the
Typ column. These models are effectively Typ only, so the EDA tool should
assume the Min or Max columns are Typ, but the User should know that this
model only has valid Typ data.

This does not necessarily mean that the Model is bad, although I am always
suspicious when I see models with NA in the Min and Max columns for IV or
VT data. For SerDes devices Min and Max has less (or different) importance
than in traditional models.

Walter

-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Muranyi, Arpad
Sent: Monday, July 14, 2014 3:30 PM
To: IBIS-users
Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max
columns

Walter,

Thanks for your reply, but I wasn't talking about rows...  I was talking
about the case when the entire column is NA for min/max.

Imagine a case when the I-V tables have all three corners filled, but the
waveform tables have only the typ column filled.  This is legal according
to the spec.  What is the EDA tool supposed to do?
We can synthesize the min/max waveform tables so that the end points are
calculated from the min/max I-V curve / load line intersection and then
scale the typical waveform according to those calculated end points.  This
would set the amplitude correctly for the synthesized waveform tables.
But what about the time scale?
If the [Ramp] has min/max data, we could look at the slope in the min/max
[Ramp] and scale the time axis of the synthesized waveform table according
to that.  Now we have a reasonable synthesized min/max waveform data.

But what if the [ISSO ***] or [Composite Current] tables are missing
min/max columns?  Such synthesis may be more and more difficult or
impossible, yet the specification allows any combination for missing or
existing min/max columns.

Shouldn't the spec spell out some rules on not allowing that to happen?

Thanks,

Arpad
======================================================================


-----Original Message-----
From: Walter Katz [mailto:wkatz@sisoft.com]
Sent: Monday, July 14, 2014 12:07 PM
To: Muranyi, Arpad; IBIS-users
Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max
columns

Arpad, Bob,

I have not followed the e-mail thread, but let me put my 2 cents in on how
we handle NA. With the exception of IV and VT table, and record that has
an NA in the Min or Max field takes on the value of the Typ field.

In the case of IV and VT tables there are two cases, one case is when all
the Min or Max data is NA, for all rows of an IV or VT table. In that
case, all value of the Min and Max columns take on the Typ value. In the
case where some rows have NA and some do not, then those rows with NA are
ignored for that column.

Do these rules make sense for all cases where there is an NA in a Min or
Max column?

Walter

-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Muranyi, Arpad
Sent: Monday, July 14, 2014 12:15 PM
To: 'IBIS-users'
Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max
columns

Bob,

Thanks for your response, but remember, I am asking this as an EDA vendor.
And a big aspect of my question is what the EDA tool is expected to do
with such models.  The spec is quite vague, and I think it should define a
few rules.  We can't just throw out all models and abort the simulation if
we find NA-s in the min/max corner in any of the keywords for which the
spec doesn't say to use the typ value when min/max is not available.

But this also applies to the model makers.  The spec should have a few
rules on what keyword combinations can have NA in the min/max columns.
The way the spec goes now, a lot of combinations are allowed which do not
make sense or can't be simulated.

Thanks,

Arpad
=================================================================

-----Original Message-----
From: Bob Ross [mailto:bob@teraspeed.com]
Sent: Friday, July 11, 2014 8:59 PM
To: Muranyi, Arpad; 'IBIS-users'
Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max
columns

Arpad:

You have provided a good analysis and scratched the surface of the
problem.

I do not think IBIS should make it illegal to have some, but not all
corner data missing (e.g. the min and max columns for some tables are NA).
There are pathological cases where such a models are still accurate and
useful.

E.g, ideal 50 ohm source resistors for the pullup and pulldown tables to
the defined pulldown and pullup reference voltages for all corners with
only the typ table is given and the min/max table corners have NA entries.
The intent might be to model a fixed 50 ohm impedance for all pullup and
pulldown table corners and vary the V-T data.)  Or just providing an ideal
50 ohm termination for all corners could be done with just the typical
data only, and that can be used with other models with all numerical
corner data given.

However, the user should be suspicious of and probably reject models for
real buffers with NAs in the corners because they are incomplete or
contain uncorrelated information that would make corner analysis
inaccurate.

Bob



-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Muranyi, Arpad
Sent: Friday, July 11, 2014 10:45 AM
To: IBIS-users
Subject: [IBIS-Users] A question on how to handle NA in the min/max
columns

Hello,

I would like to discuss the question of how to handle the situations when
min/max data is not available in certain IBIS keywords.  The IBIS
specification has several occurrences of the following statement (with
some variations here and there):


If minimum and/or maximum values are not available, the reserved word "NA"
must be used indicating the typical value by default.


(This one can be found on pg. 36 at the end of the 1st paragraph of the
Usage Rules on the top of the page).

The interesting thing is that this statement does not appear under every
single keyword, so my first question is whether this was intentional or
sloppiness.  For example, pg. 53 where the I-V tables are described, we
can read the following:


All four columns are required under these keywords. However, data is only
required in the typical column. If minimum and/or maximum current values
are not available, the reserved word "NA" must be used. "NA" can be used
for currents in the typical column, but numeric values MUST be specified
for the first and last voltage points on any I-V table. Each I-V table
must have at least 2, but not more than 100, rows.


This section does not state what the EDA tool should do when min/max data
is not available.  My guess is that the expectation was that the EDA tool
should use the typical data, but this is not stated.  The same observation
can also be made for the waveform tables on pg. 69, [Composite Current] on
pg. 71/72 and the [ISSO ***] keywords on pg. 56.

The story gets more interesting when we consider how the I-V tables and
the waveform voltages are related to each other by Ohm's law using the
R_fixture load resistor value.  One might argue that if the min/max data
is missing from the waveform tables, the typical waveform data might be
"adjusted" (scaled) relatively easily so that they would be in agreement
by Ohm's law.   One could even do the reverse when the min/max data is
available in the waveform tables but are missing in the I-V tables.  But
things will get more complicated or perhaps impossible with the [ISSO ***]
and/or [Composite Current] tables.  Imagine a certain waveform which
includes typ/min/max, but the [Composite Current] following it has only
typ data (or the other way around).

So the question I would like to clarify is whether the IBIS specification
should define what to do in these cases, or perhaps impose some
requirements on how the model maker should provide the data for these
various keywords (i.e. require all of them to have or not have min/max
data).

Note that not all keywords fall into this category.  For example, C_comp
and its variants are relatively independent from I-V and waveform related
keywords, so these would not have to be "matched" with having or not
having min/max data.

Questions, comments welcome...

Thanks,

Arpad
==========================================================================
==
==

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org 
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent 
| http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993



--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent
|  http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent
|  http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent
|  http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent
|  http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993
Received on Mon Jul 14 15:21:34 2014

This archive was generated by hypermail 2.1.8 : Mon Jul 14 2014 - 15:21:41 PDT