From John.Fitzpatrick@ln.cit.alcatel.fr Tue Jan 23 08:46:36 1996 Return-Path: Received: from alcatel.fr ([193.104.30.131]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11416; Tue, 23 Jan 96 08:46:36 PST Received: by gatekeeper.alcatel.fr id <21905>; Tue, 23 Jan 1996 17:36:02 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Date: Tue, 23 Jan 1996 17:19:42 +0100 From: FITZPATRICK John Organization: Alcatel CIT, 22304 Lannion, France X-Mailer: Mozilla 2.0b5 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis-users@vhdl.org Cc: Arpad Muranyi Subject: 3 issues (was Re[3]: Interpretation of I/O data ) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <96Jan23.173602gmt+0100.21905@gatekeeper.alcatel.fr> Hello all! I'd like to thank Arpad Muruanyi taking the time to answer my questions. These questions arose from internal discussions here at Alcatel as to whether an IBIS model can replace the electrical characteristics specification for a component. It would be nice if a combination of IBIS and VHDL models could provide, as a minimum, the same information as a paper datasheet. (This would mean extending the definition of the IBIS model to more than behavioral models.) Below are some ideas on 1) INTERPRETING INPUT V/I CURVES 2) ABSOLUTE MAXIMUM RATINGS 3) NEW INPUT SUB-PARAMETERS I hope you find them of interest. Depending on feedback, I may write 2 & 3 up as a BIRD. (Does Alcatel need to be an IBIS member if I want to submit a BIRD? Should I have said EGG?) Regards, John 1) INTERPRETING INPUT V/I CURVES Arpad asked: > What are you referring to when you say FAST-type? Significant input current. (I was a bit confused by the receiver model, which contains only clamping diode curves.) Has anybody modelled an input with significant input current? Arpad asked: > Shouldn't the Bus-hold circuit be modeled as an output rather than an input? Hmm. I guess so - if that's the buffer's only function. But "bus hold" is usually a feature associated with an input buffer, so I think it would be better simply to include the current in or out as part of the input buffer's V/I curve. Maybe someone from TI could post an example of model of an LVT input? 2) ABSOLUTE MAXIMUM RATINGS I asked: > >Can a buffer which doesn't clamp when powered, clamp > >when unpowered (for applied voltages in the range 0 to Vcc)? Arpad replied: > If the power on the input disables the clamping somehow, I can see that it could > clamp when it is not powered. But it would be helpful if you would state what > kind of input you are referring to. Regular CMOS, or something unusual, which I > don't know about? CMOS DOES clamp ewen when it is powered (0.6 volts above > Vdd). It does seem natural to make the assumption that if the buffer doesn't clamp from Vcc to 2Vcc, over the specified Vcc range, then it won't clamp inputs from 0 to ~|Vcc| when Vcc = 0. Similarly, a 3.3V buffer, which clamps at Vcc+2V normally, will clamp at 2V when its Vcc = 0. But this is only my interpretation of the IBIS data. On re-reading my question, I realise that what I am looking for is an Absolute Maximum Ratings section in the IBIS model. With IBIS 2.1, it's not possible to answer questions like: - What is the maximum over/undershoot voltage or current tolerated by a component? - Over what time-scale can an over/undershoot safely be tolerated? - If the power supply fails, is it sufficient protection to limit the input current? To what value? Over what time-scale? - etc A good example of the "modern" absolute maximum ratings is that specified by Xilinx: "Maximum DC overshoot above Vcc or below GND must be limited to either 0.5 V or 10 mA, whichever is easier to achieve. During transitions, the device pins may undershoot to -2.0 V or overshoot to Vcc + 2.0 V, provided this overshoot or undershoot lasts less than 20 ns. Can the IBIS model evolve to take this type of specification into account? My suggestion is to supply a table of voltage v.time for each [Model] entry: -----------------------start of example----------------------------- [Abs Max Applied Voltage Pos Ref] POWER | Simple example, only one power supply | If not present, assume GND [Abs Max Applied Voltage Neg Ref] GND | If not present, assume GND [Abs Max Applied Voltage] | Time Positive_Voltage Negative_Voltage 0 2.0V -2.0V 20n 0.5V -0.5V -----------------------end of example------------------------------- Other absolute maximum rating may also be necessary (supply voltage, temperature, etc) The maximum current can be derived from the V/I curves *IF* these can be extrapolated for use over absolute maximum supply voltage range. Any comments? 3) NEW INPUT SUB-PARAMETERS Arpad said: > If it > is important to you, you might want to raise this (and the hysteresis) issue in > the Open Forum Meeting. I brought it up last time, and people are open to these > kinds of comments, requests My suggestion is that two new sub-parameters might be added to the [Model] keyword. Vh = 0.4V | minimum hysteresis value dt/dV_in = 10ns/1V | maximum input transition rise or fall time These values could be used to issue warning during a simulation. Any comments? -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From Will_Hobbs@ccm.jf.intel.com Tue Jan 23 11:00:49 1996 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12401; Tue, 23 Jan 96 11:00:49 PST Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id KAA06008; Tue, 23 Jan 1996 10:52:38 -0800 Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tenpc-000twiC; Tue, 23 Jan 96 10:52 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Tue, 23 Jan 96 10:52:36 PST Date: Tue, 23 Jan 96 10:49:00 PST From: Will Hobbs Message-Id: To: John.Fitzpatrick@ln.cit.alcatel.fr, ibis-users@vhdl.org Cc: Arpad_Muranyi@ccm.fm.intel.com Subject: Re: 3 issues (was Re[3]: Interpretation of I/O data ) Text item: John, Anyone can submit a BIRD or an EGG. An EGG is an unofficial "pre-BIRD," if you will. We don't actually formally track them. They are used to express ideas that aren't quite completely formulated, and hence can't be put into a BIRD. Sometimes they evolve into BIRDs (hatch), sometimes not. If you choose to submit a BIRD, you must follow the format we have defined for them, which you can get from the VHDL.org machine or from any officer or long-time participant in the forum. Send the BIRD to me (will_hobbs@jf.ccm.intel.com) and I will assign a number to it and post it to the reflector. Regarding your comments about extensions to IBIS to be more comprehensive, like a data sheet, CFI is doing similar work to bring together many standards into a comprehensive relationship that covers these bases. I'm sure others can amplify on this. We always face a choice between making IBIS more comprehensive and keeping it simple. The choice is: Should we extend it beyond its original purpose (providing a behavioral way of specifying I/O buffer analog characteristics) to make it more broadly useful, such as an electronic data sheet? Or should we keep the definition narrow? We can't be all things to all people, and overly-complex specs tend to die eventually, or not be adopted. So, we often tend towards the simpler end of the spectrum and hope that other specifications will fill in the holes. Don't take this as discouragement, however. The forum is willing to entertain lots of ideas, and if simple extensions can broaden the usefulness of IBIS, they might be worth considering. Regards, Will Hello all! I'd like to thank Arpad Muruanyi taking the time to answer my questions. These questions arose from internal discussions here at Alcatel as to whether an IBIS model can replace the electrical characteristics specification for a component. It would be nice if a combination of IBIS and VHDL models could provide, as a minimum, the same information as a paper datasheet. (This would mean extending the definition of the IBIS model to more than behavioral models.) Below are some ideas on 1) INTERPRETING INPUT V/I CURVES 2) ABSOLUTE MAXIMUM RATINGS 3) NEW INPUT SUB-PARAMETERS I hope you find them of interest. Depending on feedback, I may write 2 & 3 up as a BIRD. (Does Alcatel need to be an IBIS member if I want to submit a BIRD? Should I have said EGG?) Regards, John 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***. Message-Id: <96Jan23.173602gmt+0100.21905@gatekeeper.alcatel.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: 3 issues (was Re[3]: Interpretation of I/O data ) Cc: Arpad Muranyi To: ibis-users@vhdl.org Mime-Version: 1.0 X-Mailer: Mozilla 2.0b5 (X11; I; SunOS 4.1.3_U1 sun4c) Organization: Alcatel CIT, 22304 Lannion, France From: FITZPATRICK John Date: Tue, 23 Jan 1996 17:19:42 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Received: by gatekeeper.alcatel.fr id <21905>; Tue, 23 Jan 1996 17:36:02 +0100 Received: from alcatel.fr ([193.104.30.131]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRN et) id AA11416; Tue, 23 Jan 96 08:46:36 PST Received: from vhdl.vhdl.org by hermes.intel.com (8.7.1/10.0i); Tue, 23 Jan 1996 09:52:24 -0800 Received: from hermes.intel.com by ichips.intel.com (8.7.1/jIII); Tue, 23 Jan 19 96 09:52:30 -0800 (PST) Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0temtU-000twVC; Tue, 23 Jan 96 09:52 PST From bob@icx.com Wed Jan 24 13:14:57 1996 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00683; Wed, 24 Jan 96 13:14:57 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Jan 96 13:06 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Jan 96 13:09 PST Message-Id: Date: Wed, 24 Jan 96 13:09 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org Subject: Test Please Disregard From bob@icx.com Thu Jan 25 20:36:56 1996 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00683; Wed, 24 Jan 96 13:14:57 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Jan 96 13:06 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Jan 96 13:09 PST Message-Id: Date: Wed, 24 Jan 96 13:09 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org Subject: Test Please Disregard