Re: Switched clamping diodes

From: Ben Andresen <andresen@asic.sc.ti.com>
Date: Tue Apr 23 1996 - 06:27:08 PDT

Since TI was mentioned in the earlier msg from John I want to clarify the
switching clamp diode situation as far as our clamp diodes are concerned. All
5V tolerant ASIC I/O with clamp diodes have the diode continuously attached to
the 5V supply. Arpad's description is exactly how the TI ASIC circuits
perform. The only exceptions are the universal PCI buffers which have diodes
to the VI/O supply which could be either 3V or 5V. Those diodes are also
continuously attached to VI/O.

Ben Andresen andresen@asic.sc.ti.com

> From owner-ibis@vhdl.vhdl.org Mon Apr 22 18:40:27 1996
> To: owner-ibis@vhdl.org, ibis@vhdl.org
> Subject: Re: Switched clamping diodes
>
>
> Text item:
>
> John,
>
> You might understand the situation of I-V curves a little better if you compare
> the case of the I/O and Output only (non 3-statable) buffers.
>
> If you make a model for an output only buffer, the clamp curves will have to be
> part of the pullup/pulldown I-V curves. This is because you cannot 3-state the
> device to measure the clamps separately by themselves. (In a way both pullup or
> pulldown are always present together with the clamps).
>
> The quote you cited below refers to 3-statable buffers or I/O-s, in which the
> clamps are always present, while the driver section of the buffer may not be
> there all the time (when the device acts as a receiver, for example). The
> intention in IBIS was to separate the static "constantly present", and the
> switched "when needed" characteristics of the buffers somehow.
>
> Now, if you have a buffer that has a switched clamp, I don't see anything wrong
> with combining the switched clamp I-V curves with the pullup or pulldown I-V
> curves, as long as they are switched together. If they are switched separately
> in time, you might need to model things differently, which might not be possible
> with IBIS directly. If the simulator tool you are using is flexible enough, you
> might be able to get around this problem by making two models, one to represent
> the pullups/pulldowns and another to represent the clamps and then driving them
> with two independent clocks or enables.
>
> By the way, some 5 V safe 3.3 V buffers do have constantly present clamps, but
> they clamp above 5 V only. If a CMOS device has a p-channel pullup, the pullup
> I-V curve will cross 0 mA at 3.3 V and draw current between 3.3 and 5 V due to
> the symmetrical nature of the CMOS channel. I would not call this a clamp,
> however, since this current is part of the pullup transistor's characteristics
> and not it's parasitic diode or a separate ESD structure
>
> I hope this helps in clarifying the usage of I-V curves.
>
> Arpad Muranyi
> Intel Corporation
> ===============================================================================
>
> All,
>
> Thanks to everyone who replied to my earlier mail to ibis-users.
>
> >From the answers, I don't think my 2nd point was
> expressed clearly enough
>
> > 2) One family of components switches out the power clamp
> > diode whenever the output buffer is in tri-state.
>
> This family is 5V tolerant LVC from Philips (and TI). When in
> 3-state, the clamping diode to Vcc is "removed". However, in
> active state, it is present.
>
> In the IBIS spec, it is assumed that:
> "the data in the clamping curve sections are handled
> as constantly present curves and the pullup and
> pulldown curves are used only when needed"
>
> This assumption is false for LVC. The clamping curves are not
> constantly present!
>
> A work-around for 2.1 is to put the clamping curve in with the
> pull-up and pull-down curves. As long as the 3-state curve is
> truly high-impedance, the model will be very good.
>
> For 3.0, perhaps it would it be an idea to have separate curves
> for active and 3-state modes?
>
> 2.1
> 3-state: [3-state] = [GND_clamp] + [POWER_Clamp]
> Active: ( [Pullup] or [Pulldown] ) + [3-state]
>
> 3.0 Proposal:
> 3-state: [3-state] = [GND_clamp] + [POWER_Clamp]
> Active: [Pullup] or [Pulldown]
>
> In order to reduce confusion, it would be better to rename
> [GND_clamp] and [POWER_clamp] to [3-state pullup] and
> [3-state pulldown]. Then, if the simulator detects the new keywords,
> it will know that the definition of [Pullup] and [Pulldown]
> has changed. In this way, a 2.1 description would still be valid
> in 3.0.
>
> Any comments?
> John
>
>
>
> --
> John Fitzpatrick <John.Fitzpatrick@ln.cit.alcatel.fr>
> Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France
> Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09
>
> 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-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=us-ascii
> Subject: Switched clamping diodes
> To: ibis@vhdl.org
> Mime-Version: 1.0
> X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c)
> Organization: Alcatel CIT, 22304 Lannion, France
> From: FITZPATRICK John <John.Fitzpatrick@ln.cit.alcatel.fr>
> Date: Mon, 22 Apr 1996 12:30:55 +0200
> Message-Id: <317B5FDF.1CFBAE39@ln.cit.alcatel.fr>
> Sender: fitzpat1@ln.cit.alcatel.fr
> Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1)
> id AA00371; Mon, 22 Apr 96 12:30:57 +0200
> Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1)
> id AA07812; Mon, 22 Apr 96 12:31:00 +0200
> Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by
> nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id MAA24775 for <ibis@vhdl.org>; Mon,
> 22 Apr 1996 12:28:07 +0200 (METDST)
> Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.241]) by mailg
> ate.alcatel.fr (8.7.3/8.7.3) with ESMTP id MAA29583 for <ibis@vhdl.org>; Mon, 22
> Apr 1996 12:27:34 +0200
> Received: from alcatel.fr (mail.alcatel.fr [193.104.30.131]) by vhdl.vhdl.org (8
> .7.3/8.7.3) with ESMTP id DAA07877 for <ibis@vhdl.org>; Mon, 22 Apr 1996 03:37:4
> 0 -0700 (PDT)
> Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c
> om (8.7.4/8.7.3) with ESMTP id DAA22346; Mon, 22 Apr 1996 03:35:11 -0700 (PDT)
> Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.192.4])
> by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id DAA20722; Mon, 22 Apr 1996 03:
> 35:55 -0700 (PDT)
> Return-Path: owner-ibis@vhdl.vhdl.org
>
Received on Tue Apr 23 06:37:27 1996

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