EGG10 - Proposed Automatic Validation Checks

From: Stephen Peters <speters@ichips.intel.com>
Date: Thu Feb 22 1996 - 08:31:09 PST

Hello Chris, and Fellow IBISans:

     Reading Chris's EEG 10 got me thinking about another test
I would like to see added to this golden parser EGG. How about a 'units'
check? I would like to see a warning if the values listed with
[C_comp], [Package], R_pin, L_pin, C_pin, [Ramp] and the waveform
fixture variables do not have a suffix attached. For example, if
a model maker entered '5' instead of '5p' as the value of C_comp,
the golden parser would flag it with a warning. I have seen this
error several times, especially with the ramp rate number (leaving
the 'n' off the Dt portion of the ratio).

         Regards,
         Stephen Peters
         Intel Corp.

=------------------------------------

     

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 Thu Feb 22 08:39:42 1996

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT