Chris and IBISians;
Here are a few comments on EGG10.
(1) Could you expand on what additional testing is needed? The Version 2.1
Specification already gives WARNING messages for non-monotonic data in
tables, and already gives and ERROR message for wrong polarity data based
on the starting and final point values. So I think your first test is already
covered. It works correctly for ECL devices as well. If the [IBIS Ver] of
a Version 1.1 file is changed to 2.1, then Version 1.1 files will also
go through these tests.
(2) I think testing Waveform End-points against V/I data is a good idea.
The test will also reveal problems such as providing a min V/T table, but
having only NA data for the corresponding V/I table. I would expand on
the comment to have Both the [Power Clamp] and [Gnd Clamp] tables added
for all tests. If these clamps do not have data in the regions of
interest, then linear extrapolation of the data needs to be done.
(3) The extreme current test to provide a warning looks useful. There
might be more discussion about the delta V and what max I to use. If
the values are too low, then two many incorrect WARNINGS may be produced,
and a real problem still may be discovered.
(4) This also looks like a useful test. It would also detect incorrect
discontinuities in data that may have gone unnoticied. However, I am not
sure what defines an abrupt slope change in V/I data. In some simulations,
this may not be critical.
Anyway, you have provided some very good ideas for a parser enhansement project.
The main issues relate to what values to use.
Bob Ross
Interconnectix, Inc.
> Date: Wed, 21 Feb 96 11:57:34 PST
> From: crokusek@qdt.com (Chris Rokusek)
> To: ibis@vhdl.org
> Cc: crokusek@qdt.com
> Subject: EGG10 - Proposed Automatic Validation Checks
> Status: RO
> Fellow IBISians,
> Here is EGG10 proposing 4 "automatic" checks that could be built into
> the ibis checker to prevent some common model building pitfalls at
> build time rather than at simulation time after the model has been
> distributed.
> Any feedback is greatly appreciated!
> -Chris Rokusek
> Quad Design
> -------------------------------------------------------------------
> EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK.
> -------------------------------------------------------------------
> Items #1 and #2 are aimed toward checking that an IBIS file was built
> correctly and prevent common mistakes like getting spice output files
> overwritten, names mangled, and current/voltage polarity reversed.
> Items #3 and #4 attempt to verify that the data contained within the
> IBIS file is generally useful for SI simulation.
> 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE.
> REASON:
> -------
> Simple protection against wrong current polarity.
> RULE:
> -----
> (increase = more positive or less negative):
> For [Pulldown] and [GND Clamp] tables:
> As Voltage increases, Current should increase.
> For [Pullup] and [POWER Clamp] tables:
> As Voltage increases, Current should decrease.
> 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD.
> REASON:
> -------
> To insure that the Voltage/Time waveforms match the specified test
> load.
> To insure that the min/typ/max VT table corresponds to the
> min/typ/max VI table
> RULE:
> -----
> This check would look at the beginning and ending voltages of a VT
> Waveform which indicate DC settling points and compare each of these
> voltages to the given DC VI curves using the load specified for the
> waveform data.
> For example, given...
> [Rising Waveform]
> R_fixture = 50
> V_fixture = 2.5
> C_fixture = 50.0pF /* not important for this test */
> ...and a waveform like...
> +V
> |
> |
> |
> 4.2V | ********
> | **** |
> | * |
> | first point * |
> | | * |
> 2.5V | | * |
> | | * last point
> | V *
> | *
> 0.5V | **********
> |
> |
> ------------------------------------- +Time
> Can use the first point (see above) at 0.5V to check against the
> low VI curve (see below)...
> +I
> | Low State VI Curve
> | |
> | V
> | x LLLLLLLLLLLLLLLLLLLL
> | x LLLLLLL
> | x LLL
> | xLL
> | LLvx
> | L v x
> | L v x
> | L v x
> | L v x
> |L v x <--- slope = -50.0 = R_fixture
> |L v x
> L v x _------ Voltage = V_fixture
> L v x /
> ----L-------v---------x---------------------- +V
> L| | | |
> L
> 0.0V ?=? 2.5V 5.0V
> 0.5V?
> The load line "xxxx" should intersect the low state VI curve "LLLL"
> at ~= 0.5V indicated by the first point of the [Rising Waveform].
> Similarly, the High VI curve can be correlated to the last point
> of the Rising Waveform. This should be repeated for all waveforms.
> ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp].
> 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves)
> REASON:
> -------
> Many SPICE models are tested against data-book performance parameters
> designed to be used within the normal operating range of the device
> and are and not meant for simulation outside of that operating range
> into the protection range. However, for accurate SI simulation, it
> becomes important to have a well-defined protection range.
> Even if a model would fail this test, it still may be usable for SI
> simulation implying that failing this test should flag a WARNING
> but not an ERROR. The model developer will become aware that the
> SPICE model could be improved.
> RULE:
> -----
> Any VI point current should not exceed XX.X Amps when the voltage
> is within +-2.5V of operating range.
> 4) VERY FEW TRANSITION POINTS IN VI CURVE...
> REASON:
> -------
>
> Perhaps a more important check (then #3) would test for a
> significant number of transition points at the elbow of a shunt
> curve or bend(s) within VI curves.
> This test could be applied to all VI curves (not just shunt)
> as a test to determine if the voltage step was small enough.
> RULE:
> -----
> I believe this can be implemented as a comparison of some absolute
> maximum "delta ohms" to the second derivative at each point of
> each VI curve.
> Example Shunt Curve that FAILS test #4...
> +I
> |
> ----------*---*---*--*---*---*-- +V
> |
> |
> |
> * |
> |
> |
> * |
> |
> |
> Example Shunt Curve that PASSES test #4...
> +I
> |
> ----------********************* +V
> **** |
> ** |
> * |
> ** |
> * |
> ** |
> * |
> ** |
> * |
> ---------------------------------------------------------------------------
Received on Wed Feb 21 19:18:19 1996
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT