Re: IBIS - I/O Buffer Modeling Cookbook

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" <yokede@motorola.com>
To: "Ross, Bob" <bob_ross@mentorg.com>; <ibis-users@eda.org>;
<stephen.peters@intel.com>; <ibis@eda.org>; "Sergey Sofer (r53493)"
<r53493@email.sps.mot.com>
Cc: "Lior Aviv" <liora@msil.sps.mot.com>
Sent: Tuesday, August 21, 2001 7:39 AM
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
>
>
>

 
Received on Tue Aug 21 09:09:40 2001