Re[2]: BIRD18 Column Headers for IBIS Ver. 2.1

From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Date: Mon Jul 25 1994 - 16:14:48 PDT

Text item:

Bob,

Thanks for your response. I would appreciate if you could resend BIRD 18 for me
to make sure I got the right one.

Regarding point 2) below, I wish everyone agreed with what you say, but since I
am not sure, I feel it should be brought up in the Open Forum meetings. I am
just afraid that if I put something in the POWER_clamp section into a range that
is not specified now, someone might ignore it because it is outside the
specified region.

I agree with you on point 3) completely.

Arpad Muranyi
Intel Corporation

Arpad

Here are my views on the questions you raise:

1) BIRD18 applies only to [Diff Pin] and is totally unrelated to BIRD17
While cutting and pasting, I accidentally tranmitted a BIRD18 which
had some BIRD17 verbage, and have subsequently retranmitted BIRD18.
If you need the correct copy, I can send it to you.

2) Regarding the range of any VI table in IBIS, I interpret the mandated
ranges as the Minimum ranges for IBIS compliant models. I believe there
is nothing to prevent the [Power_clamp] table to be extended on either
end. So IBIS does not prevent you from putting in a "weak", non-linear
always on pullup resistor using the [Power_clamp] keyword for any range
including to 0 or -Vcc. The [Gnd_clamp] data from 0 to Vcc (and beyond)
would be set to 0 since the clamping curve currents are added.

3) For normal IBIS buffer applications, you would not need to extend
the clamp ranges beyond what is specified (beyond Vcc for [Gnd_clamp] and
below Vcc for [Power_clamp] because the clamping currents in these regions
are typically negligible. So even if simulators do not do extroplation,
the error would be neglibible. Your pullup resistor is an example where
you need to extend the IBIS range because the currents are not negligible,
and I believe IBIS already supports this application.

Bob Ross,
Interconnectix, Inc.

> So is BIRD 17 or 18 the same thing?

> One more comment I forgot in my last EMAIL:

> If anything, I would like to see both clamps have the same range,
-Vcc to Vcc,
> or even -Vcc to (2 x Vcc). Currently, the POWER clamp is only -Vcc
to 0V, and
> the GND clamp is -Vcc to Vcc.

> We all agreed on earlier open forums that the clamp curves can also
be used for
> internal pullup or pulldown structures ("resistors") for devices
that have it.
> These "resistors" are usually weak transistors which are always
ON. Since they
> are transistors, they have an I-V curve, not a straight resistive
line. The
> best place to put these in an IBIS model is the clamp curve.

> Hovever, currently there is only one place to put such curves, the
GND_clamp
> curve. This creates a few problems when I have a pullup "resistor"
(which I
> have to make VCC relative) and I have to put it into the GND_clamp
curve. If we
> extend the Vcc_clamp range to the same coverage as the GND_clamp,
I could put
> the pullup "resistors" into the POWER_clamp, and the pulldown "resistors"
into
> the GND_clamp curve and my problems would be gone.

> Arpad Muranyi
> Intel Corporation

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Re: BIRD18 Column Headers for IBIS Ver. 2.1
To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org
Message-Id: <9407252052.AA19219@icx.com>
Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.)
        id AA19219; Mon, 25 Jul 94 13:52:07 PDT
From: bob@icx.com ( Bob Ross)
Date: Mon, 25 Jul 94 13:52:07 PDT
Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
        id AA28964 for ; Mon, 25 Jul 94 17:04:06 -0400
Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
        id AA24648; Mon, 25 Jul 94 14:23:28 PDT
Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 25 Jul 94 14
Received: from hermes.intel.com by ormail.intel.com with smtp
        (Smail3.1.28.1 #12) id m0qSXZm-000MNvC; Mon, 25 Jul 94 14:28 PDT
Received: from ormail.intel.com by relay.jf.intel.com with smtp
        (Smail3.1.28.1 #2) id m0qSXYh-000twlC; Mon, 25 Jul 94 14:27 PDT
Received on Mon Jul 25 15:51:40 1994

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT