Subject: IBIS - I/O Buffer Modeling Cookbook
From: Ross, Bob (bob_ross@mentorg.com)
Date: Mon Aug 13 2001 - 15:14:54 PDT
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
This archive was generated by hypermail 2b28 : Mon Aug 13 2001 - 15:17:44 PDT