Text item:
Andy,
I agree with your response. The main problem I see in this discussion is that
we are talking about something, but we don't really know what we are talking
about. We need a definition what that "INPUT" really is. True CMOS input, a
CMOS I/O in receiving mode, Bipolar, etc... The answer might be quite
different.
This kind of holds for the bus-hold circuits as well. Whether we can model it
or not with IBIS depends on how it is built. Is there feedback or other fancy
stuff in it? Is it just a static pullup or pulldown structure? etc...
Arpad
===============================================================================
I wasn't the one who asked the questions, but I'll throw in my two bits,
if for no other reason than to give another opinion.
> Shouldn't the Bus-hold circuit be modeled as an output rather than an input?
Bus-hold circuits are typically used on bi-directs, but because they
come into play when the output is disabled, one tends to think of them
as being part of the input circuit rather than the output. It seems to
make more sense to model them as input currents, since they are always
there whether the output drives or not.
Since IBIS is predicated on modeling static I/V characteristics, and
since the I/V curves of bus-hold circuits depend on past history (a
bi-stable state), there is a problem of how to model them. Anyway,
they may be problematic because of their positive feedback.
> Inputs usually clamp below and above the supply rail. If the failing power
> supply shorts to GND, the input will clamp below -0.6 volts and above +0.6
> volts.
Not necessarily. Many IC inputs do not clamp in the positive direction,
or if they do, it is not at Vcc +0.6 volts.
CMOS inputs need not clamp at all, in principle. Generally speaking,
clamps are added for their protection.
Some IC inputs are designed not to conduct when power is removed;
important for hot-swapping boards or running independent units on a
common bus. I think this is the question John Fitzpatrick is getting
at. Will the clamp characteristics be the same (relative to Vcc) with
the power removed as when it is present? I can't say, though I think
there is a good likelihood that the gross behavior would be similar.
It is probably best to contact the IC manufacturer or IBIS model writer
to see under what conditions those parameters apply.
Regards,
Andy
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[3]: Interpretation of I/O data
Apparently-To: ibis@vhdl.org
Cc: ingraham@wrksys.ENET.dec.com
To: ibis@vhdl.org
From: Andy Ingraham <ingraham@wrksys.ENET.dec.com>
Date: Mon, 22 Jan 96 22:33:05 EST
Received: from wrksys.enet; by us1rmc.enet; Mon, 22 Jan 96 22:33:05 EST
Message-Id: <9601230323.AA04534@us1rmc.bb.dec.com>
Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA04534; Mon, 22 Jan 96 22:23:04 -0500
Received: from us1rmc.bb.dec.com by mail13.digital.com (5.65v3.2/1.0/WV)
id AA23271; Mon, 22 Jan 1996 22:32:19 -0500
Received: from mail13.digital.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
id AA29893; Mon, 22 Jan 96 19:46:13 PST
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com (
8.6.12/8.6.12) with SMTP id TAA29644; Mon, 22 Jan 1996 19:44:44 -0800
Received: from ormail.intel.com by relay.jf.intel.com with smtp
(Smail3.1.28.1 #2) id m0teZf4-000tx5C; Mon, 22 Jan 96 19:44 PST
Received on Tue Jan 23 08:22:19 1996
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT