Subject: IBIS - I/O Buffer Modeling Cookbook

From: "Ross, Bob" <[email-masked]>
Date: Mon, 13 Aug 2001 15:14:54 -0700

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) ([email-masked])
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:       [email-masked]
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP
MOTOROLA     SEMICONDUCTOR     ISRAEL

---

From: yoked erlich <[email-masked]>
Date: Tue, 21 Aug 2001 17:39:43 +0300

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.

--

With regards,

Yoked.

E-mail:           [email-masked]

---

From: "Matthew Flora" <[email-masked]>
Date: Tue, 21 Aug 2001 09:10:21 -0700

Dear Yoked Erlich,

Regarding your first question:
Which version of ibischk3 are you using?  The latest version available is
3.2.7.  There was a bug in earlier versions that generated incorrect warnings
for open drain buffers.

Best regards,
Matthew Flora

----- Original Message -----
From: "yoked erlich" <[email-masked]>
To: "Ross, Bob" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Sergey Sofer (r53493)"
<[email-masked]>
Cc: "Lior Aviv" <[email-masked]>
Sent: Tuesday, August 21, 2001 7:39 AM
Subject: Re: IBIS - I/O Buffer Modeling Cookbook