Subject: Re: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit

From: "Matthew Flora" <[email-masked]>
Date: Fri, 3 Nov 2000 13:11:02 -0800

Bob,

Will this increase to the data point quantity limit be retroactive to IBIS
3.0, 3.1, 3.2, or does it only apply to 3.3 and later?  I ask because I want
to make sure that IBISCHK will make the distinction.

Thanks,
Matthew Flora
Innoveda

----- Original Message -----
From: "Bob Ross" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 27, 2000 4:26 PM
Subject: IBIS BIRD67.1 - Increase V-T Table 100 Point Limit

> To All:
>
> BIRD67.1 is the same as BIRD67, except the 1000 point limit is clarified
> as 1000 rows.  This deals with the issue brought up at the October 27, 2000
> meeting regarding whether NA's are counted as points.
>
> Bob Ross
> Mentor Graphics
>
>
******************************************************************************
******************************************************************************
>
> BIRD ID#:       67.1
> ISSUE TITLE:    Increase V-T Table 100 Point Limit
> REQUESTER:      Bob Ross, Mentor Graphics, Ian Dodd, Cadence
> DATE SUBMITTED: October 24, 2000, October 27, 2000
> DATE ACCEPTED BY IBIS OPEN FORUM: Pending
>
>
******************************************************************************
******************************************************************************
>
> STATEMENT OF THE ISSUE:
>
> The 100 point limitation on V-T tables is too limiting because of increased
> accuracy needs and the fact that the available point may have to be
> distributed among the typ, min, and max columns.  A 1000 point limit is
> proposed.
>
>
******************************************************************************
>
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
>
> In the following keyword, the value 100 is replaced by 1000, and points is
> replace by rows on the lines designated by |*
>
>
>
|=============================================================================
> |    Keywords:  [Rising Waveform], [Falling Waveform]
> |    Required:  No
> | Description:  Describes the shape of the rising and falling edge waveforms
> |               of a driver.
> |  Sub-Params:  R_fixture, V_fixture, V_fixture_min, V_fixture_max,
C_fixture,
> |               L_fixture, R_dut, L_dut, C_dut
> | Usage Rules:  Each [Rising Waveform] and [Falling Waveform] keyword
> |               introduces a table of time vs. voltage points that describe
> |               the shape of an output waveform.  These time/voltage points
> |               are taken under the conditions specified in the
> |               R/L/C/V_fixture and R/L/C_dut subparameters.  The table
itself
> |               consists of one column of time points, then three columns of
> |               voltage points in the standard typ, min, and max format.
The
> |               four entries must be placed on a single line and must be
> |               separated by at least one white space.  All four columns are
> |               required.  However, data is only required in the typical
> |               column.  If minimum or maximum data is not available, use
the
> |               reserved word "NA".  The first value in the time column need
> |               not be '0'.  Time values must increase as one parses down
the
> |*               table.  The waveform table can contain a maximum of 1000
data
> |*               rows.  A maximum of 100 waveform tables are allowed per
> |               model.  Note that for backward compatibility, the existing
> |               [Ramp] keyword is still required.  The data in the waveform
> |               table is taken with the effects of the C_comp parameter
> |               included.
> |
> |               A waveform table must include the entire waveform; i.e., the
> |               first entry (or entries) in a voltage column must be the DC
> |               voltage of the output before switching and the last entry
(or
> |               entries) of the column must be the final DC value of the
> |               output after switching.  Each table must contain at least
two
> |               entries.  Thus, numerical values are required for the first
> |               and last entries of any column containing numerical data.
> |
> |               A [Model] specification can contain more than one rising
edge
> |               or falling edge waveform table.  However, each new table
must
> |               begin with the appropriate keyword and subparameter list as
> |               shown below.  If more than one rising or falling edge
waveform
> |               table is present, then the data in each of the respective
> |               tables must be time correlated.  In other words, the rising
> |               (falling) edge data in each of the rising (falling) edge
> |               waveform tables must be entered with respect to a common
> |               reference point on the input stimulus waveform.
> |
> |               The 'fixture' subparameters specify the loading conditions
> |               under which the waveform is taken.  The R_dut, C_dut, and
> |               L_dut subparameters are analogous to the package parameters
> |               R_pkg, C_pkg, and L_pkg and are used if the waveform
includes
> |               the effects of pin inductance/capacitance.  The diagram
below
> |               shows the interconnection of these elements.
> |
> |                      PACKAGE            |   TEST FIXTURE
> |       _________                         |
> |      |  DUT    |   L_dut   R_dut        | L_fixture  R_fixture
> |      |  die    |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\-----
V_fixture
> |      |_________|                  |     |         |
> |                                   |     |         |
> |                                   |     |         |
> |                            C_dut ===    |        === C_fixture
> |                                   |     |         |
> |                                   |     |         |
> |                                  GND    |        GND
> |
> |               NOTE:  The use of L_dut, R_dut, and C_dut is strongly
> |               discouraged in developing Waveform data from simulation
> |               models.  Some simulators may ignore these parameters because
> |               they may introduce numerical time constant artifacts.
> |
> |               Only the R_fixture and V_fixture subparameters are required,
> |               the rest of the subparameters are optional.  If a
subparameter
> |               is not used, its value defaults to zero.  The subparameters
> |               must appear in the text after the keyword and before the
first
> |               row of the waveform table.
> |
> |               V_fixture defines the voltage for typ, min, and max supply
> |               conditions.  However, when the fixture voltage is related to
> |               the power supply voltages, then the subparameters
> |               V_fixture_min and V_fixture_max can be used to further
specify
> |               the fixture voltage for min and max supply voltages.
> |
> |               NOTE:  Test fixtures with R_fixture and V_fixture,
> |               V_fixture_min, and V_fixture_max only are strongly
encouraged
> |               because they provide the BEST set of data needed to produce
> |               the best model for simulation.  C_fixture and L_fixture can
be
> |               used to produce waveforms which describe the typical test
case
> |               setups for reference.
> |
> |               NOTE:  In most cases two [Rising Waveform] tables and two
> |               [Falling Waveform] tables will be necessary for accurate
> |               modeling.
> |
> |               All tables assume that the die capacitance is included.
> |               Potential numerical problems associated with processing the
> |               data using the effective C_comp for effective die
capacitance
> |               may be handled differently among simulators.
>
|-----------------------------------------------------------------------------
> [Rising Waveform]
> R_fixture = 50
> V_fixture = 0.0
> | C_fixture = 50p        | These are shown, but are generally not
recommended
> | L_fixture = 2n
> | C_dut = 7p
> | R_dut = 1m
> | L_dut = 1n
> | Time            V(typ)              V(min)              V(max)
>    0.0000s       25.2100mV           15.2200mV           43.5700mV
>    0.2000ns       2.3325mV           -8.5090mV           23.4150mV
>    0.4000ns       0.1484V            15.9375mV            0.3944V
>    0.6000ns       0.7799V             0.2673V             1.3400V
>    0.8000ns       1.2960V             0.6042V             1.9490V
>    1.0000ns       1.6603V             0.9256V             2.4233V
>    1.2000ns       1.9460V             1.2050V             2.8130V
>    1.4000ns       2.1285V             1.3725V             3.0095V
>    1.6000ns       2.3415V             1.5560V             3.1265V
>    1.8000ns       2.5135V             1.7015V             3.1600V
>    2.0000ns       2.6460V             1.8085V             3.1695V
> | ...
>   10.0000ns       2.7780V             2.3600V             3.1670V
> |
> [Falling Waveform]
> R_fixture = 50
> V_fixture = 5.5
> V_fixture_min = 4.5
> V_fixture_max = 5.5
> | Time            V(typ)              V(min)              V(max)
>    0.0000s        5.0000V             4.5000V             5.5000V
>    0.2000ns       4.7470V             4.4695V             4.8815V
>    0.4000ns       3.9030V             4.0955V             3.5355V
>    0.6000ns       2.7313V             3.4533V             1.7770V
>    0.8000ns       1.8150V             2.8570V             0.8629V
>    1.0000ns       1.1697V             2.3270V             0.5364V
>    1.2000ns       0.7539V             1.8470V             0.4524V
>    1.4000ns       0.5905V             1.5430V             0.4368V
>    1.6000ns       0.4923V             1.2290V             0.4266V
>    1.8000ns       0.4639V             0.9906V             0.4207V
>    2.0000ns       0.4489V             0.8349V             0.4169V
> | ...
>   10.0000ns       0.3950V             0.4935V             0.3841V
> |
>
>
>
******************************************************************************
>
> ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
>
> This topic has been discussed at several IBIS Meeting and on e-mail.  BIRD67
> complies with the action item to propose a correction to the 100 point
> limit problem on V-T tables.
>
> There now exists both the requirement that V-T tables have high resolution
> for accuracy and also extend to a time where the DC value reaches the
correct
> DC final value.
>
> A further requirement is that the high resolution exists on all columns -
typ,
> min, and max.  However, often the waveforms for min and max columns are both
> delayed differently and have their sharpest transition points distributed
> at different time values from each other and from the typ column points.
> Since the time points are all referenced to the same time axis for all
> columns, the selection of actual time values for best accuracy might be
> different for each column.  A worst case scenerio would have approximately
> 33 selected time points available for each column.  This provides too low
> of a resolution needed for some of the higher speed devices and for some
> corresponding accuracy requirements.
>
> This issue is further confused by whether NA entries in a particular column
> count as one of the maximum 100 entries in that column.  The worst case
> interpretation is that it does.  Also ibischk3 enforces this limitation
> regardless of contents of any column.
>
> Often tools used to generate V-T tables use constant time steps.  This
> often provides conflicting delta time requirements: small enough for the
> necessary resolution for the fastest responses, and large enough so that the
> final DC value is reached for the slowest response using 100 points or less.
> More complicated optimal distribution of points may be the only solution.
> With more allowable points even the simplier constant delta time tables can
> be provided.
>
> BIRD67 simply increases the maximum value allowed to 1000.  We still want to
> provide a limit to prevent vendors from providing unnecessarily large
amounts
> of V-T data.  At this time we feel that 1000 points is more than adequate.
>
> BIRD67 retains the 100 point limit for all other tables.  The 100 point
limit
> is still reasonable for these situations.  Having a common limit of 1000
> would also be attractive for consistency, but this would also encourage
> producing needlessly large files.
>
> An older BIRD17 had proposed raising the limit to 151 for greater resolution
> and to allow even distribution of some I-V data based on 5 V technology.
> BIRD17 was rejected.  One reason was that a common tool at that time had a
> limit of 100 points when processing table based VCCS and VCVS functions - a
> key element in processing IBIS models.  The need to be compatible with this
> tool still exists, but the need for greater resolution also exists.  The
> burden now shifts to the specific tool - either it must change its limits or
> else provide the filtering algorithm to do the best selection of data
points.
> Most other tools do not have such a 100 point restriction.
>
> BIRD67.1 changes points to rows to clarify that the limit is for time
> entries rather than number of actual data points in each column.  This is
> the most conservative interpretation.  The 1000 points is retained rather
> than increasing to 1001 to discourage people to automatically putting in
> the maximum allowable points when they are not needed.  The issue of
> increasing the 100 row limit for I-V tables would be addressed in another
> BIRD.
>
>
******************************************************************************
>
> ANY OTHER BACKGROUND INFORMATION:
>
>
>
******************************************************************************

---

From: Bob Ross <[email-masked]>
Date: Fri, 03 Nov 2000 13:50:06 -0800

Matthew:

BIRD67.1 would not apply to any existing release.  The Version number
would have to be increased to 3.3 or some other number for ibischk
to make the distinction.

Bob Ross
Mentor Graphics

---

From: Al Davis <[email-masked]>
Date: Fri, 3 Nov 2000 15:12:01 -0800

> to make sure that IBISCHK will make the distinction.

It seems to me that obviously it can only apply to future versions,
because we cannot change products that have already been shipped to
customers.

I do not oppose an increase in the table size to something
arbitrarily large, like 1000 points.  Most tools use dynamic
allocation anyway, and for those that don't it is usually just
changing the subscript on an array.  The only reason I see to not
make it completely unlimited is to not require a major rewrite for
simulators that use fixed allocation.  I agree with the increase,
because most is not all, and the standard should not arbitrarily
prohibit the few cases where the increase in points is truly needed.

However, in most cases the existing 100, or even 30, is plenty of
points.  Accuracy is limited elsewhere.  

Many models have only one waveform of each type, which is measured
with a particular load.  Even if the measurement is highly accurate
with that load, the waveform is only a guess with any other load.
Therefore, accuracy can be better by supplying additional waveforms
with diffrerent loads, or loads to different reference voltages. 
This is true in the extreme with differential drivers, where the only
correct load is the differential one, with the other end connected to
the other side's driver.

Another issue is proper choice of the time points.  Many have 100
points, but all of the action is in 3 points.  First, there are too
few points in the action region.  Second, and as important, data in
the nearly steady region is often contaminated by noise or limited by
numeric granularity.

Consider ......
0    0.22
1n  0.22
2n  0.22
3n  0.22
4n  0.23
5n  0.23
6n  0.23
7n  0.23
8n  0.24
9n  0.24

You might naively interpret this to mean the voltage is increasing
slowly.  What the data says is that it remains constant until 4ns,
then jumps , remaining constant again until 8ns, jumping again.  If
this is driving a capacitor, you get a current spike at 4ns and 8ns,
with no current elsewhere.

But, likely the intent is that the voltage is increasing slowly. 
Accuracy is actually improved by removing points, in this case giving
only 0, 4n, and 8n.