From randyh Tue Jan 4 13:40:34 1994 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21200; Tue, 4 Jan 94 13:40:34 PST Date: Tue, 4 Jan 94 13:40:34 PST From: randyh (Randy Harr) Message-Id: <9401042140.AA21200@vhdl.vhdl.org> To: ibis@vhdl.org Subject: New files Welcome back from the holidays! Will Hobbs sent down the meeting minutes from the summit (see pub/ibis/summit93) along with the overview document (see pub/ibis/overview.doc). Some of the latest meeting minutes (usually in the email archive file) were also sent (see pub/ibis/minute93). For the most part, only the original Microsoft WORD document binaries are available. When we get a chance (or if someone would like to submit them) we will add the RTF and PostScript versions. randy harr randyh@lmc.com From ccm!Will_Hobbs@intelhf.intel.com Tue Jan 4 17:38:33 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23119; Tue, 4 Jan 94 17:38:33 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pHNBO-000MNXC; Tue, 4 Jan 94 17:37 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pHNEK-0000hkC; Tue, 4 Jan 94 17:40 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 4 Jan 94 17:40:11 PST Date: Tue, 4 Jan 94 17:40:11 PST From: Will Hobbs Message-Id: <940104174011_78@ccm.hf.intel.com> To: ibis@vhdl.org Subject: New IBIS Bridge Text item: Text_1 IBISers and Fellow Electronic Ornithologists, The next meeting of the IBIS Open Forum will be from 9:00 - 11:00 Pacific time on Friday, January 7. The bridge number is: (415) 904-8944, the reservation number is 627407. Please reference my name (Will Hobbs) as chairperson when you phone in and tell the bridge operator the reservation number. Best Regards, Will From Ravender_Goyal@pdxml1.mentorg.com Thu Jan 6 09:39:35 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22893; Thu, 6 Jan 94 09:39:35 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA27632; Thu, 6 Jan 94 09:38:08 -0800 Received: from pdxml1.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA05347; Thu, 6 Jan 94 09:38:07 -0800 Message-Id: <9401061738.AA05347@rainbow.mentorg.com> Date: 6 Jan 1994 09:43:09 -0800 From: "Ravender Goyal" Subject: High freq effects in i/o mo To: "chuck catto" , "ravender Goyal" High freq effects in i/o modeling 9:07 AM 1/6/94 Dear IBISers, I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: | Vcc/ Vdd/ etc. ____|____ | B | | L | | A | input o--------| C |---------o output | K | | | | | | BOX | === pin capacitance -------------------- | | | Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: --------------- | Vcc/ Vdd/ etc. | ____|____ | | B | == | L | | | A | input o--------| C |---------o output | | K | | | | | | | | BOX | === pin capacitance == -------------------- | | | | ------------ Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From rgoyal@wv.MENTORG.COM Thu Jan 6 10:31:02 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23192; Thu, 6 Jan 94 10:31:02 PST Received: from wv.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA28867; Thu, 6 Jan 94 10:29:41 -0800 Received: from em-wv03.mentorg.com by wv.MENTORG.COM (5.65c/CF5.1R) id AA19917; Thu, 6 Jan 1994 10:29:39 -0800 Received: from wolf.MENTORG.COM by em-wv03.MENTORG.COM (4.1/CF3.4) id AA10261; Thu, 6 Jan 94 10:29:38 PST From: rgoyal@wv.MENTORG.COM (Ravender Goyal) Received: by wolf.MENTORG.COM (1.37.109.4/CF3.4) id AA11656; Thu, 6 Jan 94 10:29:37 -0800 Date: Thu, 6 Jan 94 10:29:37 -0800 Message-Id: <9401061029.ZM11654@wolf> X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis@vhdl.org, chuck_catto@wv.MENTORG.COM Subject: high freq effects in i/o models Sorry, in my last message, it seems that the figures did not come through good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From catto@wv.MENTORG.COM Thu Jan 6 10:44:06 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23230; Thu, 6 Jan 94 10:44:06 PST Received: from wv.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA29203; Thu, 6 Jan 94 10:42:44 -0800 Received: from em-sj01.MENTORG.COM ([134.86.73.77]) by wv.MENTORG.COM (5.65c/CF5.1R) id AA20278; Thu, 6 Jan 1994 10:42:41 -0800 Received: from hpcatto.MENTORG.COM by em-sj01.MENTORG.COM (4.1/CF3.5) id AA28559; Thu, 6 Jan 94 10:46:01 PST From: catto@wv.MENTORG.COM (Chuck Catto @ PCB x5506) Received: by hpcatto.MENTORG.COM (1.37.109.4/CF2.9) id AA11480; Thu, 6 Jan 94 10:47:17 -0800 Date: Thu, 6 Jan 94 10:47:17 -0800 Message-Id: <9401061047.ZM11478@hpcatto> In-Reply-To: "Ravender Goyal" "High freq effects in i/o mo" (Jan 6, 9:43am) References: <9401061738.AA05347@rainbow.mentorg.com> X-Mailer: Z-Mail (2.1.3 26jan93) To: "Ravender Goyal" , "ravender Goyal" Subject: Re: High freq effects in i/o mo Cc: catto@wv.MENTORG.COM Ravender, Yes, whole heartedly! Way back when, when I first started using Quad, the one question I had in mind was freqency dependent char- acteristics of the output drivers and input receivers. All mea- surements are done at DC, without any jw effects taken into ac- count. And in doing so, as you have stated below, this would lead to an understanding of the modelization or internal char- acteristics of those devices looking into the output of a driver or into the input of a receiver. I feel it is necessary to take the imaginary component into effect, and not rely simply on a lumped capacitance to a pin are some "equivalent" series inductance of an io pin. The modeling becomes even more important at higher frequencies, as you mentioned. I did not fully get your drawings, with the BLA K. I was trying to make sense, and thought perhaps the L meant inductance, etc., but lost it in the BA and K. A FAX with a sketch would do me fine, and would be much appreciated. I read with much interest your work on producing more accurate closed form equations for characteristic impedance, etc. I think you are doing an excellent job, and I am glad we have the right person at the helm of this 'high-speed' ship. I have a lot of respect for you. Any and all inputs with respect to Quad, IBIS modeling, XFX3D and other new developments, as well as research you are conducting, is much appreciated. Take care, - Chuck Catto - **************** On Jan 6, 9:43am, "Ravender Goyal" wrote: > Subject: High freq effects in i/o mo > High freq effects in i/o modeling 9:07 AM 1/6/94 > Dear IBISers, > > I am starting this discussion to get your inputs on including the high > frequency effects (4- 5 GHz) in IBIS models. > As we know the signal integrity analysis accuracy depends as much on > accurately evaluating the electrical characterisitcs (characteristic > impedance, trace velocity, dispersion, to name a few) of interconnects, > as it depends on the accuracy of evaluating or specifying the > terminating impedances- i.e. the i/o models. > For EMI (Electromagnetic Interference) analysis, the frequency of > analysis is upto several GHz, as required by the FCC, European FCC etc. > guidelines. Hence, for EMI analysis upto what ever frequency of > interest, it is critical to have i/o model that is valid at that > frequency, else results from EMI analysis could be grossly inaccurate. > In order to include the high frequency effects, it is general > impression (as I have heard in the past) that one may have to give up > the proprietary information about the process. However, just for > accurate impedance presentation, that may not be necessary. To give an > example: > 1- Today the i/o model is represented as follows: > > | Vcc/ Vdd/ etc. > ____|____ > | B | > | L | > | A | > input o--------| C |---------o output > | K | | > | | | > | BOX | === pin > capacitance > -------------------- | > | | > Ground > The black box today is an i/v curve which results in a real impedance > only. The imaginary part of the impedance is contributed by the pin > parasitics only. We all know that the semiconductor devices have > capcitance that will also contribute to the imaginary part of the > impedance. > 2- At higher frequencies (5- 6 GHz), the device capacitances can be > accounted for, as a first order approximation, as follows: > > --------------- | Vcc/ Vdd/ etc. > | ____|____ > | | B | > == | L | > | | A | > input o--------| C |---------o output > | | K | | > | | | | > | | BOX | === pin > capacitance > == -------------------- | > | | | > ------------ Ground > > There may be another feedback capacitance from supply to ground. How > these capcitances can be estimated, or measured are to be addressed. > Also, what will be the optimum model to include the device > capacitances, needs to be discussed. > However, the primary question to address is, are these effects > important to take into account for signal integrity/ EMI analysis? > Secondly, is it within IBIS's charter to address such effects in the > models? > Thanks & look forward to hear from fellow IBISians...... > > > Ravender > > >-- End of excerpt from "Ravender Goyal" From ccm!Arpad_Muranyi@intelhf.intel.com Fri Jan 7 09:36:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10294; Fri, 7 Jan 94 09:36:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIL59-000MNeC; Fri, 7 Jan 94 09:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIL8Q-0000JPC; Fri, 7 Jan 94 09:38 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 09:38:06 PST Date: Fri, 7 Jan 94 09:38:06 PST From: Arpad Muranyi Message-Id: <940107093806_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through -good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From Ravender_Goyal@pdxml1.mentorg.com Fri Jan 7 09:57:19 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10389; Fri, 7 Jan 94 09:57:19 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA17028; Fri, 7 Jan 94 09:55:55 -0800 Received: from pdxml1.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13763; Fri, 7 Jan 94 09:55:53 -0800 Message-Id: <9401071755.AA13763@rainbow.mentorg.com> Date: 7 Jan 1994 09:59:32 -0800 From: "Ravender Goyal" Subject: Re: Hi frequency stuff To: "ravender goyal" Reply to: RE>>Hi frequency stuff I agree in the case of driver pin, the input- cap will be effective only if the predriver is defined as non- ideal source. However, for the driver pin the output capacitor (collector to emitter or drain to source) with- in the black box may be important. Also, how about the receiver pin, where the pin is driven by the interconnect impedance? In this case (receiver pin) the impedance match or mismatch between the interconnect and pin will be important and may not need to define preamplifier.... Thanks...... Ravender -------------------------------------- Date: 1/7/94 9:42 AM To: Ravender Goyal From: Arpad Muranyi Received: by pdxml2.mentorg.com with SMTP;7 Jan 1994 09:41:48 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13646; Fri, 7 Jan 94 09:39:32 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA16660; Fri, 7 Jan 94 09:39:29 -0800 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10294; Fri, 7 Jan 94 09:36:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIL59-000MNeC; Fri, 7 Jan 94 09:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIL8Q-0000JPC; Fri, 7 Jan 94 09:38 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 09:38:06 PST Date: Fri, 7 Jan 94 09:38:06 PST From: Arpad Muranyi Message-Id: <940107093806_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through -good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From bracken@valhalla.performance.com Fri Jan 7 10:17:05 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10544; Fri, 7 Jan 94 10:17:05 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA12192; Fri, 7 Jan 94 13:17:10 EST Message-Id: <9401071817.AA12192@valhalla.performance.com> To: ibis@vhdl.org Subject: Reference to Canright paper Date: Fri, 07 Jan 94 13:17:08 -0500 From: bracken@valhalla.performance.com Y'all, This may be the paper Bob Ward describes. Does anybody have this conference proceedings? --Eric **************************************************************** Author CANRIGHT, R.E., Jr.; Martin Marietta Missile Syst., Orlando, FL, USA Title Capacitance: relationships and measurements (for multiple conductors in VLSI packages and PWB) Source 1990 Proceedings. 40th Electronic Components and Technology Conference (Cat. No.90CH2893-6); Part: Las Vegas, NV, USA; Part: 20-23 May 1990; Sponsored by: IEEE; Electron. Ind. Assoc; New York, NY, USA; IEEE; 2 vol. xvi+1125 pp.; 1990 pp.; pp. 163-8 vol.1 pp. Abstract Three descriptions of capacitances for multiple conductors over a ground are discussed: the lumped-element capacitance, the two- terminal capacitance, and Maxwell's capacitance. Equations that completely interrelate the different descriptions of capacitance are presented. Experimental evidence supporting the two-terminal measurement technique is presented. AN example how the measurement can be applied to the VLSI package is given. It is also shown how networks of cross-coupled resistors can be measured Subject capacitance; capacitance measurement; conductors (electric); packaging; printed circuits; VLSI Keyword parasite capacitance; multiple conductors; lumped-element capacitance; two-terminal capacitance; Maxwell's capacitance; VLSI package; networks of cross-coupled resistors ClassCodes B2110; B0170J; B2570; B2210; B7310J Treatment theoretical/mathematical; experimental Language English RecordType Conference ControlNo. 3897358 AbstractNos. B91037970 References 6 U.S. Copyright Clearance Center Code 0569-5503/90/0000-0163$01.00 Country Pub. USA date 1170 **************************************************************** From bracken@valhalla.performance.com Fri Jan 7 10:50:44 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11051; Fri, 7 Jan 94 10:50:44 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA12235; Fri, 7 Jan 94 13:49:26 EST Message-Id: <9401071849.AA12235@valhalla.performance.com> To: Arpad Muranyi Cc: ibis@vhdl.org Subject: Re: 3D, or I/V/T models Date: Fri, 07 Jan 94 13:49:18 -0500 From: bracken@valhalla.performance.com Arpad, One thing about 3-D models that I still don't understand: When you run tests of the 3-D models in HSPICE, I presume that you replace the actual gate (transistors, etc.) with something else. What is that "something else"? --Eric From ccm!Arpad_Muranyi@intelhf.intel.com Fri Jan 7 11:26:09 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11319; Fri, 7 Jan 94 11:26:09 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIMnc-000MO1C; Fri, 7 Jan 94 11:24 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIMqu-0000IwC; Fri, 7 Jan 94 11:28 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 11:28:08 PST Date: Fri, 7 Jan 94 11:28:08 PST From: Arpad Muranyi Message-Id: <940107112808_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re[2]: Hi frequency stuff Dear Ravender (and all IBISers), I am not sure if I don't understand what you are talking about or whether you missed something in the IBIS spec. Currently, we have C_comp and C_pkg defined in IBIS. Schematically it can be drawn like this: +------+ | | |Buffer|------+--L_pkg----R_pkg--+--o Output | | | | +------+ ===C_comp ===C_pkg | | GND GND This picture can be mirrored for an input structure. What you describe below as Collector to Emitter (or Source to Drain) capacitance looks to me as C_comp and C_pkg is there for the (lumped) packaging capacitance. I think what you are asking for is already there. Arpad Muranyi Intel Corporation Folsom, CA Reply to: RE>>Hi frequency stuff I agree in the case of driver pin, the input- cap will be effective only if the predriver is defined as non- ideal source. However, for the driver pin the output capacitor (collector to emitter or drain to source) with- in the black box may be important. Also, how about the receiver pin, where the pin is driven by the interconnect impedance? In this case (receiver pin) the impedance match or mismatch between the interconnect and pin will be important and may not need to define preamplifier.... Thanks...... Ravender -------------------------------------- Date: 1/7/94 9:42 AM To: Ravender Goyal From: Arpad Muranyi Received: by pdxml2.mentorg.com with SMTP;7 Jan 1994 09:41:48 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13646; Fri, 7 Jan 94 09:39:32 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA16660; Fri, 7 Jan 94 09:39:29 -0800 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10294; Fri, 7 Jan 94 09:36:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIL59-000MNeC; Fri, 7 Jan 94 09:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIL8Q-0000JPC; Fri, 7 Jan 94 09:38 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 09:38:06 PST Date: Fri, 7 Jan 94 09:38:06 PST From: Arpad Muranyi Message-Id: <940107093806_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through -good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From bracken@valhalla.performance.com Fri Jan 7 14:38:00 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14201; Fri, 7 Jan 94 14:38:00 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA12756; Fri, 7 Jan 94 17:38:07 EST Message-Id: <9401072238.AA12756@valhalla.performance.com> To: ibis@vhdl.org Subject: High frequency stuff In-Reply-To: Your message of "Fri, 07 Jan 94 11:28:08 PST." <940107112808_3@ccm.hf.intel.com> Date: Fri, 07 Jan 94 17:38:06 -0500 From: bracken@valhalla.performance.com Here are a few thoughts. Say we have: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | B | | O | |_____X_____| | | | | o Ground (Vss, Vee, etc.) I think we could identify several potential issues for discussion here: 1) Assuming that the "insides" of this black box respond INSTANTANEOUSLY to changes at the terminals, is the set of caps currently in the IBIS model sufficient for modelling the AC behavior of the four-terminal device shown above? (Answer: No. To be *rigorous*, you need 4 self-capacitances and 6 coupling capacitances connected between every pair of terminals.) The question in my mind is whether we need this level of detail for DIGITAL circuits... It could certainly be important for ANALOG microwave circuits, but I don't think IBIS is quite "ready for prime time" there. Naturally there could also be inductances in series with every lead, with mutual inductances coupling every pair. 2) Presumably the black box is really NONlinear--the capacitance values depend upon the operating point. What can we do in this case? Provide a table of C-V data points? What do you do with these in a simulation? And how are they measured? 3) If the "guts" of the black box have significant "memory" and DON'T respond instantaneously when we wiggle the terminal voltages, what can we do? You can talk about "small-signal" impedances and admittances, but these are only valid about a quiescent DC operating point--not when the device is slewing rapidly through different regions of operation. And it's even scarier to think about how to use these in a nonlinear large-signal simulation. (Note that this case includes the "feedback" situation that we've recently been discussing in the forum.) Much of this smells like university research to me...but perhaps we can conquer it? --Eric From ccm!Arpad_Muranyi@intelhf.intel.com Fri Jan 7 14:52:10 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14296; Fri, 7 Jan 94 14:52:10 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIQ0z-000MOaC; Fri, 7 Jan 94 14:50 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIQ4I-00006iC; Fri, 7 Jan 94 14:54 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 14:54:10 PST Date: Fri, 7 Jan 94 14:54:10 PST From: Arpad Muranyi Message-Id: <940107145410_7@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Dear Ravender (and all IBISers), I am not sure if I don't understand what you are talking about or whether you missed something in the IBIS spec. Currently, we have C_comp and C_pkg defined in IBIS. Schematically it can be drawn like this: +------+ | | |Buffer|------+--L_pkg----R_pkg--+--o Output | | | | +------+ ===C_comp ===C_pkg | | GND GND This picture can be mirrored for an input structure. What you describe below as Collector to Emitter (or Source to Drain) capacitance looks to me as C_comp and C_pkg is there for the (lumped) packaging capacitance. I think what you are asking for is already there. Arpad Muranyi Intel Corporation Folsom, CA Reply to: RE>>Hi frequency stuff I agree in the case of driver pin, the input- cap will be effective only if the predriver is defined as non- ideal source. However, for the driver pin the output capacitor (collector to emitter or drain to source) with- in the black box may be important. Also, how about the receiver pin, where the pin is driven by the interconnect impedance? In this case (receiver pin) the impedance match or mismatch between the interconnect and pin will be important and may not need to define preamplifier.... Thanks...... Ravender -------------------------------------- Date: 1/7/94 9:42 AM To: Ravender Goyal From: Arpad Muranyi Received: by pdxml2.mentorg.com with SMTP;7 Jan 1994 09:41:48 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13646; Fri, 7 Jan 94 09:39:32 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA16660; Fri, 7 Jan 94 09:39:29 -0800 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10294; Fri, 7 Jan 94 09:36:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIL59-000MNeC; Fri, 7 Jan 94 09:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIL8Q-0000JPC; Fri, 7 Jan 94 09:38 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 09:38:06 PST Date: Fri, 7 Jan 94 09:38:06 PST From: Arpad Muranyi Message-Id: <940107093806_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through -good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - - - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From ccm!Arpad_Muranyi@intelhf.intel.com Fri Jan 7 15:16:17 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14481; Fri, 7 Jan 94 15:16:17 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIQOO-000MOoC; Fri, 7 Jan 94 15:14 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIQRh-00006iC; Fri, 7 Jan 94 15:18 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 15:18:21 PST Date: Fri, 7 Jan 94 15:18:21 PST From: Arpad Muranyi Message-Id: <940107151821_10@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re[2]: 3D, or I/V/T models Eric, I could make a drawing, but it really is not much different from the present IBIS model. Here is what I did: I modified the ramp generator so that it became a stopwatch. (I mean, it gives elapsed time from the "event" (= threshold crossing). Then I added a multiplier element which uses the current vs. time table to scale the output current based on the time elapsed from the "event". There you have a 3-D model. If you need more info I would be glad to answer your questions. Arpad Arpad, It partially answers my question--I was wondering what the "replacement" circuit looked like. (How are the V,I,R,C elements hooked up?) Would there be diagrams for any of this in the materials from the Summit Meeting? --Eric From ccm!Arpad_Muranyi@intelhf.intel.com Fri Jan 7 15:19:14 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14484; Fri, 7 Jan 94 15:19:14 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIQRF-000MOgC; Fri, 7 Jan 94 15:17 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIQUZ-00002oC; Fri, 7 Jan 94 15:21 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 15:21:18 PST Date: Fri, 7 Jan 94 15:21:18 PST From: Arpad Muranyi Message-Id: <940107152118_10@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Returned mail: unknown mailer error 1 (Sorry for the duplicate, if you already got this one, but I am not sure if I sent it out correctly)... Dear Ravender (and all IBISers), I am not sure if I don't understand what you are talking about or whether you missed something in the IBIS spec. Currently, we have C_comp and C_pkg defined in IBIS. Schematically it can be drawn like this: +------+ | | |Buffer|------+--L_pkg----R_pkg--+--o Output | | | | +------+ ===C_comp ===C_pkg | | GND GND This picture can be mirrored for an input structure. What you describe below as Collector to Emitter (or Source to Drain) capacitance looks to me as C_comp and C_pkg is there for the (lumped) packaging capacitance. I think what you are asking for is already there. Arpad Muranyi Intel Corporation Folsom, CA Reply to: RE>>Hi frequency stuff I agree in the case of driver pin, the input- cap will be effective only if the predriver is defined as non- ideal source. However, for the driver pin the output capacitor (collector to emitter or drain to source) with- in the black box may be important. Also, how about the receiver pin, where the pin is driven by the interconnect impedance? In this case (receiver pin) the impedance match or mismatch between the interconnect and pin will be important and may not need to define preamplifier.... Thanks...... Ravender -------------------------------------- Date: 1/7/94 9:42 AM To: Ravender Goyal From: Arpad Muranyi Received: by pdxml2.mentorg.com with SMTP;7 Jan 1994 09:41:48 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13646; Fri, 7 Jan 94 09:39:32 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA16660; Fri, 7 Jan 94 09:39:29 -0800 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10294; Fri, 7 Jan 94 09:36:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIL59-000MNeC; Fri, 7 Jan 94 09:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIL8Q-0000JPC; Fri, 7 Jan 94 09:38 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 09:38:06 PST Date: Fri, 7 Jan 94 09:38:06 PST From: Arpad Muranyi Message-Id: <940107093806_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through -good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - - - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From bob@icx.com Sat Jan 8 18:48:51 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29202; Sat, 8 Jan 94 18:48:51 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18618 for ; Sat, 8 Jan 94 21:41:25 -0500 Date: Sat, 8 Jan 94 18:25:04 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03925; Sat, 8 Jan 94 18:25:04 PST Message-Id: <9401090225.AA03925@icx.com> To: ibis@vhdl.org Subject: IBIS Support Greetings: In response to Will Hobb's question about EDA Vendor support at the 1/7/94 Forum, the Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. I am very concerned about the completeness of Release 2.0 and therefore will be raising (or reminding us of) a number of issues concerning clarifications and possible enhancements. Bob Ross From ravender_goyal@eurogw1.mentorg.com Mon Jan 10 10:34:13 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22238; Mon, 10 Jan 94 10:34:13 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA15913; Mon, 10 Jan 94 10:32:47 -0800 Received: from holland.ebv.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA26043; Mon, 10 Jan 94 10:32:39 -0800 Message-Id: <9401101832.AA26043@rainbow.mentorg.com> Received: from [137.202.64.101] by holland.ebv.mentorg.com with SMTP (1.37.109.8/15.6) id AA20872; Mon, 10 Jan 1994 19:32:26 +0100 Date: 10 Jan 94 10:31:37 U From: "Ravender Goyal" Subject: Re: High frequency stuff To: bracken@valhalla.performance.com, ibis@vhdl.org Reply to: RE>High frequency stuff Before we get into the technical details of it, I believe the bottom line question to ask is- does IBIS model address the EMI simulation and analysis requirements. If the answer is no, then we are ok with the present model. if the answer is yes then does anyone (who knows the FCC EMI guidelines in USA, Europe and Japan) believe that we are ok with the present model? if the answer is that IBIS does not address EMI reqreuiments, but need to address that, then we need to get into the technical discussion, as to what it takes to make the model accurate to address EMI requirements. Whether it is 2 additional elements (which I believe, from my RF design background, may be enough to take the model to 2- 4 GHz), 6 elements or 20 elements. I am not sure if the complexity of model should deter to handle the requirements. So bottom line is does IBIS models address EMI requirements accurately? Ravender -------------------------------------- Date: 1/7/94 11:48 PM To: Ravender Goyal From: bracken@valhalla.performance.c Received: by eurogw1.mentorg.com (2.01/Mail*Link(r) SMTP); 7 Jan 94 23:47:55 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA16056; Fri, 7 Jan 94 14:42:02 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA23529; Fri, 7 Jan 94 14:41:58 -0800 Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14201; Fri, 7 Jan 94 14:38:00 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA12756; Fri, 7 Jan 94 17:38:07 EST Message-Id: <9401072238.AA12756@valhalla.performance.com> To: ibis@vhdl.org Subject: High frequency stuff In-Reply-To: Your message of "Fri, 07 Jan 94 11:28:08 PST." <940107112808_3@ccm.hf.intel.com> Date: Fri, 07 Jan 94 17:38:06 -0500 From: bracken@valhalla.performance.com Here are a few thoughts. Say we have: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | B | | O | |_____X_____| | | | | o Ground (Vss, Vee, etc.) I think we could identify several potential issues for discussion here: 1) Assuming that the "insides" of this black box respond INSTANTANEOUSLY to changes at the terminals, is the set of caps currently in the IBIS model sufficient for modelling the AC behavior of the four-terminal device shown above? (Answer: No. To be *rigorous*, you need 4 self-capacitances and 6 coupling capacitances connected between every pair of terminals.) The question in my mind is whether we need this level of detail for DIGITAL circuits... It could certainly be important for ANALOG microwave circuits, but I don't think IBIS is quite "ready for prime time" there. Naturally there could also be inductances in series with every lead, with mutual inductances coupling every pair. 2) Presumably the black box is really NONlinear--the capacitance values depend upon the operating point. What can we do in this case? Provide a table of C-V data points? What do you do with these in a simulation? And how are they measured? 3) If the "guts" of the black box have significant "memory" and DON'T respond instantaneously when we wiggle the terminal voltages, what can we do? You can talk about "small-signal" impedances and admittances, but these are only valid about a quiescent DC operating point--not when the device is slewing rapidly through different regions of operation. And it's even scarier to think about how to use these in a nonlinear large-signal simulation. (Note that this case includes the "feedback" situation that we've recently been discussing in the forum.) Much of this smells like university research to me...but perhaps we can conquer it? --Eric From ccm!Arpad_Muranyi@intelhf.intel.com Mon Jan 10 10:37:32 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22257; Mon, 10 Jan 94 10:37:32 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pJRTG-000MO8C; Mon, 10 Jan 94 10:36 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pJQeq-0000SGC; Mon, 10 Jan 94 09:44 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 10 Jan 94 09:44:04 PST Date: Mon, 10 Jan 94 09:44:04 PST From: Arpad Muranyi Message-Id: <940110094404_48@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Testing for returned mail problem This is just a test message. My mail kept coming back to me as returned mail. I just want to see if this goes through. Thanks for ignoring this... Arpad From ccm!Arpad_Muranyi@intelhf.intel.com Mon Jan 10 10:37:15 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22251; Mon, 10 Jan 94 10:37:15 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pJRSy-000MOFC; Mon, 10 Jan 94 10:35 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pJQed-00013JC; Mon, 10 Jan 94 09:43 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 10 Jan 94 09:43:51 PST Date: Mon, 10 Jan 94 09:43:51 PST From: Arpad Muranyi Message-Id: <940110094351_43@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Hi frequency stuff (try again) (Sorry for the duplicate if you already got this one, but it keeps coming back to me as returned mail...) Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From ccm!Arpad_Muranyi@intelhf.intel.com Mon Jan 10 10:37:26 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22254; Mon, 10 Jan 94 10:37:26 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pJRT9-000MNtC; Mon, 10 Jan 94 10:36 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pJQen-0000crC; Mon, 10 Jan 94 09:44 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 10 Jan 94 09:44:00 PST Date: Mon, 10 Jan 94 09:44:00 PST From: Arpad Muranyi Message-Id: <940110094400_47@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Hi frequency stuff2 (try again) (Sorry for the duplicate if you already got this one, but it keeps coming back to me as returned mail...) Dear Ravender (and all IBISers), I am not sure if I don't understand what you are talking about or whether you missed something in the IBIS spec. Currently, we have C_comp and C_pkg defined in IBIS. Schematically it can be drawn like this: +------+ | | |Buffer|------+--L_pkg----R_pkg--+--o Output | | | | +------+ ===C_comp ===C_pkg | | GND GND This picture can be mirrored for an input structure. What you describe below as Collector to Emitter (or Source to Drain) capacitance looks to me as C_comp and C_pkg is there for the (lumped) packaging capacitance. I think what you are asking for is already there. Arpad Muranyi Intel Corporation Folsom, CA Reply to: RE>>Hi frequency stuff I agree in the case of driver pin, the input- cap will be effective only if the predriver is defined as non- ideal source. However, for the driver pin the output capacitor (collector to emitter or drain to source) with- in the black box may be important. Also, how about the receiver pin, where the pin is driven by the interconnect impedance? In this case (receiver pin) the impedance match or mismatch between the interconnect and pin will be important and may not need to define preamplifier.... Thanks...... Ravender -------------------------------------- Date: 1/7/94 9:42 AM To: Ravender Goyal From: Arpad Muranyi Received: by pdxml2.mentorg.com with SMTP;7 Jan 1994 09:41:48 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA13646; Fri, 7 Jan 94 09:39:32 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA16660; Fri, 7 Jan 94 09:39:29 -0800 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10294; Fri, 7 Jan 94 09:36:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pIL59-000MNeC; Fri, 7 Jan 94 09:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pIL8Q-0000JPC; Fri, 7 Jan 94 09:38 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 7 Jan 94 09:38:06 PST Date: Fri, 7 Jan 94 09:38:06 PST From: Arpad Muranyi Message-Id: <940107093806_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Hi frequency stuff Hi IBIS folks, To respond to this (Hi Frequency) issue, it seems to me that those capacitors on the input side of the "Black BOX" do nothing if the buffer is driven with an ideal source (zero impedance). This might be the case in some IBIS implementations. Those capacitors will have a correct effect only if the predriver is modeled correctly. Are we ready to add more V/I curves to the IBIS standard to describe the predriver? Arpad Muranyi Intel Corporation Folsom, CA Sorry, in my last message, it seems that the figures did not come through -good. Let me make another attempt here. Ravender ------------------------------------------------------------------------------ - - - - -- I am starting this discussion to get your inputs on including the high frequency effects (4- 5 GHz) in IBIS models. As we know the signal integrity analysis accuracy depends as much on accurately evaluating the electrical characterisitcs (characteristic impedance, trace velocity, dispersion, to name a few) of interconnects, as it depends on the accuracy of evaluating or specifying the terminating impedances- i.e. the i/o models. For EMI (Electromagnetic Interference) analysis, the frequency of analysis is upto several GHz, as required by the FCC, European FCC etc. guidelines. Hence, for EMI analysis upto what ever frequency of interest, it is critical to have i/o model that is valid at that frequency, else results from EMI analysis could be grossly inaccurate. In order to include the high frequency effects, it is general impression (as I have heard in the past) that one may have to give up the proprietary information about the process. However, just for accurate impedance presentation, that may not be necessary. To give an example: 1- Today the i/o model is represented as follows: o Vcc/ Vdd etc. | | | _____|_____ | B | | L | | A | | C | o-------| K |------o output input | | | | B | | | O | | |_____X_____| === pin capacitance | | | | |----------- | o Ground The black box today is an i/v curve which results in a real impedance only. The imaginary part of the impedance is contributed by the pin parasitics only. We all know that the semiconductor devices have capcitance that will also contribute to the imaginary part of the impedance. 2- At higher frequencies (5- 6 GHz), the device capacitances can be accounted for, as a first order approximation, as follows: o Vcc/ Vdd etc. | ----------| | | | _____|_____ | | B | === | L | | | A | | | C | o-------| K |------o output input | | | | | | B | | | | O | | | |_____X_____| === pin capacitance === | | | | | ----------|----------- | o Ground There may be another feedback capacitance from supply to ground. How these capcitances can be estimated, or measured are to be addressed. Also, what will be the optimum model to include the device capacitances, needs to be discussed. However, the primary question to address is, are these effects important to take into account for signal integrity/ EMI analysis? Secondly, is it within IBIS's charter to address such effects in the models? Thanks & look forward to hear from fellow IBISians...... Ravender From 71436.1314@CompuServe.COM Tue Jan 11 20:16:09 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10556; Tue, 11 Jan 94 20:16:09 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id XAA27153; Tue, 11 Jan 1994 23:14:46 -0500 Date: 11 Jan 94 23:10:33 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Do IBIS models support EMI simulations? Message-Id: <940112041032_71436.1314_BHU37-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx I believe that IBIS models will work for first order EMI simulations. The best indications that I have seen are when comparing the EMI profiles from a real system that has had the transmission lines terminated and the same system without termination, there can easily be more than 10 db of difference. From Ravender_Goyal@pdxml1.mentorg.com Wed Jan 12 09:02:05 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19551; Wed, 12 Jan 94 09:02:05 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA20856; Wed, 12 Jan 94 09:00:19 -0800 Received: from pdxml1.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA14042; Wed, 12 Jan 94 09:00:18 -0800 Message-Id: <9401121700.AA14042@rainbow.mentorg.com> Date: 12 Jan 1994 09:02:58 -0800 From: "Ravender Goyal" Subject: Re: Do IBIS models support E To: "ravender goyal" , "Kellee Crisafulli" <71436.1314@CompuServe.COM> Reply to: RE>Do IBIS models support EMI 10 db of difference at what frequency? One has to specify the freq when you talk about the radiated power. I will have hard time to believe that it was 10 db of difference from dc to optical freq. Yes, the dc model will work as a first order approximation, (ofcourse, dc model is the primary requirement to represent a device), but will not have anywhere close to accurate radiation power AS A FUNCTION OF FREQ. Kelle has brought a very good point, as one uses the appropriate terminations and accounts for signal integrity issues, EMI will be less compared to when signal integrity issues are not accounted for. Unterminated Xlines, open eneded Xlines- long stubs etc., discontinuties- all act as antenna at one freq. or the other. However, that gives a feel of comfort, not the quantitative measure of how much less radiations. In the present model we are considering for IBIS with dc IV characterisitcs, intrinsic device (without package) will have the gain with respect to frequency from dc to optical freq.- if that is true, it means that when one calculates the ac currents through the interconnects, the only reason those ac currents will be different is due to the freq response of interconnects. As far active devices- i/o, they will have the same freq response at all the freqs. Well, an analogous situation is, if the i/o models do not change with voltage i.e. we use only linear model- will that be acceptable? Practical devices tend to have 3db gain bandwidth, which define their usefulness for a particular high speed or high frequency application. ECL bipolar devices may have 3db gain bandwidth in x00 MHz- x GHz range, state of the art bipolar devices have 3 db gain bandwidth in low 1x GHz range, MESFET devices have typical useful freq response to high 1x GHz, and HEMTs go upto xx GHz. If we model all devices with their IV models only and not worry about their freq response, we are assuming that intrinsic devices have same freq response (dc to infinity). In essence, given the same IV dc model for all devices (CMOS, ECL, BiCMOS, MESFET, HEMT)- for the sake of discussion), CMOS devices typically have lowest freq response, will not be able to sustain any signal above x00 MHz, so there will be minimal signal strength supported by the device at higher freqs, whereas if one is using MESFETs, the system may be able to support signals at much higher freqs and hence may have significant radiated power at higher freqs. Yes, the package parasitics will limit the freq response of the device, but in case one uses unpackaged device, devices will have freq response to infinite. Also, whether one puts an ECL- bipolar device or a MESFET device or for the sake of argument a HEMT device, all will have the same freq reponse (may have differences due to dc IV models, but freq response will be the same)- no effect on radiated power pattern as a function of freq as calculated by the EMI tool. Ravender -------------------------------------- Date: 1/11/94 8:20 PM To: Ravender Goyal From: Kellee Crisafulli Received: by pdxml2.mentorg.com with SMTP;11 Jan 1994 20:20:23 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA09661; Tue, 11 Jan 94 20:17:59 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA14462; Tue, 11 Jan 94 20:17:57 -0800 Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10556; Tue, 11 Jan 94 20:16:09 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id XAA27153; Tue, 11 Jan 1994 23:14:46 -0500 Date: 11 Jan 94 23:10:33 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Do IBIS models support EMI simulations? Message-Id: <940112041032_71436.1314_BHU37-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx I believe that IBIS models will work for first order EMI simulations. The best indications that I have seen are when comparing the EMI profiles from a real system that has had the transmission lines terminated and the same system without termination, there can easily be more than 10 db of difference. From ccm!Will_Hobbs@intelhf.intel.com Wed Jan 12 13:34:38 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22072; Wed, 12 Jan 94 13:34:38 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pKDBh-000MO2C; Wed, 12 Jan 94 13:33 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pKDFd-0000zKC; Wed, 12 Jan 94 13:37 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 12 Jan 94 13:37:17 PST Date: Wed, 12 Jan 94 13:37:17 PST From: Will Hobbs Message-Id: <940112133717_5@ccm.hf.intel.com> To: ibis@vhdl.org Subject: NEW BIRD, #6 Hello IBIS members: How can we specify components with differential pins? Some devices in the ECLinPS families such as the MC10E111, MC10E112, and MC10E116 have differential driver and receiver functionality. Examples for differential bidirectional operation include components such as the SN75117, SN75176A, and SN75LBC976 contained in the Data Transmission Circuits book from TI. A proposal in BIRD format is put on the table for discussion and refinement. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 6 ISSUE TITLE: Differential Pin Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 12 January 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Several components contain pins which operate in a differential mode with respect to other pins. Since this operation in inherent to a component, the IBIS document should be extended to specify this functionality. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: An additional optional keyword, [Diff_Pin], is added to the specification. |========================================================================== | Keyword: [Diff_Pin] | Required: Optional |Description: Used to associate differential pins and their peak-to-peak | differential voltages. | Sub-Params: inv_pin, vpp |Usage Rules: Entries follow these rules: Only differential pin pairs | are entered. The [Diff_pin] column contains a non-inverting | pin number and the inv_pin column always contains the | corresponding inverting pin number for output and I/O output. | The vpp column contains the specified peak-to-peak voltage | between pins if the pins are an Input or I/O Model_type. | When the input pins follow the polarity convention according | to the columns they are entered, the vpp value is positive. | However, a negative vpp value means that the input pins do | not follow the polarity convention, such as when the I/O | input polarity is opposite that for output operation. For | output only differential pins, the vpp entry is 0V. |Other Notes: The output pin polarity specification in the table takes | precedence over the [Model] Polarity specification such | that the pin in the [Diff_pin] column will be Non-Inverting | and the pin in the inv_pin column will be Inverting. One | [Model] is permitted for both pins. | | Column length limits are: | [Diff_Pin] 5 characters max | inv_pin 5 characters max | vpp 9 characters max | | [Model] Vinl and Vinh specifications are permitted since | some components contain this information even for differential | input pins. |--------------------------------------------------------------------------- [Diff_Pin] inv_pin vpp | 3 4 150mV | Input or I/O pin pair 8 9 0V | Output pin pair 14 15 -500mV | Input or I/O pin pair with input | polarity opposite of that shown ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. It is required only if the model itself must convey associations between pins for differential inputs and/or outputs. It is possible to provide methods external to a model to associate component pins by relating the attached networks. This may be the best method when some output pins are complementary. However, IBIS should handle pins designed for differential operation which contain specifications based on the associations between pins. Such components may contain a differential input sensitivity specification such as "Vpp" or "VT+" and "VT-" which define a peak to peak voltage between two input pins. Thus the vpp column is introduced. Furthermore a few components contain I/O pins where the output differential polarity is opposite that of the input (e.g., SN75117). The vpp polarity is used for such a case, but extended for consistency to cover any input pin pair. For timing purposes, an output is referenced to a zero volt cross-over value between two output pins. Setting the vpp entry to 0V is chosen to correspond to output differential voltage selections. The column lengths are consistent with the [Pin] keyword column lengths. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From huq@rockie.nsc.com Thu Jan 13 16:53:29 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10805; Thu, 13 Jan 94 16:53:29 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA02713 for ibis@vhdl.org; Thu, 13 Jan 94 16:52:05 -0800 Received: from [139.187.119.99] by nsc.nsc.com (5.65/1.34) with SMTP id AA14558 for ibis@vhdl.org; Thu, 13 Jan 94 16:52:03 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA07733; Thu, 13 Jan 94 15:49:20 PST Date: Thu, 13 Jan 94 15:49:19 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9401132349.AA07733@rockie.nsc.com> To: ibis@vhdl.org Subject: Differential Line testing Cc: huq@rockie.nsc.com Hi IBIS members: As a semiconductor product vendor, 90% of my devices are differential line drivers and differential line receivers. These fall under RS-422, RS-485, SCSI and LVDS standards. These products from National Semiconductor falls under the 'Data Transmission Products'. I am glad BIRD ID#6 has started to address Differential Lines. Regards, Syed Data Transmission Application National Semiconductor Corp. From Ravender_Goyal@pdxml1.mentorg.com Thu Jan 13 17:00:33 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10963; Thu, 13 Jan 94 17:00:33 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA17761; Thu, 13 Jan 94 16:59:08 -0800 Received: from pdxml1.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA29743; Thu, 13 Jan 94 16:59:06 -0800 Message-Id: <9401140059.AA29743@rainbow.mentorg.com> Date: 13 Jan 1994 17:02:57 -0800 From: "Ravender Goyal" Subject: Re: Do IBIS models support E To: "ravender goyal" Reply to: RE>Do IBIS models support EMI This mail came back to me, so I am resending it. Sorry if you are receiving it again.... Ravender ------------------------------------------------------------------ 10 db of difference at what frequency? One has to specify the freq when you talk about the radiated power. I will have hard time to believe that it was 10 db of difference from dc to optical freq. Yes, the dc model will work as a first order approximation, (ofcourse, dc model is the primary requirement to represent a device), but will not have anywhere close to accurate radiation power AS A FUNCTION OF FREQ. Kelle has brought a very good point, as one uses the appropriate terminations and accounts for signal integrity issues, EMI will be less compared to when signal integrity issues are not accounted for. Unterminated Xlines, open eneded Xlines- long stubs etc., discontinuties- all act as antenna at one freq. or the other. However, that gives a feel of comfort, not the quantitative measure of how much less radiations. In the present model we are considering for IBIS with dc IV characterisitcs, intrinsic device (without package) will have the gain with respect to frequency from dc to optical freq.- if that is true, it means that when one calculates the ac currents through the interconnects, the only reason those ac currents will be different is due to the freq response of interconnects. As far active devices- i/o, they will have the same freq response at all the freqs. Well, an analogous situation is, if the i/o models do not change with voltage i.e. we use only linear model- will that be acceptable? Practical devices tend to have 3db gain bandwidth, which define their usefulness for a particular high speed or high frequency application. ECL bipolar devices may have 3db gain bandwidth in x00 MHz- x GHz range, state of the art bipolar devices have 3 db gain bandwidth in low 1x GHz range, MESFET devices have typical useful freq response to high 1x GHz, and HEMTs go upto xx GHz. If we model all devices with their IV models only and not worry about their freq response, we are assuming that intrinsic devices have same freq response (dc to infinity). In essence, given the same IV dc model for all devices (CMOS, ECL, BiCMOS, MESFET, HEMT)- for the sake of discussion), CMOS devices typically have lowest freq response, will not be able to sustain any signal above x00 MHz, so there will be minimal signal strength supported by the device at higher freqs, whereas if one is using MESFETs, the system may be able to support signals at much higher freqs and hence may have significant radiated power at higher freqs. Yes, the package parasitics will limit the freq response of the device, but in case one uses unpackaged device, devices will have freq response to infinite. Also, whether one puts an ECL- bipolar device or a MESFET device or for the sake of argument a HEMT device, all will have the same freq reponse (may have differences due to dc IV models, but freq response will be the same)- no effect on radiated power pattern as a function of freq as calculated by the EMI tool. Ravender -------------------------------------- Date: 1/11/94 8:20 PM To: Ravender Goyal From: Kellee Crisafulli Received: by pdxml2.mentorg.com with SMTP;11 Jan 1994 20:20:23 U Received: from mgc.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA09661; Tue, 11 Jan 94 20:17:59 -0800 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA14462; Tue, 11 Jan 94 20:17:57 -0800 Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10556; Tue, 11 Jan 94 20:16:09 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id XAA27153; Tue, 11 Jan 1994 23:14:46 -0500 Date: 11 Jan 94 23:10:33 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Do IBIS models support EMI simulations? Message-Id: <940112041032_71436.1314_BHU37-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx I believe that IBIS models will work for first order EMI simulations. The best indications that I have seen are when comparing the EMI profiles from a real system that has had the transmission lines terminated and the same system without termination, there can easily be more than 10 db of difference. From ccm!Derrick_Duehren@intelhf.intel.com Fri Jan 14 15:20:39 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25098; Fri, 14 Jan 94 15:20:39 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pKxnE-000MOsC; Fri, 14 Jan 94 15:19 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pKxrQ-0000SKC; Fri, 14 Jan 94 15:23 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 14 Jan 94 15:23:24 PST Date: Fri, 14 Jan 94 15:23:24 PST From: Derrick Duehren Message-Id: <940114152324_8@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS 1/7/94 Meeting Minutes Text item: Text_1 Date: January 14, 1994 From: Derrick Duehren (503) 696-4299, fax (503) 696-4904 Third Party Vendor Program Manager Xceleration Tools Group (Will Hobb's IBIS Assistant) Intel Corporation Hillsboro, Oregon and Will Hobbs (503) 696-4369, fax (503) 696-4210 Intel Modeling Manager Subject: Minutes from IBIS Open Forum 1/7/94 To: Anacad Petra Osterman AnSoft Henri Maramis* Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski*, Kumar* Contec Maah Sango*, Dermott Lynch, Clark Cochran High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd*, David Wiens* IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal* Meta-Software Stephen Fenstermaker, Mei Wong* MicroSim Arthur Wong, Jerry Brown, Graham Bell North Carolina State U. Paul Franzon, Michael Steer Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell* Quantic Labs Mike Ventham, Zhen Mu Siemens Nixdorf Werner Rissiek, Ulas Rethneier* Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl, Samie Samaan,Tay Wu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the 1/7/94 meeting are indicated by * Next Meeting: January 28, 1994, 8:15 AM to 10:00 PST. *PLEASE NOTE THE The Phone number, reservation number, and NEW TIME* agenda will be sent out in the week of Jan. 17. Please note: If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), or have updates to your e-mail address, e-mail to ibis-request@vhdl.org. -------------------------------------------------------------------------- Meeting Agenda -------------- In keeping with the wishes of various participants, Will has arranged the order to keep technical discussions later so that those who wish to leave early may do so. 9:00 Check-in 9:05 Introductions of new IBIS members 9:10 12/3 Summit Minutes Review Opens for New Issues 9:15 Another IBIS Press Release Hobbs Enlisting new IC Vendors Forms of EDA support of IBIS Hobbs 9:30 BIRD 5.2, Pin Mapping Bracken EGG 1, mutual pin coupling Bracken 10:00 80 Column restriction? Non-intrusive pkg param extraction Ward Formal BNF notation Reed, Harr VIH, VIL Thresholds for Inputs, BIRD 2 Powell Spice to IBIS Converter 10:30 IBIS 2.0 Goals Hobbs 3D Modeling Muranyi New model_types (r-packs, etc.) Modeling Feedback Hobbs, Peters 10:45 Phased turn-on/off of multiple devices Powell Open Side Devices Crisafulli Other Updates (U of NC, DIE, etc.) All 10:55 Wrap-up, Next Meeting Plans Minutes ------- 1. New members, 11/12 Minutes review, Open time for new issues: There were no new members to announce and no corrections were made to last month's minutes. FYI, Paul Munsey was finally been paid by all the vendors who contracted him to do the IBIS parser. A/R: Everyone. Please use spaces instead of tabs in email. Tabs do not display well for some recipients. 2. Another IBIS Press Release Will Hobbs and Derrick Duehren are working on Intel-driven press release. No results yet. There have been several articles featuring IBIS. The most significant was 12/8/93 EDN article which named IBIS as one of the hot 100 products of 1993. A half-page feature article on IBIS appeared in the 12/16/93 Electronic Design magazine(Pg. 36). There was some concern that this was a Cadence announcement, not an IBIS open-forum announcement. Inquiries were to be directed to Karen Kirkpatrick at Cadence. The consensus of the forum is that this is acceptable as long as Cadence shares customer IBIS inquiries with IBIS members. Pawel Chadzynski joined the meeting to tell us that they had received only two inquiries from the article. A Cadence press release was printed in EDN 11/25/93, IBIS was mentioned. A Japanese-language magazine printed an article featuring IBIS (one paragraph in Technology News, a Nikkei Electronics publication). Cadence and Mentor tools are discussed with Pentium(TM) processor models from Intel and PowerPC models from Motorola/IBM. A/R: Kumar to get IBIS contact clarified from Cadence. Cadence needs to pass on customer inquiries, esp. semiconductor vendors, from the EDN article to other IBIS companies. The IBIS Overview doc is in vhdl.org and available through FaxBack through Intel customer Support. Past IBIS minutes are also on vhdl.org. A/R: Derrick Duehren convert it to RTF and submit. 3. Enlisting new IC Vendors Jon Powell is talking to National Semiconductor. He is working with them to get models in IBIS format. Jon is planning to assist Motorola in creating IBIS models for the PowerPC next month. Will Hobbs read off the list of companies that requested IBIS information since the last meeting. 17 total, including 10 IC vendors: AT&T Cypress Thompson SCF Unicad (Bell Northern) IBM Motorola Micron National Semiconductor Sun Network Systems Thomatronik Rambus Texas Instruments Tandem Computers EMC corp. Loral Federal Systems (Radhard - space exploration) Someone said they would follow up with Cypress. (Kellee?) Bob Ward wanted to know who at TI requested the IBIS information. A/R: Will Hobbs to get the name to Bob. Done 4. Forms of EDA support of IBIS As of 1/7, Kellee was the only respondent so far to the request in last month's minutes. Will is still soliciting your descriptions of how each simulator vendor supports IBIS, which I will pass on to customers and the IBIS Open Forum, if you wish. Update: Since the meeting, we have received input from Intusoft and Interconnectix. Interconnectix: Bob Ross says that the Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. Intusoft: Charles Hymowitz says that Intusoft takes a customer's netlist or model and translates it into a spice model, free of charge. They have the golden parser source but haven't, as of yet, automated the process. They're waiting until there are more IBIS models available. A/R: Derrick to send separate email request. 5. BIRD 5.2, Pin Mapping for Ground Bounce Simulation After a flurry of reflector discussion on this BIRD in early December, the email discussion died down in the last few weeks. Eric Bracken gave a summary of the major issues of the BIRD and the differences between 5.0, 5.1, and 5.2. After a short discussion, attendees agreed that all issues had been ironed out on reflector. Upon vote, it was unanimously approved. 6. Egg 1, mutual pin coupling Technical discussion of this Egg in IBIS 2.0 ensued. EGG 1 (Eric Bracken coined the term, reasoning that an EGG precedes a BIRD, so an early discussion that may lead to a BIRD should be called an EGG) dealt with mutual coupling between signals in the package. Although orthogonal to the pin mapping question (BIRD 5.2), it is related. Eric's suggestion is to add an optional keyword and table to IBIS that specifies mutual coupling. Quoting the original mail from Eric: [Mutuals] Pin1 Pin2 Rmut Lmut Cmut 1 2 1e-3 1n 1p 1 3 1e-4 0.1n 0.1p Columns "Pin1" and "Pin2" contain numbers of pins which are coupled together; the Rmut, etc. columns specify the values of the couplings. Not every coupling must be specified (in the interest of sparsity); you can assume that the self-inductances have been specified in the [Pin] section (talk about backward compatibility!) And it all fits into 80 characters. Chris Reed of Cadence has offered to write a BIRD on mutuals. In the meantime, we will continue this discussion on reflector. 7. IBIS 2.0 Goals When is the right time to close on IBIS V2.0? Concern was expressed that 1.1 does not support ECL, whereas 2.0 will support ECL, a fairly pressing need, which could drive us to early closure on 2.0. We need to get more semiconductor vendors on board first. The fear is that a new major revision to IBIS will scare off new semiconductor vendors, who might perceive that IBIS is an unstable moving target. (Of course, we understand our commitment to backward compatibility and the fact that IBIS as it currently stands is highly functional.) Jon Powell proposed that we releasing 2.0 when 10 semiconductor vendors come on board or in June, 1994, whichever occurs first. (A semiconductor vendor on board is defined as 'people who say they are developing models'). Several people volunteered to help vendors write there first models. This plan was agreed to and is now the plan of record. 8. 80 Column restriction? The arguments for staying within 80 columns (too many VGA users, email concerns, printers that truncate long lines rather than wrap, potential for errors in models when part of the data may be off the edge of the screen) outweighed those for using longer line lengths. Consensus is that 80-columns is a better common denominator. General agreement to use 80-col. until a specific insurmountable issue arises that forces us beyond 80 characters per line. 9. Non-intrusive package parameter extraction Bob Ward summarized two papers discussing slow-speed, non-intrusive extraction methods based on TDR (Time Domain Reflectometry). An engineer at TI produced a paper discussing immersion of components in ultra-pure de-ionized water. Pure water is non-conductive, but has a very dielectric constant (~38), slowing down the signals so they can be measured. The measurements have to be taken very quickly because the de-ionized water quickly becomes contaminated by the component and the container. Bob Canright of Convex did a paper on a related subject. A/R: Bob Ward put both papers on reflector (with given permissions). Bob may also conduct some of his own tests. Will Hobbs mentioned that at the Summit, Jon Powell talked about creating AC V/I curves. Jon said this idea didn't apply to non-intrusive package parameter extraction because the method is used to infer package parameters when customers already know full buffer characteristics. The ones who are in a position to apply this method already have access to this information. 10. Formal BNF notation We needed Randy Harr and Chris Reed for this discussion. They were not in the meeting. Bob Ward summarized that lex (scan) and yacc (parse) UNIX utilities can be used to parse IBIS files if a formal BNF exists for IBIS. Randy has done a preliminary BNF for IBIS, but it needs to be completed. We will continue this discussion over the reflector. 11. VIH, VIL Thresholds for Inputs, BIRD 2 Jon is in crunch mode for a major release. He won't be able to address this issue until the end of the month, at which time he will put together BIRD 2 and post it. 12. Spice to IBIS Converter We need someone to do this converter development. U of NC is reportedly doing this work under their ARPA (Gov't) funding. This triggered discussion about analog simulation (Spice). We need conversions from any analog simulator, which would require a standard format for the output, such as V/I pairs. There is also the problem that some simulators just generate wave forms, not tabular data. Quad Design has a utility that converts ASCII V/T V/I data into Quad design models successfully. Theoretically, the utility could also generate IBIS models. We discussed the need for a cookbook on how to generate and validate the IBIS data properly. This is where guidance is badly needed, specifications are needed. A cookbook is in process for use within Intel. The cookbook discusses how to generate data from both simulation and measurement, and how to validate the models. Although the document contains Intel proprietary information, large sections could be used publicly. Will Hobbs has major sections in process, but they won't be ready for at least a month. We took a $5K SWAG at contractor-writer effort to complete the cookbook. Jon Powell proposed checking within organizations to see if funding is available. Many requested to be in the review cycle before publishing. A/R: Derrick to do cost estimate for the next meeting. 13. Dues? The discussion on hiring a technical writer triggered a discussion on how to fund such an effort. Do we need an annual dues? Some ideas were tossed about: Voting members pay dues? Cost figured by # of employees? Corp./individual memberships? Free for Universities? The discussion was tabled. We will continue the discussion on reflector and in the next meeting. A/R: Each person to talk with their management/finance people about funding/dues/comfortable contribution levels. 14. 3D Modeling Arpad Muranyi had hoped to issues a BIRD on this subject but hasn't gotten to it yet. He did, however, initiate a discussion on the topic. Can we make an assumption that each I/V/T curve is a scaleable curve? In Arpad's present 3D modeling approach, there are two current curves and four time-related curves, six curves total. A scaling function is used to interpolate between the 2D curves to generate the surface (family of V/T curves). Arpad has done some work with this and gotten good results with simple devices. We felt that this simple approach will probably work for standard CMOS, but will likely fall apart for bi-polar devices. Bob Ward said TI has experience with extremely short channel lengths and are seeing unexpected results, so simple CMOS scaling may fall apart under these conditions. We recognized that a fair amount of R&D is required to further understand this issue. This could be a great opportunity to get a University involved. Simple scaling may be sufficient for now. A/R: Cadence, Intel, and a third company (Quad Design ?) [sorry, my notes are unclear. I was prying my laptop open with my Swiss army knife during this discussion...] volunteered to work to get someone from the U of NC to participate in these Open Forums. Can they do some of this work? 15. New model_types (r-packs, etc.) When are input thresholds mandatory and when not? Jon had previously brought this up and offered to roll it into BIRD 2.1 as soon as he gets off his release crunch. 16. Modeling Feedback No worthy feedback yet. Both TI and Intel have a stake in this but can't share the data because of real-world propriety issues. 17. Phased turn-on/off of multiple devices Jon will address this following his BIRD 2.1 work. He will propose including it in 2.1. He should be able to get to this in March. 18. Open Side Devices No discussion. Kellee had left the meeting before this topic was addressed. 19. Other Updates (U of NC, DIE, etc.) Regarding Ravender's mail on extremely high frequencies, much reflector activity is currently underway on this topic. Will Hobbs pointed out that frequency dependence is a significant layout issue. Transmission lines have a built-in frequency-dependent impedance due to skin effect. Will said that some Intel engineers had been struggling with this and felt that current simulation tools didn't handle this. There was general disagreement among attendees about this. Jon Powell said "Look up "skin effect" in the manual. Most felt that this is a non issue. There is still an open issue of package parameters. Is it time to go to transmission line representation? This issue needs further study. 20. Wrap-up, Next Meeting Plans New business: The group agreed to move the meeting time to 8:15 am to 10:00 am. PMT Next meeting: 1/28/94 From ccm!Derrick_Duehren@intelhf.intel.com Fri Jan 14 18:42:14 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26291; Fri, 14 Jan 94 18:42:14 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pL0wO-000MNtC; Fri, 14 Jan 94 18:40 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pL10b-0000OTC; Fri, 14 Jan 94 18:45 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 14 Jan 94 18:45:05 PST Date: Fri, 14 Jan 94 18:45:05 PST From: Derrick Duehren Message-Id: <940114184505_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: How does your company support IBIS? Text item: Text_1 Date: January 14, 1994 From: Derrick Duehren (503) 696-4299, fax (503) 696-4904 Email: Derrick_Duehren@ccm.hf.intel.com Third Party Vendor Program Manager Xceleration Tools Group (Will Hobb's IBIS Assistant) Intel Corporation Subject: Request for Support Information To: Anacad Petra Osterman AnSoft Henri Maramis* Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski*, Kumar* Contec Maah Sango*, Dermott Lynch, Clark Cochran High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd*, David Wiens* IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal* Meta-Software Stephen Fenstermaker, Mei Wong* MicroSim Arthur Wong, Jerry Brown, Graham Bell North Carolina State U. Paul Franzon, Michael Steer Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell* Quantic Labs Mike Ventham, Zhen Mu Siemens Nixdorf Werner Rissiek, Ulas Rethneier* Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl, Samie Samaan,Tay Wu -------------------------------------------------------------------------- How Does Your Company Support IBIS? Will Hobbs and I are gathering input to make a list of how the member companies support IBIS. Some vendors have created a product-specific IBIS-to-their model converter, others accept native IBIS models, still others may have written application notes describing how to use IBIS data in their simulators. Will asked for descriptions from everyone on how their company supports IBIS. This information will be given to our field sales and applications engineers and marketing folks so we can answer customer questions. He also stated that if someone did not want to make their information publicly available, we would still like the information and would protect the information. Please describe how you support IBIS (converter, application note, native IBIS models, etc.). Send this information to Derrick Duehren, Derrick_Duehren@ccm.hf.intel.com. I will compile the information, and make it available to the IBIS Open Forum, excluding that information which the vendors do not wish to share publicly. To date, I have the following input from HyperLynx, Interconnectix, and Intusoft: o IBIS support by Linesim Pro from HyperLynx: 1) Any IBIS file can be used directly as a 'NATIVE' file by Linesim Pro Version 3.0 or newer. 2) A single model in an IBIS file can selected, loaded and viewed directly by LineSim Pro. 3) Several IBIS models can be included in a single file and used as a library. Note: this library file still complies completely with the IBIS specification and can be checked with the IBIS check program. o Interconnectix: Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. o Intusoft: Takes a customer's netlist or model and translates it into a spice model, free of charge. They have the golden parser source but haven't, as of yet, automated the process. They're waiting until there are more IBIS models available. From ccm!Charles_A_Anyimi@intelhf.intel.com Mon Jan 17 18:12:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04635; Mon, 17 Jan 94 18:12:05 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pM5tq-000MOAC; Mon, 17 Jan 94 18:10 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pM5yR-0000VnC; Mon, 17 Jan 94 18:15 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 17 Jan 94 18:15:19 PST Date: Mon, 17 Jan 94 18:15:19 PST From: Charles A Anyimi Message-Id: <940117181519_7@ccm.hf.intel.com> To: ibis-request@vhdl.org, ibis@vhdl.org Subject: intel.caanyimi@inside.intel.com Text item: Text_1 intel.caanyimi@inside.intel.com canyimi@pcocd2.intel.com This is a test to see if I will get on the IBIS reflector. From ccm!Will_Hobbs@intelhf.intel.com Wed Jan 19 13:40:40 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00142; Wed, 19 Jan 94 13:40:40 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pMkcG-000MOQC; Wed, 19 Jan 94 13:39 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pMkh5-0000buC; Wed, 19 Jan 94 13:44 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 19 Jan 94 13:44:07 PST Date: Wed, 19 Jan 94 13:44:07 PST From: Will Hobbs Message-Id: <940119134407_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: OPEN REVISION Hello IBIS members: Bob Ross sent this to me last week, I corrected the formatting changes the mailer made to it, then Bob sent me a revision. I'm sorry I haven't gotten to the second re-formatting and posting of this BIRD sooner, but I've been fighting fires. Please, do not use tabs when you submit BIRDS, do not exceed 80 characters, and please try to get it correct the first time. This will help me a lot. That said, ladies and gentlemen, here is BIRD 7 for your reading enjoyment. But first, an introduction by Bob Ross.... (drum roll).... Here is an attempt to reopen the open-side issue. This does not address how the open devices are handled in the simulator, but rather, how they can be specified in a manner that covers all components. If this BIRD is approved, then new Model_type selections are introduced for completeness. This will make the [Model] documentation clearer and will be the favored method to specify "open" models. It will not prevent any of the alternative methods that currently exist. If this BIRD is not approved, then "Open_drain" stands alone and must be supported. But for completeness and consistency, the alternative methods that currently exist would be the favored method for all "open" models. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: XXXX ISSUE TITLE: Open Specification Completion REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 13 January 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: Model_type "Open_drain" provides insufficient coverage for "open" sided models. For completeness, additional "open" Model_types are need. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Under the keyword [Model], additional Model_type selection choices are given They are Open_source, I/O_open_drain, and I/O_open_source. Below is a revision of the [Model] keyword specification in Version 1.1 edited to show these Model_types. |==============================================================================| | Keyword: [Model] | | Required: Yes | | Description: Used to define a model, and its attributes | | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | | Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, Open_source, | | I/O_open_drain, or I/O_open_source model must | | begin with the keyword [Model]. The model_name must match | | the one that is listed under the [Pin] keyword and must not | | contain more than 20 characters. An .ibs file must contain | | enough [Model] keywords to cover all of the model_names | | specified under the [Pin] keyword, except for those | | model_names which use reserved words (POWER, GND and NC). | | Model_names with reserved words are an exception and | | they do not have to have a corresponding [Model] keyword. | | C_comp is allowed to use "NA" for the min and max values only. | | Other Notes: A complete [Model] description normally contains the following | | keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], | | [POWER_clamp], and [Ramp]. However, some models may have only | | a subset these keywords. For example, an input structure | | normally only needs the [Voltage range], [GND_clamp], and | | possibly the [POWER_clamp] keywords. | | Note that C_comp defines the silicon die capacitance. This | | value should not include the capacitance of the package. | | | |------------------------------------------------------------------------------| [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, Open_source, I/O_open_drain, I/O_open_source | List one only Polarity Non-Inverting, Inverting | List one only, -if any Enable Active-High, Active-Low | List one only, -if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, -if desired Vinl = 0.8V | input logic "low" DC voltage, -if any Vinh = 2.0V | input logic "high" DC voltage, -if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Open-drain is corrected to Open_drain as a Model_type selection. "Drain" also is used for "collector", and "source" also is used for "emitter". Certain pins could not be represented without the additional Model_types. Bidirectional Open_drain pins exist in the SN74AS621, SN74ALS641, and other devices. Open_source pins exist in some line driver components which support both a pullup and a pulldown (sink) output. Examples include the SN75116 and SN75118. Furthermore, some ASICs support the Open_source configuration. Thus Open_source is included. ASICs could be configured as I/O_open_source. Therefore this is included for completeness. The user may choose to model the "open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] is interpreted as Open_drain or I/O_open_drain. Omission of [Pulldown] is interpreted as Open_source or I/O_open_source. The user may choose to model the "open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contain I(typ) entries of 0mA (a minimum of two entries are required), then that operation could be interpreted as "open". Zero valued [Pullup] data corresponds to Open_drain or I/O_open_drain. Zero valued [Pulldown] data corresponds to Open_source or I/O_open_source. Without the additional Model_types, the above two approaches are the only methods to specify "open" sides (other than Open_drain). However the additional Model_types do not prevent the above approaches to be used. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell initiated the issue in Email of October 1993 questioning whether we needed "I/O_OPEN_DRAIN" and I/O_OPEN_COLLECTOR". He referred to the SN74ALS641 Open Collector Tranceiver as a specific example. Kellee Crisafulli in Email of July 1993 considered "open output devices (open-drain, open-collector, open-source)". Furthermore, he referred to "open collector npn" and "open collector pnp" devices. In the discussion, he proposed new Optional (Required for open-side devices) keywords dV/dt_r_off (turn off time of high side driver) and dv/dt_f_off (turn off time of low side driver). Included it the discussion was the requirement that "If the pulldown table is missing then dV/dt_r_off is required" and "If the pullup table is missing then dV/dt_f_off is required". Kellee elaborated further on the measurement/extraction issues of the ramp values. This BIRD does not address the ramp specification. This can be treated as a separate issue. The assumption to date is that sufficient information is provided by the existing dV/dt_r and dV/dt_f specifications. ****************************************************************************** From 71436.1314@CompuServe.COM Thu Jan 20 01:00:42 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04475; Thu, 20 Jan 94 01:00:42 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id DAA09531; Thu, 20 Jan 1994 03:59:14 -0500 Date: 20 Jan 94 03:56:20 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: 10 db improvement at what frequency Message-Id: <940120085619_71436.1314_HHB27-1@CompuServe.COM> To: ravender goyal From: Kellee Crisafulli Re: Reply to: RE>Do IBIS models support EMI 10 db of difference at what frequency? One has to specify the freq when you talk about the radiated power. I will have hard time to believe that it was 10 db of difference from dc to optical freq. Response: So would I. The 10dB I spoke of came from one of our customers attempting to meet the FCC radiation limit. The 10dB improvment was noted at several frequences which were either exceeding or nearly exceeding the FCC limit. This is after all the point for many people. The customer found that his product was nearly exceeding or was actually slightly exceeding the FCC limit before performing a signal integrity cleanup pass on his board (no termination etc.). After cleaning up all his signals he was able to meet or exceed the safety margins needed to meet the FCC requirements. The 10db was a relative improvement at the worst frequencies. He considered this a nice side benefit to making his signals clean.... Have a great day..... Kellee From 71436.1314@CompuServe.COM Thu Jan 20 01:02:06 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04480; Thu, 20 Jan 94 01:02:06 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id EAA04317; Thu, 20 Jan 1994 04:00:38 -0500 Date: 20 Jan 94 03:56:43 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: BIRD 7 Message-Id: <940120085642_71436.1314_HHB27-2@CompuServe.COM> From: Kellee Crisafulli, HyperLynx Re: BIRD 7 Bob, I basically like what you have proposed in BIRD 7 for the additional key words. I have been going to send in a bird on this, but have been waiting for the results of an in-house project we are doing to develop some ABT models under IBIS. We have nearly completed this project and I can report on this now. I also have a few concerns with bird 7, specifically: 1) I believe we absolutely must address the dv/dt issue for the turn off side. We could do this by simply stating explicitly in the specification that the dv/dt associated with opposite side is used as the turn-off time of the open-side device. However it must include a load specification during turn off.And specify this being valid for the a 50 ohm pull to the opposite rail. 2) I think it would be very useful to most semi-conductor companies developing models to require that V/I table data match the model type exactly. This way the IBIS parse can check it and help find errors in manually entered data. 3) If I am not mistaken CMOS has an open_drain p channel and an open_drain n channel device there is no open_source configuration that I know of unless you consider some of the 3 volt outputs with totem pole type n-channel outputs. Therefore the key word open_source may not be appropriate. I propose instead that we use just Open_drain to indicate either an N channel/P channel, open collector, or open emitter type output. The thing that differentiates them is simply the missing V/I data for the output. HyperLynx now has IBIS simulations running of ABT buffers (FutureBus) which look pretty good. These require the open_drain model type and have an additional offset for the output diode. I therefore feel good about From 71436.1314@CompuServe.COM Thu Jan 20 01:03:23 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04488; Thu, 20 Jan 94 01:03:23 PST Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.930129sam) id EAA09562; Thu, 20 Jan 1994 04:01:53 -0500 Date: 20 Jan 94 03:58:52 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: "INTERNET:slipa@eos.ncsu.edu" Cc: IBIS ALL Subject: Spice2IBIS Message-Id: <940120085851_71436.1314_HHB25-1@CompuServe.COM> To: Steven From: Kellee Crisafulli, HyperLynx Background (an EMAIL from Steven to myself and Randy): Hi. My name is Steven Lipa. I'm starting a Ph.D. here at NC State under Michael Steer, and I am planning to work on behavioral modelling. I worked in the jelly-bean IC industry (designing FAST, FACT, ECL, etc.) for about 10 years so I am aware of some of the issues involved. Michael has asked me to get involved in the Spice2IBIS project Hi Steven, I am very happy to hear from you we are extremely interested in you project. I would be very happy to help you any way I can. I would be glad to send you a copy of the IBIS spec, a copy of the IBIS file checker, a copy of the HyperLynx LINESIM PRO product to test your output files, and anything else I can do to help you. I think both Randy and I as well as many others on the IBIS committee would be very intested in helping you with comments, suggestions, ideas etc. If you would like any of the above please let me know and give me your physical address to send it to you You sound like exactly the person we might be looking for to write the first version of the Spice2IBIS converter. Do you have any "C" programming background? What platform would you be developing code on? Here's hoping your IBIS eggs can be converted to IBIS birds (a littel IBIS humor)........ Kellee From Ravender_Goyal@pdxml1.mentorg.com Thu Jan 20 15:44:35 1994 Return-Path: Received: from mgc.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14190; Thu, 20 Jan 94 15:44:35 PST Received: from rainbow.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA12214; Thu, 20 Jan 94 15:42:58 -0800 Received: from pdxml1.mentorg.com by rainbow.mentorg.com with SMTP (15.11.1.6/15.5+MGC-TD 2.08) id AA22308; Thu, 20 Jan 94 15:42:55 -0800 Message-Id: <9401202342.AA22308@rainbow.mentorg.com> Date: 20 Jan 1994 15:19:56 -0800 From: "Ravender Goyal" Subject: on the ibis reflector To: "ravender goyal" Cc: "chuck catto" Reply to: on the ibis reflector Can you please include Chuck Catto from Mentor Graphics Corp, in the IBIS mail group. If you need to know more about Chuck, please send him email! Chuck's e-mail address is chuck_catto@mentorg.com. Thanks...... Ravender From ccm!Will_Hobbs@intelhf.intel.com Thu Jan 20 18:25:09 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15342; Thu, 20 Jan 94 18:25:09 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pNBX0-000MOAC; Thu, 20 Jan 94 18:23 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pNBbz-0000FDC; Thu, 20 Jan 94 18:28 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 20 Jan 94 18:28:38 PST Date: Thu, 20 Jan 94 18:28:38 PST From: Will Hobbs Message-Id: <940120182838_9@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, Ravender_Goyal@pdxml1.mentorg.com, ibis@vhdl.org Cc: catto@wv.mentorg.com Subject: Re: on the ibis reflector Ravender, and others, This request and others like it should be sent to ibis-request@vhdl.org. I have forwarded this particular one, so you don't need to do anything more. Will Reply to: on the ibis reflector Can you please include Chuck Catto from Mentor Graphics Corp, in the IBIS mail group. If you need to know more about Chuck, please send him email! Chuck's e-mail address is chuck_catto@mentorg.com. Thanks...... Ravender From bob@icx.com Thu Jan 20 18:56:58 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15625; Thu, 20 Jan 94 18:56:58 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18746 for ; Thu, 20 Jan 94 21:45:36 -0500 Date: Thu, 20 Jan 94 16:55:27 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA12555; Thu, 20 Jan 94 16:55:27 PST Message-Id: <9401210055.AA12555@icx.com> To: ibis@vhdl.org Subject: OPEN BIRD7 Comments Kellee, In you comments on the "open" bird7, you have raised some interesting points. The real issue is to specify whether the pullup is open or the pulldown is open - i.e., "the missing V/I data for the output." By knowning this, the appropriate ramp can be interpreted for the turn-off transition. "Open_drain" is already defined in IBIS Version 1.1. Furthermore, in NOTES ON DERIVATION DATE #7, "The rise time of an open-drain device must be measured into a 50 Ohm pullup resistor tied to the power pin." Based on this, there is a strong implication that "Open_drain" means open pullup. However, I think you are technically correct in pointing out that in CMOS logic, Open_drain is ambigous as to which side is open - it could either the p-channel or the n-channel device. The IEC logic symbol definitions for open outputs unfortunately give little guidence in this area. One is defined for "N-P-N open-collector or similar output ...", and the other is for "N-P-N open-emitter or similar output ...". Based on this, it would be ideal to use open_collector and open_emitter generically to cover both bipolar and CMOS technologies and to drop "Open_drain" as a Model_type. On the other hand, I know of one example where "open source" and "open drain" are used. The Toshiba TC140G/14L/150G Series Macrocell data book specifies open drain, open source, bidirectional open drain and bidirectional open source output buffers. (Actually these are 3-state open drain and open source output buffers!) I am faxing to you, Kellee, some of the pages. For terminology purposes the four Model types are given for open pullup and open pulldown and the I/O versions of the same. >From the circuits shown, I think you could argue that the names are technically incorrect. One part of the issue then is what terms should we use? Are there any common usage guidelines we could follow? What I would like to see is the best way to specify "open-pullup", "open-pulldown", "I/O-open-pullup" (such in the ABT Futurebus line), and "I/O-open-pulldown" with, hopefully, only four Model_types. We should also specify "3-state-open-pullup" and "3-state-open-pulldown" for completeness. Regarding another point, I agree that the dV/dt of the off side has to be specified. The text of Note 7 above should be expanded. Would this address your concern? Bob Ross Interconnectix, Inc. From 71436.1314@CompuServe.COM Fri Jan 21 00:14:45 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17460; Fri, 21 Jan 94 00:14:45 PST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id DAA07413; Fri, 21 Jan 1994 03:13:16 -0500 Date: 21 Jan 94 03:09:34 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: BIRD 7 (more from Kellee Crisafulli) Message-Id: <940121080933_71436.1314_HHB30-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx To: Bob Ross, Bob Ward and fellow IBISers Re: BIRD 7, Resending, (1/2 of the document was lost in the mail) For some reason only 1/2 of my Email was transmitted. I recreated the the 2nd 1/2 from memory and am resending it. Also, at the end of this document is my response to Bob's last message. My apologies, I don't know where the other 1/2 landed ... (perhaps in the IBIS bird bath) Bob, I basically like what you have proposed in BIRD 7 for the additional key words. I have been going to send in a bird on this, but have been waiting for the results of an in-house project we are doing to develop some ABT models under IBIS. We have nearly completed this project and I can report on this now. I also have a few concerns with bird 7, specifically: 1) I believe we absolutely must address the dv/dt issue for the turn off side. We could do this by simplystating explicitly in the specification that the dv/dt associated with opposite side is used as the turn-off time of the open-side device. However it must include a load specification during turn off. and specify this being valid for the a load resistor to the opposite rail. 2) I think it would be very useful to most semi-conductor companies developing models to require that V/I table data match the model type exactly. This way the IBIS parse can check it and help find errors in manually entered data. 3) If I am not mistaken CMOS has an open_drain p channel and an open_drain N channel device there is no open_source configuration that I know of unless you consider some of the 3 volt outputs with totem pole type N-channel outputs. Therefore the key word open_source may not be appropriate. I propose instead that we use just Open_drain to indicate either an N channel/P channel, open collector, or open emitter type output. The thing that differentiates them is simply the missing V/I data for the output. HyperLynx now has IBIS simulations running of ABT buffers (FutureBus) which look pretty good. These require the open_drain model type and have an additional offset for the output diode. I therefore feel good about recommending the use of IBIS for modeling open side devices. I beleive we should modify BIRD7 as follows: ********************************************* 1) Modify the "Usage Rules" under the Keyword Model, to show Open_drain instead of Open-drain. (exactly as Bob suggested) 2) Add only one new keyword "I/O_open_drain" to the list in usage rules, and the Model_type line. This keyword allong with Open_drain can represent all open side devices. The absence of either the Pullup and Pulldown V/I table can be used to indicate which side is open. 3) Change the section titled NOTES ON DATA DERIVATION METHOD as follows: Section 3 on Ramp rates: ------------------------ 3) Ramp Rates: The ramp rates (listed in AC characteristics below) should be derived as follows: 1)Start with the silicon model, remove all packaging. 2)If: The model type is one of the following: Output, I/O, or 3-state Then: Attach a 50 ohm resistor to GND to derive the rising edge ramp. Attach a 50 ohm resistor to POWER to derive the falling edge ramp. If: The model type is either (Open_drain or I/O_open_drain) and the Pullup V/I table is missing. Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either POWER or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. If: The model type is either (Open_drain or I/O_open_drain) and the Pulldown V/I table is missing. Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either GND or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. 4-6) renumber these 3-5 7) **** Delete item 7 ****** 4) Under the Pullup, Pulldown keyword section in usage rules, add the following: If the model type is (Output, I/O, or 3-state) then both the Pullup and Pulldown V/I tables are required. If the model type is either (Open_drain or I/O_open_drain) then only one "Pull" V/I table (Pullup or Pulldown) may be present. Postmortum: ----------- After reading Bobs response to 1/2 of my Email I agree that the usage of open_source is being used by some vendors in a somewhat confusing manor. i.e. they call the open drain P channel devices open_source. While I think this is an inconsistant usage, I am willing to use Open_source and I/O_open_source as Bob suggested if the entire IBIS group strongly perfers this. I DO NOT however want to choose a solution that deletes the existing Open_drain model type as this is not backward compatible with the specification. Note: 3_state_open_drain is a redundant definition and is therefore not needed. (i.e. open_drain by definition is 3-stated if it is off) Summary: -------- Using just two key words, Open_drain, and I/O_open_drain is simple, and maintains backward compatibility, and covers all the cases so far... P.S. thankyou for the Fax, Bob. Best wishes to all...... Kellee  From 71436.1314@CompuServe.COM Fri Jan 21 00:39:18 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17873; Fri, 21 Jan 94 00:39:18 PST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id DAA07915; Fri, 21 Jan 1994 03:37:49 -0500 Date: 21 Jan 94 03:35:28 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Bird 6, Differential signal spec, From Kellee Crisafulli Message-Id: <940121083528_71436.1314_HHB27-1@CompuServe.COM> From: Kellee Crisafulli To: Bob Ross and fellow IBIS members Re: BIRD 6 (differential pin spec proposal) Bob it is really nice to see all the activity from you. This is another great start on an IBIS improvment. I have read your BIRD and have the following concerns: 1) The use of the vpp term to indicate the threshold voltage seems like a good idea, however the vpp label is used alot for programmable devices to indicate a programming supply pin and I am concerned about confusion factor at semi-conductor houses. How about "vdiff" or something similar? 2) Real output buffers will have pin to pin skew between the non-inverting and inverting pins. It seems like this could be significant factor for proper modeling at higher speeds. I say could because I have little experience with differential mode systems. Do you think we need to consider a delay term with min, typ, max ? Would any of the Semiconductor vendors care to comment on this (National, TI etc)? 3) Should we consider using the POLARITY specification that already exists instead of the negative voltage to indicate polarity? e.g. we could require that both pins have either inverting or both pins have non_inverting polarity and only except positive diffential threshold voltages. Great start Bob! Kellee .. From ccm!Arpad_Muranyi@intelhf.intel.com Fri Jan 21 13:05:37 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26429; Fri, 21 Jan 94 13:05:37 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pNT1Q-000MNXC; Fri, 21 Jan 94 13:04 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pNT6V-0000HfC; Fri, 21 Jan 94 13:09 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 21 Jan 94 13:09:19 PST Date: Fri, 21 Jan 94 13:09:19 PST From: Arpad Muranyi Message-Id: <940121130919_8@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: BIRD 7 from Arpad Text item: Text_1 Dear IBIS watchers, It seems to me that it really does not matter whether that open something is a DRAIN, or SOURCE, or COLLECTOR or EMITTER. That is described by the V/I curve. All we need to tell the simulator is whether the particular element that is left there in the device is connected to POWER or GND. I feel we should either use JUST ONE of the existing terms, such as open drain, or open collector in a general (and somewhat inaccurate) manner, or we might coin a new term that means what we want to say without aggrovating those of us who like to mean what we say. In either case, ONE keyword (or subkeyword, whatever it is) should be sufficient to achieve the goal. Something like "open pulldown" could replace "open drain" and an additional "open pullup" might take care of all possibilities. (Unless I am missing the point). We can figure out how to spell them later if we decide on these terms. Otherwise I agree with the intent of the BIRD. Arpad From cpk@Cadence.COM Fri Jan 21 13:20:34 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26534; Fri, 21 Jan 94 13:20:34 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id NAA16546; Fri, 21 Jan 1994 13:19:03 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma016525; Fri Jan 21 13:18:54 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA12512; Fri, 21 Jan 94 13:15:41 -0800 Received: by hot (5.65+/1.5) id AA02995; Fri, 21 Jan 94 16:17:45 -0500 Date: Fri, 21 Jan 94 16:17:45 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9401212117.AA02995@hot> To: ibis@vhdl.org, Arpad_Muranyi@ccm.hf.intel.com Subject: Re: BIRD 7 from Arpad > > Dear IBIS watchers, > > It seems to me that it really does not matter whether that open > something is a DRAIN, or SOURCE, or COLLECTOR or EMITTER. That is > described by the V/I curve. All we need to tell the simulator is > whether the particular element that is left there in the device is > connected to POWER or GND. I feel we should either use JUST ONE of the > existing terms, such as open drain, or open collector in a general (and > somewhat inaccurate) manner, or we might coin a new term that means what > we want to say without aggrovating those of us who like to mean what we > say. In either case, ONE keyword (or subkeyword, whatever it is) should > be sufficient to achieve the goal. > > Something like "open pulldown" could replace "open drain" and an > additional "open pullup" might take care of all possibilities. (Unless > I am missing the point). We can figure out how to spell them later if > we decide on these terms. > > Otherwise I agree with the intent of the BIRD. > > Arpad > I thought that the ECL bird provided for explicit referencing and solved this problem. - kumar From bob@icx.com Fri Jan 21 16:06:55 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27945; Fri, 21 Jan 94 16:06:55 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA08651 for ; Fri, 21 Jan 94 18:42:37 -0500 Date: Fri, 21 Jan 94 14:59:56 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA15158; Fri, 21 Jan 94 14:59:56 PST Message-Id: <9401212259.AA15158@icx.com> To: ibis@vhdl.org Subject: BIRD 7 comment Hello IBIS members: Thanks, Kellee for the completed set of comments regarding Bird7. You have presented a valid alternative proposal which saves adding some new Model_types, yet produces the expanded functionality. I think, however, "open-drain" is commonly understood to mean open pullup for CMOS devices. I have never seen used to describe an open pulldown configuration. I am open to any terminology improvement, but agree with you that at least "Open_drain" should be retained for compatiblity. Assuming "Open_source" is adopted, I want to lay out a table with respect to a little item I introduced and you commented on: 3-state open outputs. The issue actually relates to the Vinh and Vinl Sub-Params of [Model] and also to "Terminator" specification - issues Jon Powell have raised in past Email. Assume we have the "open-source" model_types and an additional one called "Terminator". Then a table can be drawn providing reasonably complete coverage and consistency. Model_type: Terminator Output 3-state | I/O Input Open_drain 3-state_OD | I/O_Open_drain Open_source 3-state_OS | I/O_Open_source | Vinh, Vinl not required | Vinh, Vinl required | pullup and pulldown disable | | option in simulator | | (manual or automatic) | Functionally there really is no need for any 3-state designation or in many cases even the Output designation. The I/O designation and the existence of Vinh and Vinl is sufficient to cover practical modeling cases. The state that and I/O or 3-state model is in can be external to the component. However, common data book terminology plus terms used in IBIS Version 1.1 argue for Output and 3-state. So what I am doing is just filling out the table for the "open" cases in a consistent manner for explicit specification versus derived specification, hopefully consistent with common practice. Furthermore, I am reserving some Model_type words in case we really need them. Actually, at this time I favor continuing making Vinh and Vinl optional for all cases because I think some I/O models can be "disabled" into a high Z mode without input. Furthermore, the Input could then also designate a "terminator" functionality if Vinh and Vinl were not specified. With Version 1.1, a diode terminator package such as the SN74S1050 can be represented using Input models and the POWER_clamp and GND_clamp data. However, for explicit specification, I would not mind adding "Terminator" to the list of Model_types. Briefly regarding terminators, I favor expanding the keyword list that would be placed under [Model] to include [Rpower] and [Rgnd] for parallel terminator specification and terminators to ground (and also pullup resistors for open devices). Then a package such as the Motorala MCCS142233 9-Bit Switchable SCSI Passive Bus Terminator (220 Ohm and 330 Ohm) can be modeled without using extended clamping data. Furthermore, I think AC terminators should be modeled. Anyway, all of this is probably a basis for another Bird per discussions next week. This points out that a lot of issues are closely related, and getting them all on the table will give a better overall resolution. Bob Ross Interconnectix, Inc. From speters@ichips.intel.com Fri Jan 21 16:19:33 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28066; Fri, 21 Jan 94 16:19:33 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 21 Jan 94 16:18:04 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 21 Jan 94 16:17:46 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 21 Jan 94 16:17:50 PST Message-Id: <9401220017.AA28281@xtg801.intel.com> To: ibis@vhdl.org Subject: More on BIRD #7 Date: Fri, 21 Jan 1994 16:17:49 -0800 From: Stephen Peters Hello fellow IBISans -- While reading Kellee Crisafulli's e-mail this morning (1/21), regarding BIRD #7 and detailing how to measure the ramp rates for the various type of outputs, it stuck me that nowhere have we specified how to measure the ramp rate when dealing with ECL. Although ECL has an output type of Output or I/O, the ramp time is not measured with the same technique as used for standard totem-pole outputs. I agree completely with Kellee that expanding Section 3 on ramp rates is needed and I would add the following: (my additions to Kellee's list are shown with a "++"). ------------- Section 3 on Ramp rates: ------------------------ 3) Ramp Rates: The ramp rates (listed in AC characteristics below) should be derived as follows: 1)Start with the silicon model, remove all packaging. 2)If: The model type is one of the following: Output, I/O, or 3-state ++ and is not ECL. Then: Attach a 50 ohm resistor to GND to derive the rising edge ramp. Attach a 50 ohm resistor to POWER to derive the falling edge ramp. ++ If: the output type is Output or I/O and is ECL ++ Then: Attach a 50 ohm resistor to the termination voltage ++ (Vterm = VCC - 2v). Use this load to derive both the ++ rising and falling edges. If: The model type is either (Open_drain or I/O_open_drain) and the Pullup V/I table is missing. Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either POWER or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. If: The model type is either (Open_drain or I/O_open_drain) and the Pulldown V/I table is missing. Then: Attach either a 50 ohm resistor or the vendor suggested termination resistance to either GND or the vendor suggested termination voltage. Use this load to derive both the rising and falling edges. 4-6) renumber these 3-5 7) **** Delete item 7 ****** ---------------------- Best Regards, Stephen Peters Intel Corp. From bob@icx.com Fri Jan 21 18:31:55 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29051; Fri, 21 Jan 94 18:31:55 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA01750 for ; Fri, 21 Jan 94 21:14:17 -0500 Date: Fri, 21 Jan 94 16:08:58 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA15502; Fri, 21 Jan 94 16:08:58 PST Message-Id: <9401220008.AA15502@icx.com> To: ibis@vhdl.org Subject: BIRD6 comment Hello again IBIS flock: Thanks Kellee for your comments, I agree with your "vdiff" terminology change, or whatever people feel is best. Also, you raised a good point regarding differential skew. For example, the National DS3695A/DS3695AT/DS3696A/DS3696AT Multipoint RS485/RS422 Tranceivers in the Interface Databook specify this and show a waveform. Another column could be added for this in [Diff_pin]. I think using the POLARITY in the model instead of the sign of "vdiff" is a good alternative. In that way the polarity of of "vdiff" could be reserved more appropriately for a hypothetical differential device with differential hysterisis (although I have not found such a device). In doing Bird6, I had a problem in choosing whether one [Model] could be used or two [Model]s were required, one for Positve and one for Negative Polarities. In its present form, two [Model]s (even different models - and I have seen cases where complementary outputs in some latches differ) can be used if necessary, but one [Model] is sufficient. Your POLARITY specification method would work for both cases. Bob Ross Interconnectix, Inc. From ccm!Will_Hobbs@intelhf.intel.com Mon Jan 24 14:01:44 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08445; Mon, 24 Jan 94 14:01:44 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pOZKG-000MNqC; Mon, 24 Jan 94 14:00 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pOZMb-0000ayC; Mon, 24 Jan 94 14:02 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 24 Jan 94 14:02:29 PST Date: Mon, 24 Jan 94 14:02:29 PST From: Will Hobbs Message-Id: <940124140229_33@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Bridge Number for Friday's phone conference Text item: Text_1 IBIS folk, The next IBIS teleconference is this coming Friday. Per our last meeting, we have moved the time up to 8-10 Pacific time (that is one hour earlier than it used to be). We will be sending out an agenda later this week. Jan. 28th 8-10 Bridge: 415-904-8944 - Res. 657903 Call the bridge, ask for the IBIS Open Forum and give the reservation number. I look forward to hearing your voices on Friday, and I strongly encourage people to join us who have not previously called in, particularly other IC vendors. Regards, Will Hobbs From bob@icx.com Mon Jan 24 16:40:20 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09310; Mon, 24 Jan 94 16:40:20 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02562 for ; Mon, 24 Jan 94 17:52:20 -0500 Date: Mon, 24 Jan 94 13:48:58 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA27379; Mon, 24 Jan 94 13:48:58 PST Message-Id: <9401242148.AA27379@icx.com> To: ibis@vhdl.org Subject: BIRD 7 Comment on ECL Hello IBIS team: After thinking about Kumar's question to Arpad Muranyi's and Stephen Peter's recent ECL addition on ramp rates to Kellee Crisafulli's added notes, I want to list how we can identify ECL model types and its variations (e.g. ECL tied to a positive supply as in PECL) based on IBIS Version 1.1 and approved BIRDS 3 and 4: The IBIS Model is "ECL-type" if the pullup and pulldown "typical" reference voltage values are the same. These values can be extracted from the model and compared for equality. Such an extraction would be based on the [Voltage range], [Pullup reference] and [Pulldown reference] typical_values and on which take precedence over the other. Also, the equality can be tested based on satisfying one of the cases: (1) [Pullup reference] typ_val = [Pulldown reference] typ_val | e.g. 5.V = 5.V regardless of [Voltage range] typ_val or | whether [Voltage range] keyword is not present (2) [Voltage range] typ_val = [Pulldown reference] typ_val AND [Pullup reference] keyword not present (3) [Voltage range] typ_val = [Pullup reference] typ_val = 0 AND [Pulldown reference] keyword not present (default is 0V) (4) [Voltage range] typ_val = 0 AND [Pullup reference] and [Pulldown reference] keywords not present (default for pulldown reference is 0V) I am not sure if an IBIS model can be considered ECL if the pullup or pulldown data spans exactly a range from Vcc to Vcc - 2.2 because I do not know whether "spanning the range" means that the data cannot exceed this range. (E.g., I may be able to get a good data point at Vcc - 2.3V.) If "ECL-type" then [Pulldown] data follows Vtable = Vout - Vcc order. It might be easier to consider Model_types "Output_ECL" and "I/O_ECL" (and for completeness "Input_ECL" although "Input" works the same with ECL). BIRD 1 (which was replaced by BIRDS 3 and 4) originally proposed Model_type "ECL". The real issue is how explicit should IBIS be in specifying the Model_type, especially when such knowledge is critical in knowing how to interpret the [Model] data. A robust set of Model_type information can simplify the mapping of the IBIS data into internal data structures which do not have to carry the same level of distinctions. The internal data structures can rely as appropriate on other relationships and still have the same functionality. Bob Ross Interconnectix, Inc. From 71436.1314@CompuServe.COM Tue Jan 25 09:35:35 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20623; Tue, 25 Jan 94 09:35:35 PST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id MAA23024; Tue, 25 Jan 1994 12:34:05 -0500 Date: 25 Jan 94 12:29:51 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: IBIS to Spice converter (Important) Message-Id: <940125172950_71436.1314_HHB64-1@CompuServe.COM> From: Kellee Crisafulli Greetings fellow IBIS designers and creaters! This morning I spoke with Steve Lipa, the PHd student at NC state University working on the IBIS to Spice converter. He is ready to get started. He indicated he will check in with the reflector from time to time for suggestions and to give us updates. His project is funded. He will be writting in standard 'C'. We can help Steve in two ways: 1) Provide him with a document that shows what the current version 2 specification is. I am wondering if Will Hobbs would be willing to get a document together that contains all final versions of the accepted BIRDS. I have had other people ask for this as well. 2) Any or all of the Semi-conductor people could gather their present SPICE model librarys or subsets and send Steve models to run the converter on. (Perhaps Bob Ward at TI, and anyone else interested might contribute these) Have a great day! From ccm!Will_Hobbs@intelhf.intel.com Tue Jan 25 10:08:28 1994 Return-Path: Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20807; Tue, 25 Jan 94 10:08:28 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pOs9r-000MO5C; Tue, 25 Jan 94 10:06 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pOsCI-0000aJC; Tue, 25 Jan 94 10:09 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 25 Jan 94 10:09:05 PST Date: Tue, 25 Jan 94 10:09:05 PST From: Will Hobbs Message-Id: <940125100905_3@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, 71436.1314@CompuServe.COM, ibis@vhdl.org Subject: Re: IBIS to Spice converter (Important) Kellee, et al, I will post all passed and pending BIRDs to the reflector this week. Derrick and I are also putting all of them (passed, pending and voted down or superseded) into the archive on vhdl.org, and they should be there this week. Will From: Kellee Crisafulli Greetings fellow IBIS designers and creaters! This morning I spoke with Steve Lipa, the PHd student at NC state University working on the IBIS to Spice converter. He is ready to get started. He indicated he will check in with the reflector from time to time for suggestions and to give us updates. His project is funded. He will be writting in standard 'C'. We can help Steve in two ways: 1) Provide him with a document that shows what the current version 2 specification is. I am wondering if Will Hobbs would be willing to get a document together that contains all final versions of the accepted BIRDS. I have had other people ask for this as well. 2) Any or all of the Semi-conductor people could gather their present SPICE model librarys or subsets and send Steve models to run the converter on. (Perhaps Bob Ward at TI, and anyone else interested might contribute these) Have a great day! From slipa@eos.ncsu.edu Wed Jan 26 14:54:31 1994 Return-Path: Received: from rand.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07735; Wed, 26 Jan 94 14:54:31 PST Received: by rand.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA13063; Wed, 26 Jan 1994 17:52:48 -0500 From: slipa@eos.ncsu.edu Message-Id: <9401262252.AA13063@rand.ece.ncsu.edu> To: ibis@vhdl.org Subject: SPICEtoIBIS convertor Date: Wed, 26 Jan 94 17:52:46 EST Dear IBIS Community: I am trying to write a SPICE to IBIS converter that will be of use to the IBIS Community (IC) and prospective members of the IC. I am writing to you to solicit opinions and other information that might be helpful in making the product useful to the largest possible audience. To begin with, my understanding is that there is not yet a written specification for the converter. Therefore, let me present my own mini-specification and a couple of concerns I have: SPICEtoIBIS mini-specification ------------------------------ Purpose: SPICEtoIBIS accepts a commented SPICE input deck; runs the necessary SPICE simulations to generate Pulldown, Pullup, GND_clamp, POWER_clamp, and Ramp tables with typ, min and max columns using the NOTES ON DATA DERIVATION METHOD section from version 1.1; and uses the comments in the SPICE deck and the SPICE output data to generate a syntactically-correct IBIS 1.1 model. [Pin] information will be entered at the beginning of the SPICE deck using standard IBIS syntax except that an extra column is added to any line that describes a pin to be included in the IBIS model, and of course all lines are preceded by the SPICE comment character. Additionally, the first line of the input deck must be a comment line with BIPOLAR or CMOS somewhere on it. --------------------------------- This seems pretty straightforward, but I have some concerns about it and would greatly appreciate any comments, help, etc regarding this mini-spec and/or the following concerns: 1) Some Si vendors use .TNOM and separate .MODEL cards for each temperature simulated, and some may use one .MODEL for all temperatures and a .TEMP card alone. On a related note, any vendor that does use .TNOM probably does not use 50 and 100 degrees C models. Is the converter required to figure out which technique is being used and kludge a reasonable .TNOM and .TEMP for whatever model is given, or is the vendor supposed to go to the bother of generating new models? 2) What about BiCMOS devices? (sorry if this is a dumb question...) 3) Is it OK to use a constant step size in the tables, or is it really desirable to minimize the number of entries? 4) Are there other features required? Ignoring the concerns listed above I can put something with a nominal amount of error-checking together in fairly short order, but I hope to be able to provide you with a robust, general-purpose tool, so I would greatly appreciate any comments and or suggestions that you may have. If anyone can send me examples of their SPICE simulation files and/or associated IBIS models, this would be a great help. I assume that a wide variety of approaches are used, and seeing as many examples as possible will help me to make a more general-purpose tool. Thanks in advance for any help you can provide! Steve Lipa slipa@eos.ncsu.edu 919-515-3947 From ccm!Derrick_Duehren@intelhf.intel.com Wed Jan 26 22:35:58 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10989; Wed, 26 Jan 94 22:35:58 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pPQJ3-000MNSC; Wed, 26 Jan 94 22:34 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pPQLh-0000j3C; Wed, 26 Jan 94 22:37 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 26 Jan 94 22:37:05 PST Date: Wed, 26 Jan 94 22:37:05 PST From: Derrick Duehren Message-Id: <940126223705_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: 1/28/94 IBIS Agenda Text item: Text_1 IBIS Open Forum Jan. 28th, 8:15-10:00 am PST Bridge # (415) 904-8944 Reservation # 657903 Note: When speaking, please identify yourself. 1/28/94 AGENDA 8:15 Check-in 8:20 Introductions of new IBIS members/participants Hobbs 8:25 1/7 minutes review Duehren Opens for new issues All 8:35 Press updates Hobbs/All Progress toward enlisting new IC vendors All IBIS 2.0 Hobbs Forms of EDA support of IBIS Duehren IBIS Cookbook Hobbs Dues? For what? Hobbs 9:00 BIRD 6, Differential Pin Spec. Ross BIRD 7, Open Specification Completion Ross Egg 1, mutual pin coupling Bracken Spice to IBIS Converter Lipa 9:15 Canright paper Ward Formal BNF notation Reed, Harr BIRD 2, VIH, VIL Thresholds for Inputs Powell 9:30 3D Modeling (U of NC) Bracken, et. al. High freq. $ EMI Goyal, et. al. 9:45 Phased turn-on/off of multiple devices Powell Foils of IBIS Summit Hobbs 9:55 Wrap-up, Next Meeting Plans Hobbs From bracken@valhalla.performance.com Thu Jan 27 13:22:17 1994 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20811; Thu, 27 Jan 94 13:22:17 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA03420; Thu, 27 Jan 94 16:22:25 EST Message-Id: <9401272122.AA03420@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: EGG 1.0 Date: Thu, 27 Jan 94 16:22:23 -0500 From: bracken@valhalla.performance.com Fellow Avians: I've just returned to the net after some serious router down time. Here's a little something to prompt discussions on the issue of how to represent mutuals. You'll recall that there are two proposals before the forum: the EGG uses a "sparse" representation; the other proposal from Cadence is to use a "banded matrix" approach. One issue that has been raised is how compact the two notations are. Both approaches assume some numbering of the pins from 1 to N. Recall that the "banded" approach assumes that if you have two pins, numbered I and J, then there is no coupling if the difference of the two indices is greater than the bandwidth B. So, for each pin from 1 to N (let's take the I'th) you just have B + 1 entries: I's self term, the mutual from I to I+1, I to I+2, ..., I to I+B. There's no need to list the indices of the pins in the table of mutual values. In the sparse approach, you explicitly indicate the indices of the two coupled pins, and then give the value of the mutual. If there's a coupling from pin 10 to pin 78, you write 10 78 1.98237e-7 or something similar. Clearly, the need to write the indices is the source of overhead of this method. It's also a source of clarity for the human reader. In what follows, I've provided a little analysis of the storage requirements in the two approaches for a specific case: that of a big PGA. The results of the comparison may prove surprising. --Eric Bracken Chris Reid of Cadence wrote in response to EGG 1.0: >> As for representing mutuals, we are using banded-symmetric RLC >> matricies. That is the form most 3-D field solvers deliver the result, >> and it is an easy format to deal with in software. Eric's suggested >> format is up to the task, but it is somewhat more verbose than >> required, and requires more processing by the software. I guess that the "verbosity" you're referring to is the need to include the indices of the coupled pins before I give the values of the mutuals? I would say this is the price of the increased generality; the couplings don't need to be "banded" for this description to work. As to how verbose it really is, I'm not so sure. There are some inefficiencies in the banded matrix approach. Take the Intel Overdrive processor for the Pentium. It's a 273-pin PGA, with pins laid out in 21 rows with up to 21 pins each. Here's a simplified view of how the pins are distributed: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Now think about it--if I number the pins in the first row 1, 2, 3, ..., 21, those in the second row with 22, 23, ..., 42 and so forth (of course the numbering gets screwed up when you get to the "hole" in the middle, but you get the drift), then the bandwidth of the matrix is 22. That is to say, if you take (for example) pin 23 (the 2nd pin in row 2), then it's coupled to the pins above (pins 1, 2, 3) the pins beside (22, 24), and the pins below (pins 43, 44, 45). Although there are only 8 nearest neighbors, the bandwidth is 22. Therefore, the banded symmetric matrix representation will have 273 rows X 23 entries (22 mutuals + 1 self term), or 6279 entries total. Remember that in the banded representation, zero-valued entries that lie within the "band" still have to be listed explicitly. Each of these entries is a triple (R,L,C) of floating point numbers. If we can assume 10 characters per floating point number, that's 30 characters per banded matrix entry, or 188,370 <- Banded characters total, not counting spaces and returns. On the other hand, if I employ the "sparse" representation described in the EGG, then the 273 pins have 8 neighbors + 1 self term, or 9 entries per pin, for a total of 273 x 9 = 2457 entries. (Actually, some pins obviously have fewer than 8 neighbors, which would be exploited to further reduce the number of entries.) Each entry consists of 3 floating point numbers (10 chars each) and 2 integer indices (3 characters apiece), or 36 characters per entry. The total file size is therefore 2457 x 36, or 88,452 <- Sparse characters total. This is just under half the size of the banded representation. Please note that I'm assuming BOTH approaches make use of symmetry, which is only commonsense. To be fair to the banded approach, it is possible to look at more clever numbering schemes to reduce the bandwidth. But this tends to add more work for the people who are trying to build the models (which they may be unwilling to expend) because those schemes are far from intuitive. From cer@Cadence.COM Thu Jan 27 13:34:43 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20948; Thu, 27 Jan 94 13:34:43 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id NAA09795 for ; Thu, 27 Jan 1994 13:33:04 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma009774; Thu Jan 27 13:32:47 1994 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA00301; Thu, 27 Jan 94 13:27:56 -0800 Received: by oahu (5.65+/1.5) id AA02942; Thu, 27 Jan 94 16:31:43 -0500 Date: Thu, 27 Jan 94 16:31:43 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9401272131.AA02942@oahu> To: ibis@vhdl.org Subject: Mutuals : sparse vs banded Eric, Ok, you are right about the comparison between storage requirements of a "sparse" versus a "banded" approach for parts with pins arranged as you indicated. One could argue about how many such parts there are and therefore which approach actually results in a shorter "average" description over a large number of parts. However, that discussion is probably pointless. What is important is convenience to the supplier and user. The banded-matrix approach is convenient because field solvers tend to deliver their results that way. The "sparse" method is (in some cases) easier to read. We might consider supporting both methods, since the focus is on convenience, and each method is better in certain cases. Chris From ccm!Will_Hobbs@intelhf.intel.com Thu Jan 27 13:41:31 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20982; Thu, 27 Jan 94 13:41:31 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pPeRP-000MOYC; Thu, 27 Jan 94 13:39 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pPeTh-000085C; Thu, 27 Jan 94 13:42 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 27 Jan 94 13:42:17 PST Date: Thu, 27 Jan 94 13:42:17 PST From: Will Hobbs Message-Id: <940127134217_7@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Bridge numbers for upcoming meetings Text item: Text_1 Ibisers, The bridge and reservation numbers for the next four meetings are listed below. They will be listed again in the minutes. Please note that we have changed the times for the meeting to 8:15 AM Pacific time out of deference to our East Coast participants. When you call into the meeting, as always, ask for the IBIS Open Forum and give the bridge operator the reservation number. Will IBIS - 8:15-10:00 AM Pacific time. Date: Bridge: Res: 1/28 (415) 904-8944 657903 2/18 (415) 904-8800 661436 3/11 (415) 904-8944 661901 4/1 (415) 904-8944 661905 From 71436.1314@CompuServe.COM Thu Jan 27 22:07:06 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24382; Thu, 27 Jan 94 22:07:06 PST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id BAA14899; Fri, 28 Jan 1994 01:05:31 -0500 Date: 28 Jan 94 01:01:53 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: "Steve Lipa (SPICE2IBIS)" Cc: IBIS ALL Subject: Email from you to IBIS forum Message-Id: <940128060152_71436.1314_HHB37-1@CompuServe.COM> From: Kellee Crisafulli To: Steve Lipa (NCSU) RE: SPICE2IBIS Good start Steve! Regarding your questions: 1) Some Si vendors use .TNOM and separate .MODEL cards for each temperature simulated, and some may use one .MODEL for all temperatures and a .TEMP card alone. On a related note, any vendor that does use .TNOM probably does not use 50 and 100 degrees C models. Is the converter required to figure out which technique is being used and kludge a reasonable .TNOM and .TEMP for whatever model is given, or is the vendor supposed to go to the bother of generating new models? Kellee -> It would be great if you could kludge together something. 2) What about BiCMOS devices? (sorry if this is a dumb question...) Kellee -> Not a dumb question. Which issues are you thinking of in particular? 3) Is it OK to use a constant step size in the tables, or is it really desirable to minimize the number of entries? Kellee->A constant step size is ok. It may slow down the simulations slightly, however I don't believe this is a major problem. If it simplifies your work do it. 4) Are there other features required? Kellee->I suggest a multiple step approach to this problem. Phase 1) (Understand the problem better) Take input files from 2 or more vendors for a single CMOS device and write a translator. (Keep it simple and get something that works) This will give us an excellent vehicle for commenting on the more advanced version. Even hold the temperature a constant at 25 degrees C and don't worry about min/max for the first pass. Document all places were more advanced features are needed as you go. Report back to the IBIS forum and we can define a detailed Phase 2. In the mean time the vendors can start using your work from phase 1. Phase 2) (Do it "right") Add support for more vendors spice models, bipolar,ECL, BiCmos, and various open-side devices. From ccm!Derrick_Duehren@intelhf.intel.com Fri Jan 28 14:35:21 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05902; Fri, 28 Jan 94 14:35:21 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pQ1l0-000MOsC; Fri, 28 Jan 94 14:33 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pQ1nP-00002gC; Fri, 28 Jan 94 14:36 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 28 Jan 94 14:36:11 PST Date: Fri, 28 Jan 94 14:36:11 PST From: Derrick Duehren Message-Id: <940128143611_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Membership Roster - Draft Text item: Text_1 IBIS Consortium Membership Roster - First Draft As of 1/28/94 Administered by: Derrick Duehren, Intel Corp. dduehren@ichips.intel.com (503) 696-4299, Fax (503) 696-4904 INSTRUCTIONS: Please fill in the information for your company below, include: - Complete company name - Your name, or appropriate contact person or persons - Any corrections/changes to what I already have - Any additional types of information that you think is appropriate Then send your portion back to me at the above e-mail address. Please respond by 2/7/94. I'll distribute an updated copy before our next meeting on the 18th. Thanks much. - Derrick ============================================================================= Anacad Contact: Petra Osterman Email: Phone: Address: Support: AnSoft Contact: Henri Maramis Email: Phone: Address: Support: Atmel Corporation Contact: Dan Terry Email: Phone: Address: Support: Cadence Design Contact: Karen Kirkpatrick Email: karenk@cadence.com Phone: (508) 262-6448, Fax: (508) 262-6777 Address: Support: Contec Contact: Maah Sango Email: Phone: Address: Support: Digital Equipment Corp. Contact: Barry Cats Email: Phone: Address: Support: High Design Technology Contact: Michael Smith Email: Phone: Address: Support: HyperLynx Contact: Kellee Crisafulli Email: Phone: Address: Support: The Linesim Pro product supports IBIS as follows: 1) Any IBIS file can be used directly as a 'NATIVE' file (Version 3.0 or newer). 2) A single model in an IBIS file can selected, loaded, and viewed directly. 3) Several IBIS models can be included in a single file and used as a library. Note: this library file still complies completely with the IBIS specification and can be checked with the IBIS check program. IBM-Motorola (PowerPC) Contact: Lynn Warner, Soa Quoc Email: Phone: Address: Support: Integrity Engineering Contact: Greg Doyle Email: Phone: Address: Support: The Integrity Simulators and Parasitic Extractor tools, SImnet, SImnet X, and Autospice are shipped with an IBIS2IEI translation program that enables any IBIS file to be directly converted for use with the simulator or SPICE extractor. The next revisions of IEI programs, slated for delivery 2Q '94, will support IBIS models in native mode. A utility will be provided to read, edit and view IBIS files directly. Intel Corporation Contact: Will Hobbs Email: hobbswil@ccm.hf.intel.com Phone: (503) 696-4369, Fax (503) 696-4210 Address: 5200 NE Elam Young Pkwy, JF1-57 Hillsboro, OR 97124 Support: Intel provides IBIS models for some of its components. For a list of supported components, send the following message to archive@vhdl.org: path send pub/ibis/models/intel readme index /pub/ibis/models/intel Interconnectix, Inc. Contact: Bob Ross Email: Phone: Address: Support: Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. Intergraph Contact: Ian Dodd, David Wiens Email: Phone: Address: Support: IntuSoft Contact: Charles Hymowitz Email: Phone: Address: Support: Intusoft takes a customer's netlist or model and translates it into a Spice model, free of charge. Intusoft has the Golden Parser source but hasn't, as of yet, automated the process. Intusoft is waiting until there are more IBIS models available. Logic Modeling Corp. Contact: Randy Harr Email: Phone: Address: Support: Mentor Graphics Contact: Ravender Goyal Email: Phone: Address: Support: Mentor supports IBIS by using Quad Design and Intel IBIS models. Meta-Software Contact: Mei Wong Email: Phone: Address: Support: MicroSim Contact: Arthur Wong, Jerry Brown, Graham Bell Email: Phone: Address: Support: National Semiconductor Corp. Contact: Syed Huq Email: Phone: Address: Support: North Carolina State University Contact: Paul Franzon, Michael Steer, Steve Lipa Email: Phone: Address: Support: Steve Lipa will be developing a Spice to IBIS converter. slipa@eos.ncsu.edu, (919) 515-3947 Performance Signal Integrity Contact: Eric Bracken Email: Phone: Address: Support: Quad Design Contact: Jon Powell Email: jonp@qdt.com Phone: 805-988-8250 Address: Support: Quad Design has a translation program that translates from IBIS format to Quad Design .mod format. This translator uses the Golden Parser code with enhancements to warn of malformed (yet legal) models. The translator supports user input to be able to select from the min-typ-max range of IBIS data. This program (IBIS2XTK) is available now and will be generally distributed with the XTK 5.2 release (available in Feb. 1994). Quantic Labs Contact: Mike Ventham, Zhen Mu Email: Phone: Address: Support: Siemens Nixdorf Contact: Werner Rissiek, Olaf Rethmeier Email: Phone: Address: Support: Siemens Nixdorf uses the simulation program FREACS (Fast REflection And Crosstalk Simulator) for signal integrity analysis within the EMC-Workbench. Siemens can read IBIS Version 1.1 files and translate the IBIS models into FREACS models. Siemens usees an IBIS parser, developed by Siemens, and a semi-automatic process for the parametrization of the FREACS macromodels. The translation of IBIS to FREACS is available as a service for customers. A fully automated process will be developed when there are more IBIS models available. Additionally, so called 'reference lists' are set up that are used by the interface (XLIN) between the EMC-Workbench and the FREACS macromodel library. These reference lists consist of circuit informations in a special language named HINAC (Hierachical Naming Convention), where macromodel data is assigned to pins of a component using IBIS informations, as well. In this way a controlled set-up of a library is possible using IBIS-files as a basis. If necessary we will send more detailed information at any time. Texas Instruments Contact: Bob Ward Email: bward@dadhb1.ti.com Phone: (713) 274-4146, Fax (713) 274-3911 Address: Support: TI has a three-pronged attack on IBIS support. TI is working on a scheme to automatically generate IBIS models from TI Spice simulations (TI's proprietary Spice dialect), on an automatic means to generate C code to be linked in to TI Spice as a User Defined Element from an IBIS model, and an automatic means to create the Spice equivalent of the IBIS model from the IBIS model specification. The latter method differs from the second in that it uses skeletonized Spice primitive elements in the form of a subcircuit, while the second actually generates C code and compiles it for dynamic linking. Thomson-CSF/SCTF Contact: Jean Lebrun Email: Phone: Address: Support: Zeelan Technology Contact: Hiro Moriyasu, George Opsahl, Samie Samaan, Tay Wu Email: Phone: Address: Support: From bob@icx.com Sat Jan 29 21:15:52 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21243; Sat, 29 Jan 94 21:15:52 PST Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA03157 for ; Sat, 29 Jan 94 23:45:04 -0500 Date: Sat, 29 Jan 94 19:56:44 PST From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA14603; Sat, 29 Jan 94 19:56:44 PST Message-Id: <9401300356.AA14603@icx.com> To: ibis@vhdl.org Subject: BIRD 6.1 Hello IBIS members: Here is an updated BIRD6.1 to reflect the discussed and emailed changes. I would appreciate any comments or corrections from Kellee, Syed, Bob Ward, Jon, and anyone else as to whether this version meets the simulator needs and also contains information that is easily available from data sheets and from vendors. I am particularly concerned that "tskew_min" is meaningful. I am also concerned whether the normal test setup for tskew in data books which include 50pF/100pF loads gives overly pessimistic values. If you wish, you can reach me at (503) 684-6641, fax (503) 639-3469 or send email. Changes: vpp renamed to vdiff, and polarity specification modified. tskew_typ, tskew_max, tskew_min columns added. Note regarding vinl and vinh removed since it was not relevant. Analysis Path text revised and expanded. Note on vdiff notation: Motorola uses Vpp in ECLinPS family TI uses VT+ and VT- in Data Transmission Circuits Family National uses VTH in Interface Databook Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 6.1 ISSUE TITLE: Differential Pin Specification REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 12 January 1994 DATE REVISED: 29 January 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Several components contain pins which operate in a differential mode with respect to other pins. Since this operation in inherent to a component, the IBIS document should be extended to specify this functionality. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: An additional optional keyword, [Diff_Pin], is added to the specification. |========================================================================== | Keyword: [Diff_Pin] | Required: Optional |Description: Used to associate differential pins, their peak-to-peak | differential voltages and timing skews. | Sub-Params: inv_pin, vdiff, tskew_typ, tskew_min, tskew_max |Usage Rules: Entries follow these rules: Only differential pin pairs | are entered. The [Diff_pin] column contains a non-inverting | pin number and the inv_pin column always contains the | corresponding inverting pin number for output and I/O output. | The vdiff column contains the specified peak-to-peak voltage | between pins if the pins are Input or I/O Model_types. | For Output only differential pins, the vdiff entry is 0V. |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff_pin] column will be Non-Inverting and the pin in the | inv_pin column will be Inverting. This convention allows | one [Model] to be used for both pins. | | Column length limits are: | [Diff_Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tskew_typ 9 characters max | tskew_min 9 characters max | tskew_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tskew_typ or tskew_min columns, its | entry will be interpreted as 0V or 0ns. If "NA" appears in | the tskew_max column, its value will be interpreted as the | tskew_typ value. When using six columns, the headers | tskew_min and tskew_max must be listed. |--------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tskew_typ tskew_min tskew_max | 3 4 150mV 1ns 0ns 2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tskew = 0ns 22 21 NA NA | Output*, tskew = 0ns | * Could be Input or I/O with vdiff = 0V ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. The component itself may be required to convey the associations between pins for differential inputs and/or outputs. Such cases may occur in practice when pairs of pins are connected using closely-spaced, coupled nets or twisted-pair cabling. Pins which provide complimentary outputs should not be associated with each other when the analysis is normally done using only one pin at a time. However, there may be cases related to other pending extensions (package models, power association, etc.) where association of complimentary pins may be appropriate. [Diff_pin] should be used for pins designed for differential operation. Inputs of such components have a differential input sensitivity specification such as "Vpp" or "VT+" and "VT-" which defines a peak-to-peak voltage between two input pins. The vdiff column is introduced for such specification limits (as a positive value) which would trigger an output transition. One application is for timing analysis. |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT | | |<-- tmax -->| | | |<-- tmin ->|| __________ || ____________ __ \ || / A0 __\||/__ \/ vdiff DIFFERENTIAL INPUT __ /\ __ / \ __________/ \____________ A0 For timing purposes, an output is referenced to an equal voltage cross-over of output pins. Setting the vdiff entry to 0V is thus chosen when the pins are for differential outputs only. Note, the cross-over does NOT mean that the outputs are at 0V. The tskew value is the time difference between the mid-point of the two output transitions. It is equivalent to the time-delay of one pin relative to the other pin. Although an absolute value is specified, either pin can delayed relative to the other pin. This specification assumes the outputs are reasonably identical and the rise and fall transitions are reasonably similar. Tskew can be shown per National Interface Databook, diagram on pg 1-121: 3V _______________ / \ INPUT TO SAME COMPONENT 1.5V__ / \ /| |\ 0V ___/ | | \______________ | tPLH | |tPHL| ___________ __________ _________ __ ^ ^ \ / \ / ^ D0 | Vo/2 \ / \/ Vo/2 Vo v______\ /__ __|/\|_____v DIFFERENTIAL OUTPUT |\/| / \ | |/\| /| |\ v____________/ \__________/ | | \_______ D0 | | | | | | Tskew | | Tskew Tskew = |tPLH - tPHL| Conventions similar to those in [Pin] are followed with respect to required and optional column entries and to column lengths. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Introducing a [Tskew] keyword similar to [Package] (used for defaults) was suggested and could be considered as another method for dealing with skew. An alternative polarity mechanism for differential outputs could have been based on the Polarity sub-parameter within the [Model]. This was not done because Polarity is optional and also because two [Model]s would be required: one for the "Non-inverting" pin and another for the "Inverting" pin. In BIRD6.1, vdiff is used as an absolute difference regardless of polarity for Input specfication, so "polarity" no longer is applicable for inputs. However, it still may be reasonable to require two Output or I/O [Model]s for easier translation into simulator databases. In this case, the "inv_pin" name could be changed to "2nd_pin". Also, with a Polarity sub-parameter, the possibility exists that the [Models] are in phase with each other. This may be useful for double strength buffer options. ****************************************************************************** From randyh Sun Jan 30 00:22:28 1994 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22442; Sun, 30 Jan 94 00:22:28 PST Date: Sun, 30 Jan 94 00:22:28 PST From: randyh (Randy Harr) Message-Id: <9401300822.AA22442@vhdl.vhdl.org> To: ibis@vhdl.org Subject: Updated Intel model files Intel has sent in updates for their i486(tm) and Pentium(tm) PCI chipset model files. See the directory pub/ibis/models/intel. It took a little bit of handwork to get them transferred and separated onto vhdl.org. Please let Stephen Peters (speters@ichips.intel.com) or myself (randyh@vhdl.org) know if there are any problems. randy harr From 71436.1314@CompuServe.COM Sun Jan 30 16:53:43 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01868; Sun, 30 Jan 94 16:53:43 PST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id TAA02614; Sun, 30 Jan 1994 19:52:09 -0500 Date: 30 Jan 94 19:49:07 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: BIRD 6.1 Message-Id: <940131004906_71436.1314_HHB48-3@CompuServe.COM> From: Kellee Crisafulli, HyperLynx Inc. Re: Bird 6.1 This is a big improvement over 6.0, good work. As I read through 6.1, I notice something that concerned how various simulators would determine how to launch the waveform to make sure the skew time is correct as measured at the center point of the voltages. I believe this will be very difficult to accomplish. The load values and differences in how various simulators launch the edge transitions will probably cause the skew to be all over the place. The present output buffer specification does not specify where the edge actually starts relative to t=0 seconds. I know for a fact that there is a difference between at least 3 of the simulators that presently run IBIS files. Could we reference this skew time to where the simulators launch the edge changes. This should roughly correlate to the center points, however it may be slightly different depending on load conditions and simulators. This however would be reasonable for all simulators. The semiconductor companies could still measure at the center point with a fixed load. This will have some accuracy errors, however I believe that keeping it simple will allow everyone concerned to get it working quickly and easily and that is worth alot! If we use this method, I believe we should specify how to measure it, and how to simulate it. From canright@neptune.convex.com Mon Jan 31 07:22:10 1994 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11083; Mon, 31 Jan 94 07:22:10 PST Received: from neptune.convex.com by convex.convex.com (5.64/1.35) id AA15224; Mon, 31 Jan 94 09:19:51 -0600 Received: by neptune (5.64/1.28) id AA24154; Mon, 31 Jan 94 09:20:30 -0600 From: canright@neptune.convex.com (Robert Canright) Message-Id: <9401311520.AA24154@neptune> Subject: Re: BIRD 6.1 To: bob@icx.com (Bob Ross) Date: Mon, 31 Jan 94 9:20:29 CST Cc: ibis@vhdl.org, integrity@neptune.convex.com In-Reply-To: <9401300356.AA14603@icx.com>; from "Bob Ross" at Jan 29, 94 7:56 pm X-Mailer: ELM [version 2.3 PL11] > > Hello IBIS members: > > Here is an updated BIRD6.1 to reflect the discussed and emailed changes. > I would appreciate any comments or corrections from Kellee, Syed, Bob Ward, > Jon, and anyone else as to whether this version meets the simulator needs > and also contains information that is easily available from data sheets and > from vendors. I am particularly concerned that "tskew_min" is meaningful. > I am also concerned whether the normal test setup for tskew in data books > which include 50pF/100pF loads gives overly pessimistic values. If you wish, > you can reach me at (503) 684-6641, fax (503) 639-3469 or send email. Regarding your statement: "I am also concerned whether the normal test setup for tskew in data books which include 50pF/100pF loads gives overly pessimistic values." If data book numbers are copied into IBIS models without verifying simulation vs. time-domain measurements, then the data book capacitance numbers could lead to faulty simulations. Faulty simulations, even if they do provide conservative results, are a nuisance. We don't like finding out that we have spent labor fixing problems that didn't really exist. We rank models based on our confidence in them & models created from data book info have the lowest ranking. The same driver with 2 different package models can have very different waveforms. If an IBIS model uses data book info, the model should have a disclaimer to say so. -- Bob Canright Convex Computer Corp. Richardson, Texas 214-497-4474 (desk) canright@convex.com 214-497-4500 (FAX) disclaimer: It's not my typing, the Sun keyboard repeeeatsss. From ccm!Will_Hobbs@intelhf.intel.com Mon Jan 31 15:19:19 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16942; Mon, 31 Jan 94 15:19:19 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pR7pY-000MNqC; Mon, 31 Jan 94 15:14 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pR7sL-000048C; Mon, 31 Jan 94 15:17 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 31 Jan 94 15:17:48 PST Date: Mon, 31 Jan 94 15:17:48 PST From: Will Hobbs Message-Id: <940131151748_13@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, canright@neptune.convex.com, bob@icx.com Cc: ibis@vhdl.org, integrity@neptune.convex.com Subject: Re[2]: BIRD 6.1 Bob, et al, Just to reassure you, the main reason IC vendors' participation is so crucial to IBIS is that they have the proper equipment and design and technology databases needed to create the IBIS models. Some companies also can generate them from characterizing ICs. To date, I am unaware of anyone creating an IBIS model from published data book data, except when the data was already in IBIS format, such as the 82430 PCIset from Intel. Regarding where to get tskew information, again, I don't feel the data books are the right place to go, either. Regards, Will Hobbs Intel Corp. > > Hello IBIS members: > > Here is an updated BIRD6.1 to reflect the discussed and emailed changes. > I would appreciate any comments or corrections from Kellee, Syed, Bob Ward, > Jon, and anyone else as to whether this version meets the simulator needs > and also contains information that is easily available from data sheets and > from vendors. I am particularly concerned that "tskew_min" is meaningful. > I am also concerned whether the normal test setup for tskew in data books > which include 50pF/100pF loads gives overly pessimistic values. If -you wish, > you can reach me at (503) 684-6641, fax (503) 639-3469 or send email. Regarding your statement: "I am also concerned whether the normal test setup for tskew in data books which include 50pF/100pF loads gives overly pessimistic values." If data book numbers are copied into IBIS models without verifying simulation vs. time-domain measurements, then the data book capacitance numbers could lead to faulty simulations. Faulty simulations, even if they do provide conservative results, are a nuisance. We don't like finding out that we have spent labor fixing problems that didn't really exist. We rank models based on our confidence in them & models created from data book info have the lowest ranking. The same driver with 2 different package models can have very different waveforms. If an IBIS model uses data book info, the model should have a disclaimer to say so. -- Bob Canright Convex Computer Corp. Richardson, Texas 214-497-4474 (desk) canright@convex.com 214-497-4500 (FAX) disclaimer: It's not my typing, the Sun keyboard repeeeatsss. From huq@rockie.nsc.com Mon Jan 31 16:56:27 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17956; Mon, 31 Jan 94 16:56:27 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA29472 for ibis@vhdl.org; Mon, 31 Jan 94 16:54:53 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA24407 for ibis@vhdl.org; Mon, 31 Jan 94 16:54:52 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04989; Mon, 31 Jan 94 16:58:41 PST Date: Mon, 31 Jan 94 16:58:41 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9402010058.AA04989@rockie.nsc.com> To: ibis@vhdl.org Subject: comments on BIRD 6.1 Cc: huq@rockie.nsc.com Hi Bob Ross, I have read thru your BIRD 6.1 and have also seen some of the comments from other fellow IBIS members. Overall it looks good. One thing I want to be clear about is [Diff_Pin] and inv_pin are for a Differential receivers input pins and in that case vdiff is the peak-to-peak voltage of the receiver inputs. vdiff can also be the differential output of a driver. In that case it is assiged 0V(differential not ground-just as your note says). 0 volts differential shows only the cross over points of the driver outputs. I know we only talk about skews but can Differential Prop delay be measured thru the simulators. For example, for the driver this would mean the delay from 1.5V(input) to the 0v(differntial output). Also, last point, us semiconductor vendors do an extensive characterization on each device across Vcc, temp, process corners and package types to gather data. We do not base our simulations on datasheet numbers only. Thanks Will for pointing that out too. If we create IBIS files, our data will be based on the above mentioned. Regards, Syed.