RE: IBIS - I/O Buffer Modeling Cookbook

Hi Yoked:
 
  Regarding the non-monotonic warnings, I would still check the line number
on the pulldown curves and verify what is causing the non-monotonic warning.
It should be the area where ground clamp current was subtracted from the
total pulldown current and not somewhere else.
  By the way, when creating a model for a non-tristatable output (i.e. one
in which either the pullup or pulldown curves are always on) one does not
have to subtract ground and power clamp current from the curves. In this
case the warning should not occur.
 
  Regards,
  Stephen Peters
  Intel Corp.
 

-----Original Message-----
From: yoked erlich [mailto:yokede@motorola.com]
Sent: Tuesday, August 21, 2001 7:40 AM
To: Ross, Bob; ibis-users@eda.org; stephen.peters@intel.com; ibis@eda.org;
Sergey Sofer (r53493)
Cc: Lior Aviv
Subject: Re: IBIS - I/O Buffer Modeling Cookbook

Hi ,

There are another few questions about ibischk3 results:

1. I've got the next warning:
 WARNING - [Model] iovb has no description of the buffer's high state
                    DC drive characteristics (no [Pullup] table). This
warning
                    can be silenced by changing the Model_type or by adding
a
                    [Pullup] table.
This cell ('iovb') is 'Open_drain' type which according to Ibis maker cook
book do not
suppose to have [Pullup] table , only the [pulldown],[gnd_clamp] and
[power_clamp] tables ,
What do you think might be the reason of this error ?.

2. I've got the next warning:
WARNING (line 427) - Pulldown Typical data is non-monotonic
WARNING (line 427) - Pulldown Maximum data is non-monotonic
WARNING (line 428) - Pulldown Minimum data is non-monotonic
according to pulldn subtraction gnd_clamp cookbook and standard instructions
,
it is impossible to get monotonic data.
It is even mentioned in the standard that the [pulldn] or [pullup] tables
might be non-monotonic.
Is it all right to ignore this warning ?

With regards

Yoked.
"Ross, Bob" wrote:

Hello Yoked:

We are temporarily having reflector e-mail problems,
so you message did not get sent to the general list.

However, I am responding on the ibis-users reflector
and copying Stephen Peters, who authored the Cookbook.
My responses are in your text noted by "*" marks. These
are brief responses without looking at the Cookbook
document. I am trying to convey what was intended,
not any editorial issues regarding how it is documented.

Bob Ross
Mentor Graphics

---------------------

Subject: I/O buffer modeling cookbook
From: Yoked Erlich (r58559) (r58559@email.sps.mot.com)
Date: Sun Aug 12 2001 - 04:18:21 PDT

Hi ,

I would like to ask some questions about the 'I/O buffer modeling
cookbook'
paper (revision 2.0X) , Which I've got from 'www.eig.org' web site.

1. Is there anywhere I can find revision 3.2 cookbook?

* No, a Version 3.2 Cookbook has not been written. Cookbook 2 was
intended to cover Version 3.2 features, but we never got that far.

2. I've an I/O buffer model which working in some chip pads as I/O ,
some pads as steady input and some pads as steady output.
    I would like to know if the buffer grouping is made by the buffer
type or by the pad direction?
    If buffer type is the answer so one model with I/O type in enough
for this buffer,
    If pad direction is the answer so three model is needed for this
buffer , I/O model , Input model and Output model
    ( in this case Input and Output model tests will be exactly the same
as I/O model ) .

* If the buffer is truely an I/O, then it should be provided and
documented as I/O. A user might have additional knowledge that
certain I/O buffers are configured only as Input or Output buffers.
It would be permissible to modify that instance of the model and
just change the Model_type. That would help the EDA tool do
only the simulations that are relevant for the design.

3-6 questions are about 'Extracting Data for the [Ramp] keyword'
paragraph in the cookbook :
3. It is written that 'if the device does not have enough
     drive capability to make a significant output transition than a
higher load may be used' ,
     How much is significant output transition ?

* I do not have any hard guideline. I prefer impedances in the
order of magnitude of transmission line loads since that is a
typical high-speed design application. That ususally captures
a fast edge that would be seen with a PCB interconnect.

* This makes no sense for certain weak buffers which would
require multiple reflections to change from one state to the
other for an open line. If the application is not high-speed,
then it does not manner. I would guess that a higher value
load might be OK for a driver source impedance > 300 ohms.
Others might have different ideas.

4. it is written that ' For an open drain , measure the rise and fall
time into the load resistor and voltage used
    by the manufacture when specifying propagation delays' , This
sentence is not clear
    what is the test structure in open drain buffer case?.

* This is ambiguous. I prefer low impedance (50 ohm) pullups to
capture a faster edge. This may be in the order of magnitude of
the load seen during the intial part of the transition when the
device is connected through a PCB interconnect.

5. it is written that ' Falling edge ramp data is captured with the load
resistor tied to VCC'
    , Is VCC mean the pmos Driver source voltage (pad voltage) or low
voltage?

* This means that one end of the load resistor is connected to
Vcc, and the other end is connected to the output pad.

6. It is written that 'simulations are performed with C_comp included in
the circuit' , This sentence is not clear.
    As I understood C_comp is the capacitance seen when looking from the
pad back into the buffer ,
    It is written that C_comp should be added to the simulation , but
C_comp is not a capacitor it is capacitance measurement.

* It is difficult to de-embed the die capacitance information from a
Spice net list (since some of the contribution is due to paramaters
within the transistor/diode models) or from a real physical measurements.

* So the intent is to clarify that the die capacitance is already
included in any waveform extraction. Since C_comp is a first order
approximation of the die capacitance, its effects should be included
in an EDA tool simulation. I have not looked at the specific
wording, but I assume this is confusing.

7. In 'Ground Clamp' paragraph it is written that 'The data in table
must cover the range of -Vcc to Vcc ' ,
    Isn't it suppose to be -Vcc to 2*Vcc ?

* This response also covers 9.

* No, the minimum range is intended to be -vcc to vcc. The Power
Clamp covers from vcc to 2vcc. When this minimum range was
established, most Inputs were at negligle current at Vcc and the
slope (current vs voltage) was also nearly 0. So concatenation
of the tables produced the same effect as extrapolation.

* It is allowed to extend the clamp ranges beyond the specified
range. In some cases you should do so, especially if you are
including the effect of an internal terminator. In such cases,
the conditions above are not met, and I prefer -vcc to 2vcc for
both clamp tables. Care must be taken so that
currents are not double counted. However, for many situations,
the "minimal" IBIS guidelines are sufficient.

8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state
device then first subtract the ground clamp current
    from the pulldown current then enter the result into the [pulldown]
table' ,
    first , it is written above the graph 'Pullup I/V curve after
subtraction of ground clamp currents' Which is probably mistake.
    second , Should I replace the pulldn results in Ibis model file
after the subtraction?

* What is entered in the [Pulldown] table is the result after
subtraction.

9. In 'Power Clamp' It is written that 'the data in the table must cover
the range of vcc to vcc*2' ,
    Isn't the range suppose to be -Vcc to 2*Vcc ?

* See 7 above.

-- 
With regards, 
Yoked. 
_____________________________________ 
E-mail:       yokede@msil.sps.mot.com 
Tel: 972-9-9522482 Fax: 972-9-9522888 
WIRELESS     CIRCUIT  - IO      GROUP 
MOTOROLA     SEMICONDUCTOR     ISRAEL
-- 
With regards,
Yoked.
_____________________________________
E-mail:           yokede@motorola.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP                 
MOTOROLA     SEMICONDUCTOR     ISRAEL