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

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" <bob_ross@mentorg.com>
To: <ibis@eda.org>
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:
>
>
>
******************************************************************************
>

 
Received on Fri Nov 3 13:14:01 2000