Model Check List Discussion

All,

At the last phone-in meeting I pledged to share our steps in checking and using
IBIS models we receive for the sake of getting a discussion going on the
subject:

Our process has been partially defined, documented and controlled as part of our
ISO 9000 certification. The modeling process has been done. The simulation
process is in discussion and there is general agreement on it. But, it has to be
brought to closure.

Formality in following the model acquisition and verification process is
somewhat lax among product design engineers. This is primarily due to newness
and schedule pressure. The consequence of this laxness is that very valuable
lead time in acquiring the models gets lost.

In the discussion below model element is equivalent to keyword.

The process intends that we:

   Start with model elements and verification needed:

   The user (person who will simulate Signal Integrity) determines (estimates)
   what model elements he or she needs in the IBIS file and specifies same on a
   model request form (ISO document). Also specified on the request form is what
   "level of verification" will be needed. The elements requested have a direct
   bearing on any model checklist and verification.

   For instance, is dV/dt good enough or will V-T waveform data be needed? Is
   conform to the data sheet good enough, or will lab measurement verification
   be needed? This is done either at the time a new component is requested (ISO
   document), or when a design is to be reused and re-simulated/simulated, or
   when troubleshooting a production problem.

   To guide the user there is an internal IBIS standard (ISO document) which
   draws heavily on the current IBIS standard. It does a few additional things:
   1) Organize and separate model elements for better understanding and
   readability; 2) Separate model elements into a minimum standard (required of
   all) group and an optional (not required unless specified by the user) group;
   3) Define the four 3Com verification levels, and; 4) Explain methods for
   creating, verifying and detecting/correcting common IBIS model mistakes.

   My current list of common mistakes, what most people consider is their
   "checklist," is included below.

   Also, to assist the user in estimating the model elements and accuracy needed
   there is a "How to Use," a "Logic Family Signal Integrity Comparisons" and a
   "Signal Integrity - Board Design and Simulation Techniques" (non-ISO)
   document available on our internal web site. Accuracy needs are a trade-off
   with device capability, logic speed, complexity, and tolerance to variation.

   Next, there is a process (ISO document) for deciding to make or buy the IBIS
   model.

   For buying an IBIS model we have a "3Com IBIS Model Acceptance Criteria" (not
   yet ISO) document to summarize and guide them through our overabundance of
   documentation.

   For making an IBIS model we have a "Simulation Model Creation and Updating
   Process (ISO).," an "IBIS model Syntax Guide (non-ISO)" and a "Simulation
   Model Verification Process (ISO)" document available.

   We are developing procedures for storing IBIS models in our component library
   data base for use in SI simulation. This will have to address the case of
   models from EDA tool vendor libraries and their verification.

3Com Verification Levels outlined:

     Level 1 by direct measurement: High level of approval.
     Level 2 by correlation with a correlated SPICE model.
     Level 3 by correlation with a data sheet.
     Level 4 No parametric verification - will run in simulator: Low level of
     approval. IBIS model file checked for correct
               syntax with IBIS Golden Parser and/or Cadence ibis2signoise.

     We also make use of the "I/O Buffer Accuracy Handbook" from the IBIS
     committee.

Current Common Errors Checklist:

1. Numerous [End] statements.

Improper use of SPICE2IBIS tools?

Correction: Text edit the IBIS file and remove the extra statements.

2. Syntax errors of all sorts.

For example: Tab characters following keywords, lines longer than 80 ASCII
characters,
non-ASCII characters, ( / ) \ % @ # * etc., etc. Data item names too many
characters long.
Missing keywords and data items. Literal (actual) keywords inserted in the text
of
uncommented-out notes. File names that are different than the [File name ]
keyword. Etc.

Only spaces and underbars "_" are allowed in names.

Syntax errors in supplied IBIS models are so common as to hardly bear
mentioning.

Correction: Use the latest version of the IBIS Standard, this 3Com IBIS
Standard, the IBIS
Golden Parser downloaded from their website, our Cadence ibis2signoise parser,
and Appendix A:
"IBIS Model Syntax Guide" to diagnose and fix the problem. Otherwise, have the
IBIS model supplier
send you a corrected file.

3. Missing units in [Package]. H instead of nH, F instead of pF.

Correction: Verify the correct units with the IBIS model supplier and text edit
 the IBIS model
file to add them if the work isn't excessive. Otherwise, have the IBIS model
supplier send you a
corrected file.

4. No minus signs on current out of a device ([Pullup], [GND Clamp]).

Correction: Verify the correct current convention with the IBIS model supplier
and ask them to
send you a corrected model file. Because of the amount of work required, text
edit the IBIS model
file to correct the problem only if the supplier is not forthcoming in a timely
fashion.

5. [Pullup] and [POWER Clamp] not Vcc relative.

Comment: The IBIS convention is Vtable = Vcc - Voutput. So, for a Vcc of 5 volts
 when:
Voutput = -5, then Vtable = 10
Voutput = 0, then Vtable = 5
Voutput = 10, then Vtable = -5

Correction: Verify the correct voltage convention with the IBIS model supplier
and ask them to send
you a corrected model file. Because of the amount of work required, text edit
the IBIS model file to
correct the problem by adding or subtracting a constant amount (usually the Vcc
value) only if the
supplier is not forthcoming in a timely fashion.

6. Range of V-I curves do not correspond to -Vcc to +2Vcc.

Correction: Verify the correct voltage range with the IBIS model supplier and
ask them to send you a
corrected model file. Because of the amount of work required, text edit the IBIS
 model file to correct
the only if the supplier is not forthcoming in a timely fashion. You can add or
subtract data points.
Linear extensions of curves are reasonable when adding points

7. No clamps in [Model] possible, but suspicious.

One possible explanation of missing clamp curves is that their currents were
included in the
pullup/pulldown curves of a measured device model. Particularly in a non
tri-state-able device where
they cannot be separated out of the total output current. Another possible
explanation is a 5 volt
TTL compatible input on a low voltage device where they are not present. But,
most high speed digital
devices incorporate ESD protection.

Correction: After verifying problem, require generation of a corrected model by
model supplier.
Otherwise not correctable.

8. Unrealistic currents in clamp curves, i.e., GigaAmperes, Nano-Picoamperes,
etc.

Correction: Consult with device supplier regarding realistic maximum and minimum
 currents. Contact
model supplier and ask them to send you a corrected model file. Because of the
amount of work required,
text edit the IBIS model file to correct the problem only if the supplier is not
 forthcoming in a
timely fashion.

To correct the file, delete all the unrealistically high data entries. Also,
clamp curves should
eventually clamp. Instead of ridiculously small values at the end of the curve,
just set the current to
zero. Most simulators want to see at least two consecutive points of 0 mA at the
 end of all clamp curves.

9. Non-unique [Model] statements, i.e., two cells called "Output."

Correction: Consult with device supplier regarding which cells are the correct
ones. Contact model
supplier and ask them to send you a corrected model file. Text edit the IBIS
model file to correct
the problem only if the supplier is not forthcoming in a timely fashion. To
correct the file, delete
all the incorrect cells.

10. [Ramp] dt doesn't represent 20% to 80% into 50 ohms.

Correction: Get the corrected slew rates from the model supplier and text edit
the IBIS model file to
correct the problem. If the supplier is not forthcoming in a timely fashion, do
the following:

The slew rate you have, dV/dt_original, will have to be "re-sized" to the
correct definition of 20% to 80%
of the output switching range.

First, you will have to establish the correct output switching range, call this
V. Most often this will be
Vcc = 0 volts. But, not always. For instance, the output swing of a BTL driver
is 2.1 to 1.1 volts or 1
volt.

Then, calculate 60% (80% - 20%) of V = dV_new.

Next, find dt_new given that dV/dt_original = dV/dt_new.

Finally, enter the corrected slew rate(s) in the IBIS file.

11. Slew Rates ([Ramp] - dV/dt_r, dV/dt_f) are ridiculous, i.e. 1.5E-10nS.

Comment: What can I say?

Correction: You get the idea.

12. Data table typ-min-max in wrong order.

Correction: Contact model supplier and ask them to send you a corrected model
file. Because of the amount
of work required, text edit the IBIS model file to correct the problem only if
the supplier is not
forthcoming in a timely fashion. To correct the file, all the data will have to
be re-entered in the
correct order.

13. Big discontinuities (large spikes) and non-monotonicity in V-I or V-T curves
 when viewed visually.

Comment; Most simulators nowadays can handle small discontinuities in the input
data fed them. But, large
discontinuities usually prevent convergence. Large discontinuities are also not
realistic and are usually
caused by measurement artefacts and/or simulation of unrealistic models.

The IBIS golden parser, ibischk3 (and probably many other versions), checks for
non-monotonicity in the
IBIS file and gives warnings. Any non-monotonicity data can be removed when the
parser gives a warning.

Correction: Again, contact the model supplier and ask them to send you a
corrected model file. Because of
the amount of work required, text edit the IBIS model file to correct the
problem only if the supplier is
not forthcoming in a timely fashion. To correct the file, delete all the
unrealistic data entries and
re-enter smoothed data for the offending points.

14. Double counting of clamp currents, i.e., [GND Clamp] magnitudes in both [GND
 Clamp] and [Pulldown].
Comment: The V-I curves of an output, as measured, will include the action of
the pullup/pulldown curves
and the clamps, if present. In many devices it is possible to disable the
pullup/pulldown and then measure
the action of the clamps alone. Sometimes model suppliers forget to subtract the
 clamp currents from the
total output behavior and present the behavior of the pullup/pulldown itself.

Correction: contact the model supplier and ask them to send you a corrected
model file. Because of the
amount of work required, textedit the IBIS model file to correct the problem
only if the supplier is not
forthcoming in a timely fashion. To correct the file, subtract the clamp
currents from the total output
currents and enter the remainder as the pullup/pulldown curve(s).

15. Common Differential Pin-Pair Mistakes:

Making the non-inverting pin inverting, or vice versa, on drivers or receivers.
Entering Launch Delay data for a receiver (Input) cell.
Entering Vil or Vih data for a driver (Output) cell.

A word on running a file through the IBIS golden parser or Cadence
ibis2signoise:

   About half of all IBIS files I receive contain the most careless of mistakes:
   incomplete pin lists (very common), no IBIS version specified, input cells
   with no thresholds or only one threshold, file names that don't match [File
   Name], data not in the typ-min-max sequence files with output cells only - no
   inputs or I/Os, missing model cells, duplicate Model_name - you name it.
   Often, it seems to me, these files are created by people who have never run a
   single Signal Integrity simulation met a product design objective and have
   not a clue regarding their customer's needs.

   In their defense, IBIS is complex; IBIS files are long, detailed and boring
   reading, and; computer data input is unforgiving. It seems to me that IBIS
   model suppliers need to make habitual use of good parsers (syntax mistakes
   tend to jump out) and do at least an eyeball check in a graphical user
   interface (odd curves, missing pin lists, etc., tend to jump out). Excellent
   parsers are available from EDA tool vendors. One can only hope that they have
   enough sense to provide them free of charge to semiconductor suppliers. No or
   bad models - no tool sales.

   Plus, parsers can be designed to do reality checks on the data itself, not
   just syntax and inclusion of required elements tests.

A word on "experimental" models:

   2/3rds of all IBIS models requested and unavailable on the web, etc., I never
   get in time (or ever) to do me any good in meeting a development schedule.

   On critical nets I'm forced to "innovate." This includes borrowing I/O cells
   of parts from similar, as closely matching as possible technology, cobbling
   together a pin list from the data sheet, etc., and creating an experimental
   model - including my estimate of typ-min-max. This may be good enough if it
   appears that; 1) I have lots of design margin and/or; 2) I send my "what-if"
   model to my supplier and ask them to make the parts like the model or tell me
   what they can make. This at least gets some dialog going and some guesstimate
   of device performance.

   Just now I haven't though through all the implications of this nor the
   storage and use of such models.

   Lastly, I'll be sending as many documents as possible referred to above to
   Syed Huq for review and possible posting of portions to the IBIS website.
   Neither of us wants to make the content too company (user, supplier or tool
   vendor) centric.

Open for discussion.

Best Regards to All,

Roy
Received on Thu Jul 6 12:15:34 2000