Re: Pullup/down data

Hello Tareq, Arpad, others:

     Yes, very good questions. I read Arpads answer to your first
question below, but I assumed that the BUS HOLD feature
you refered to is just a weak current source (maybe a resistor?)
that pulls the input to a know voltage level if nothing else
is driving that input. In that is the case, I belive that the extra
current belongs in one of the clamp curves and the input should be modeled
as an input, not as an output or I/O.

        Regards,
        Stephen Peters
        Intel Corp.

Tareq,

These are very good questions!

1) I think this kind of an input must be handeled as if it would be an output
or an I/O buffer. However, a lot depends on how it works. If the HOLD circuit
is always on, model it as if it would be an OUTPUT buffer. If the HOLD circuit
is getting turned on after a certain amount of time (from when it saw a
transition), I would model it as if it was an I/O buffer which starts driving
shortly after it saw an edge. I know, this is a simplistic answer and there
might be more to it than that. More complicated cituations might not be
possible in IBIS as of right now.

2) The answer to this depends on how this power saver works. Does it
immediately turn off if it sees that pre-determined voltage level, or later? If
this save mode does not come into effect untill the reflections are settled, I
would not worry about modeling it. However, if it reduces the drive strength
while the signal is still bouncing back and fourth, it might be important to
model it, since the reflection coeffitients depend on the driver impedance
(=strength). How you do it, is another question. Not knowing the guts of your
buffer, I am just guessing, but using the V-t curves might be one possible way
of doing it if it is time dependent. If it is only voltage dependent, it would
most likely show up in the shape of its I-V curve.

Arpad Muranyi
Intel Corporation
================================================================================

All,

 I need some clarification on the following :

 (1) When running simulations on an "input buffer with Bus-Hold" to
extract clamp
     data, should the bus-hold circuitry be disconnected ?. In other words,
     should we include the contribution from the Bus-Hold circuit
in the clamp data.
     I would think not, any suggestions ?
 (2) Similarly, some of our devices have the so called Power-on-demand
(POD) feature
     on the output buffer. In a BiCMOS device, this feature works
to reduce the
     base current in the pulldown transistor when the output voltage
is below a preset
     level, thereby reducing power consumption. While this circuitry can be
     disconnected in a simulation, it is always present in real-life.
 Again, should
     the effect of such circuit be incorporated into the pulldown data ?.

  Please advise !

Regards,
Tareq Shahwan, ABI Applications

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***.

Content-Length: 891
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL24]
Errors-To: tareq@sh-gpl.ti.com
Reply-To: tareq@sh-gpl.ti.com
Cc: tareq@ti.com (Tareq Shahwan)
Date: Mon, 13 Nov 1995 16:04:27 -0600 (CST)
To: ibis@vhdl.org (ibis @vhdl.org)
Subject: Pullup/down data
Message-Id: <9511132204.AA17997@brain.sh-gpl.ti.com>
Received: by brain.sh-gpl.ti.com id <AA17997@brain.sh-gpl.ti.com>; Mon, 13 Nov 1
995 16:04:28 -0600
From: Tareq Shahwan <tareq@sh-gpl.ti.com>
Received: from brain.sh-gpl.ti.com by sherm-g1.sh-gpl.ti.com with SMTP
     (1.37.109.16/IDA1.4.4.1) id AA224190272; Mon, 13 Nov 1995 16:04:32 -0600
Received: from sherm-g1.sh-gpl.ti.com ([157.170.61.67]) by gate.ti.com (8.6.12/)
 with ESMTP id QAA19480; Mon, 13 Nov 1995 16:06:03 -0600
Errors-To: tareq@sh-gpl.ti.com
Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
     id AA22636; Mon, 13 Nov 95 14:13:38 PST
Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 13 Nov 95 14
:09:37 -0800
Received: from hermes.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0tF74O-000tx4C; Mon, 13 Nov 95 14:09 PST
Received on Mon Nov 13 17:54:58 1995