Hello Arpad:
Mmmmm.....that's OK if a resistance is expressed as '0.2' instead
of '200m' - it just results in an additional warning message. We could
handle scientific notation by simply checking the exponent value, but
the real point of this bird is to detect the missing suffix (the most
common error).
Thanks for your comments!
Regards,
Stephen
Text item:
Stephen,
Sounds like a good idea, but what do you do if the value is expressed in the
base unit? This might happen often with the resistance values, or if one uses
engineering or scientific notation.
Arpad
==============================================================================
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
**** |
** |
* |
** |
* |
** |
* |
** |
* |
---------------------------------------------------------------------------
Text item: External Message Header
The following mail header is for administrative use
and may be ignored unless there are problems.
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
From: Stephen Peters <speters@ichips.intel.com>
Date: Thu, 22 Feb 1996 08:31:09 -0800
Subject: EGG10 - Proposed Automatic Validation Checks
Cc: crokusek@qdt.com
To: ibis@vhdl.org
Message-Id: <9602221631.AA26484@xtg801>
Received: from localhost by xtg801 (4.1/10.0i); Thu, 22 Feb 96 08:31:10 PST
Received: from xtg801 by ichips.intel.com (8.7.1/jIII); Thu, 22 Feb 1996 08:31:1
1 -0800 (PST)
Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.in
tel.com (8.6.12/8.6.12) with ESMTP id IAA29510; Thu, 22 Feb 1996 08:31:14 -0800
Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.
org (8.7.3/8.7.3) with SMTP id IAA21261 for <ibis@vhdl.org>; Thu, 22 Feb 1996 08
:39:41 -0800 (PST)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com (
8.6.12/8.6.12) with ESMTP id IAA00827; Thu, 22 Feb 1996 08:39:11 -0800
Received: from ormail.intel.com by relay.jf.intel.com with smtp
(Smail3.1.29.1 #4) id m0tpe33-000I82C; Thu, 22 Feb 96 08:39 PST
Received on Fri Feb 23 08:37:09 1996
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT