From owner-ibis Tue Mar 4 11:39:44 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id LAA26305 for ; Tue, 4 Mar 1997 11:39:43 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA28963 for ; Tue, 4 Mar 1997 11:35:54 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V3.1.1) id xma015162; Tue, 4 Mar 97 11:16:08 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28726 for ibis-users@vhdl.org; Tue, 4 Mar 97 11:17:55 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA25665; Tue, 4 Mar 97 11:20:32 PST Date: Tue, 4 Mar 97 11:20:32 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9703041920.AA25665@rockie.nsc.com> To: ibis-users@vhdl.org Subject: about offseting the pu and pc Hi, I have a ques on the Vcc offseting of the pu(Pullup) and pc(Power Clamp) V/I data. I am creating a CMOS model with 3.3V supply. This means TYP=3.3V, MIN=3.0V and MAX=3.6V There is 'one' voltage table for the three current table. When I use the Vtable = Vcc - Vmeas to offset the voltage table, 'Which' Vcc should be used ?? If I use 3.3V, only the TYP curve goes thru the 0,0 point and the MIN and MAX will not ! The 0,0 point is when Vcc=Voh (pu curve) I am not sure how s2ibis2 handles this issue. Pls comment. Regards, Syed. National Semiconductor Corp. From owner-ibis Tue Mar 4 12:36:51 1997 Received: from mail2c.pilot.net (mail2.pilot.net [198.232.147.16]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA27165 for ; Tue, 4 Mar 1997 12:36:49 -0800 (PST) Received: from idt.com (unknown-5-20.idt.com [157.165.5.20]) by mail2c.pilot.net with SMTP id MAA25435; Tue, 4 Mar 1997 12:35:02 -0800 (PST) Received: from Eng.idt.com (root@maxwell.Eng.idt.com [157.165.21.24]) by idt.com (8.6.12/8.6.12) with ESMTP id MAA23959; Tue, 4 Mar 1997 12:34:41 -0800 Received: from hermes.Eng.idt.com (hermes.Eng.idt.com [157.165.41.92]) by Eng.idt.com (8.6.12/8.6.12) with ESMTP id MAA16193 ; Tue, 4 Mar 1997 12:35:00 -0800 From: Arthur Wong Received: (arthur@localhost) by hermes.Eng.idt.com (8.6.12/8.6.12) id MAA00523; Tue, 4 Mar 1997 12:34:58 -0800 Date: Tue, 4 Mar 1997 12:34:58 -0800 Message-Id: <199703042034.MAA00523@hermes.Eng.idt.com> To: ibis-users@vhdl.org, huq@rockie.nsc.com Subject: Re: about offseting the pu and pc Hi Syed, s2ibis2 uses the supply voltage corresponding to the current column. For example, Vcc=3.0v for the min current column; Vcc=3.6v for the max column. This would make all three curves go through the origin. Regards, Arthur Wong IDT > From owner-ibis@vhdl.vhdl.org Tue Mar 4 11:51:05 1997 > Date: Tue, 4 Mar 97 11:20:32 PST > From: huq@rockie.nsc.com (Syed Huq) > To: ibis-users@vhdl.org > Subject: about offseting the pu and pc > Content-Length: 570 > > Hi, > > I have a ques on the Vcc offseting of the pu(Pullup) and > pc(Power Clamp) V/I data. > > I am creating a CMOS model with 3.3V supply. This means > TYP=3.3V, MIN=3.0V and MAX=3.6V > > There is 'one' voltage table for the three current table. > When I use the Vtable = Vcc - Vmeas to offset the voltage > table, 'Which' Vcc should be used ?? > > If I use 3.3V, only the TYP curve goes thru the 0,0 point > and the MIN and MAX will not ! The 0,0 point is when > Vcc=Voh (pu curve) > > I am not sure how s2ibis2 handles this issue. > > Pls comment. > > Regards, > Syed. > National Semiconductor Corp. > From owner-ibis Tue Mar 4 12:37:26 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA27170 for ; Tue, 4 Mar 1997 12:37:25 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id MAA02514 for ; Tue, 4 Mar 1997 12:35:37 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id MAA02283; Tue, 4 Mar 1997 12:28:33 -0800 (PST) Message-Id: <199703042028.MAA02283@ichips.intel.com> To: ibis-users@vhdl.org Subject: about offseting the pu and pc Date: Tue, 04 Mar 1997 12:35:45 -0800 From: Stephen Peters Hello Syed: I'm not sure about s2ibis2, but when I have created models I have always adjusted the Vcc in the Vtable = Vcc - Vmeas equation to follow Min, Typ and Max voltages. In other words, all three columns in the pullup table have a 0,0 entry. Regards, Stephen Peters Intel Corp. Hi, I have a ques on the Vcc offseting of the pu(Pullup) and pc(Power Clamp) V/I data. I am creating a CMOS model with 3.3V supply. This means TYP=3.3V, MIN=3.0V and MAX=3.6V There is 'one' voltage table for the three current table. When I use the Vtable = Vcc - Vmeas to offset the voltage table, 'Which' Vcc should be used ?? If I use 3.3V, only the TYP curve goes thru the 0,0 point and the MIN and MAX will not ! The 0,0 point is when Vcc=Voh (pu curve) I am not sure how s2ibis2 handles this issue. Pls comment. Regards, Syed. National Semiconductor Corp. From owner-ibis Tue Mar 4 13:17:05 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA27842 for ; Tue, 4 Mar 1997 13:17:04 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Tue, 4 Mar 1997 21:15:23 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id NAA07900 for ibis-users@vhdl.org; Tue, 4 Mar 1997 13:17:41 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 04 Mar 97 13:17:41 PST Date: Tue, 04 Mar 97 13:07:00 PST From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org Subject: Re: about offseting the pu and pc Text item: Syed, The equation Vtable = Vcc - Vmeas assumes that you are measuring the output voltage with respect to ground while you are sweeping the device. When you select the sweeping range for a 5 volt device, you will have to sweep 5 volts above Vcc and 10 volts below Vcc, which is -5 to +10 volts in ground relative terms for the typical case. Now, if you move Vcc +- 5% for min and max, you will use 4.75 and 5.25 volts. Using these Vcc numbers, you will still have to sweep 5 volts above and 10 volts below Vcc, which translates to -5.25 to 9.75 for the minimum and -4.75 to 10.25 volts for the maximum curves (in ground relative mode). Imagine a circuit that has a variable voltage source connected between the Vcc and output pins to do this sweep. Notice that the sweeper does the same thing regardless of what Vcc is. It forces the output pin 5 volts above and 10 volts below the Vcc voltage for all three cases (typ, min, max). This is the voltage axis of the I-V tables in IBIS. Also note that if your sweeper is at 0 volts in the above configuration, the output to Vcc difference is equal to 0 volts. If you have a CMOS device driving high, it will give you 0 amps regardless of what Vcc is. Therefore you will get the zeroes all lined up at 0,0 for all three cases (typ, min, max). (Your stement below is incorrect regarding this). You can achieve the same results if you seep the pullup in a ground relative mode. In that case the variable voltage source is between GND and the output. If your device is driving high, you will get 0 mA when your sweep voltage equals Vcc. For the three cases (typ, min, max) this will be at 5.0, 4.75, and 5.25 volts, respectively. So you will get 5.0V,0mA 4.75V,0mA and 5.25V,0mA where the voltages are your Vmeas. Aplying the equation Vtable = Vcc - Vmeas you get the following three voltages for Vtable typ, min and max: Vtable_typ = Vcc_typ - Vmeas_typ ---> 5.00 - 5.00 = 0 Vtable_min = Vcc_min - Vmeas_min ---> 4.75 - 4.75 = 0 Vtable_max = Vcc_max - Vmeas_max ---> 5.25 - 5.25 = 0 That is how they line up in the Vcc relative mode. I know this can be cunfusing, but I tried my best to explain it. I hope it helped. Sorry, but I do not know how s2ibis handles this. Arpad =============================================================================== Hi, I have a ques on the Vcc offseting of the pu(Pullup) and pc(Power Clamp) V/I data. I am creating a CMOS model with 3.3V supply. This means TYP=3.3V, MIN=3.0V and MAX=3.6V There is 'one' voltage table for the three current table. When I use the Vtable = Vcc - Vmeas to offset the voltage table, 'Which' Vcc should be used ?? If I use 3.3V, only the TYP curve goes thru the 0,0 point and the MIN and MAX will not ! The 0,0 point is when Vcc=Voh (pu curve) I am not sure how s2ibis2 handles this issue. Pls comment. Regards, Syed. National Semiconductor Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: about offseting the pu and pc To: ibis-users@vhdl.org Message-Id: <9703041920.AA25665@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Tue, 4 Mar 97 11:20:32 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA25665; Tue, 4 Mar 97 11:20:32 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28726 for ibis-users@vhdl.org; Tue, 4 Mar 97 11:17:55 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V3.1.1) id xma015162; Tue, 4 Mar 97 11:16:08 -0800 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA2896 3 for ; Tue, 4 Mar 1997 11:35:54 -0800 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl. vhdl.org (8.8.5/8.8.3) with SMTP id LAA26305 for ; Tue, 4 M ar 1997 11:39:43 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id LAA23303; Tue, 4 Mar 1997 11:50:48 -0800 (PST) Received: from ormail.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0w20Gl-000qHHC; Tue, 4 Mar 97 11:53 PST From owner-ibis Tue Mar 4 13:30:15 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id NAA28043 for ; Tue, 4 Mar 1997 13:30:13 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id NAA25150; Tue, 4 Mar 1997 13:26:23 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V3.1.1) id xma020004; Tue, 4 Mar 97 13:19:34 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA08763 for ibis-users@vhdl.org; Tue, 4 Mar 97 13:21:31 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA28418; Tue, 4 Mar 97 13:24:11 PST Date: Tue, 4 Mar 97 13:24:11 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9703042124.AA28418@rockie.nsc.com> To: ibis-users@vhdl.org, huq@rockie.nsc.com, Arthur.Wong@idt.com Subject: Re: about offseting the pu and pc Aurtur, If each voltage table gets offset by it's respective Vcc, how do you still end up with one voltage col that is applicable to all three current columns ? For example, If I sweep from Vcc to 2Vcc, I get the following For TYP, sweep range is : 3.3V to 6.6V MIN, sweep range is : 3.0V to 6.0V MAX, sweep range is : 3.6V to 7.2V After Vcc offset for each table, TYP range is : 0.0 to -3.3V (offset by 3.3V) MIN range is : 0.0 to -3.0V (offset by 3.0V) MAX range is : 0.0 to -3.6V (offest by 3.6V) How do you end up with one voltage col that is applicable to all there current columns ?? The datapoints are different for each voltage table. Regards, Syed. > From arthur@idt.com Tue Mar 4 12:46:09 1997 > From: Arthur Wong > Date: Tue, 4 Mar 1997 12:34:58 -0800 > To: ibis-users@vhdl.org, huq@rockie.nsc.com > Subject: Re: about offseting the pu and pc > > > Hi Syed, > > s2ibis2 uses the supply voltage corresponding to the current column. > For example, Vcc=3.0v for the min current column; Vcc=3.6v for the max column. > > This would make all three curves go through the origin. > > Regards, > Arthur Wong > IDT > > > > From owner-ibis@vhdl.vhdl.org Tue Mar 4 11:51:05 1997 > > Date: Tue, 4 Mar 97 11:20:32 PST > > From: huq@rockie.nsc.com (Syed Huq) > > To: ibis-users@vhdl.org > > Subject: about offseting the pu and pc > > Content-Length: 570 > > > > Hi, > > > > I have a ques on the Vcc offseting of the pu(Pullup) and > > pc(Power Clamp) V/I data. > > > > I am creating a CMOS model with 3.3V supply. This means > > TYP=3.3V, MIN=3.0V and MAX=3.6V > > > > There is 'one' voltage table for the three current table. > > When I use the Vtable = Vcc - Vmeas to offset the voltage > > table, 'Which' Vcc should be used ?? > > > > If I use 3.3V, only the TYP curve goes thru the 0,0 point > > and the MIN and MAX will not ! The 0,0 point is when > > Vcc=Voh (pu curve) > > > > I am not sure how s2ibis2 handles this issue. > > > > Pls comment. > > > > Regards, > > Syed. > > National Semiconductor Corp. > > > From owner-ibis Tue Mar 4 14:17:12 1997 Received: from c11167-343dan.ece.ncsu.edu (c11167-343dan.ece.ncsu.edu [152.1.59.242]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA28948 for ; Tue, 4 Mar 1997 14:17:11 -0800 (PST) From: awglaser@eos.ncsu.edu Received: (from awglaser@localhost) by c11167-343dan.ece.ncsu.edu (8.8.4/EC02Jan97) id RAA16718; Tue, 4 Mar 1997 17:15:25 -0500 (EST) Message-Id: <199703042215.RAA16718@c11167-343dan.ece.ncsu.edu> Subject: Re: about offseting the pu and pc To: huq@rockie.nsc.com (Syed Huq) Date: Tue, 4 Mar 1997 17:15:24 -0500 (EST) Cc: ibis-users@vhdl.org In-Reply-To: <9703042124.AA28418@rockie.nsc.com> from "Syed Huq" at Mar 4, 97 01:24:11 pm X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Syed, This is handled by fixing the sweep range for all three curves to be equal to the TYP curve sweep range, and then - if it's a ground clamp or pulldown curve, setting the sweep starting voltage to be the same for all three columns. Thus you get: TYP: -3.3V to 6.6V MIN: -3.3V to 6.6V MAX: -3.3V to 6.6V - if it's a power clamp or pullup curve, offsetting the sweep starting voltage for the MIN and MAX columns by (Vcc_min - Vcc_typ) and (Vcc_max - Vcc_typ), respectively. Thus you get: TYP: 6.6V to -3.3V (Vcc = Vcc_typ = 3.3V) MIN: 6.3V to -3.6V (Vcc = Vcc_min = 3.0V) MAX: 6.9V to -3.0V (Vcc = Vcc_max = 3.6V) Thus for all three columns Vtable is the same. Regards, Alan > If each voltage table gets offset by it's respective Vcc, how > do you still end up with one voltage col that is applicable > to all three current columns ? > > For example, If I sweep from Vcc to 2Vcc, I get the following > > For TYP, sweep range is : 3.3V to 6.6V > MIN, sweep range is : 3.0V to 6.0V > MAX, sweep range is : 3.6V to 7.2V > > After Vcc offset for each table, > > TYP range is : 0.0 to -3.3V (offset by 3.3V) > MIN range is : 0.0 to -3.0V (offset by 3.0V) > MAX range is : 0.0 to -3.6V (offest by 3.6V) > > How do you end up with one voltage col that is applicable to > all there current columns ?? The datapoints are different for > each voltage table. -- Alan Glaser "It's not a competition, ECE Dept. it's just a mint..." - K North Carolina State University From owner-ibis Mon Mar 10 17:10:08 1997 Received: from icx.com (fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id RAA19443; Mon, 10 Mar 1997 17:10:07 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 10 Mar 97 17:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 10 Mar 97 17:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 10 Mar 97 17:09 PST Message-Id: Date: Mon, 10 Mar 97 17:09 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org, ibis@vhdl.org Subject: IBISCHK2+ EXECUTABLES To All: ibischk2+ executables are now available for downloading under ftp://vhdl.org/pub/ibis/ibschk2+ They contain additional checks for data values. They are beta versions at this time, pending feedback from users. Thanks to Chris Rokusek of Quad Design/Viewlogic for providing these executables. Attached is part of the CHANGES document: Best Regards Bob Ross Interconnectix Ibischk2 Users, Version 2.1.3 of ibischk2 contains the following additional checks. 1) Checks ac waveform end points against dc Vi curves. 2) Checks test load Rref to Vref can be driven through Vmeas. 3) Checks for large currents due to inaccurate shunt diodes 4) Checks c_comp for large values ( > 1 nF) 5) Checks r/f ramp_times for large values ( > 1 ms) 6) Checks pin C for large values ( > 1 nF) 7) Checks pin R for large values ( > 1 kOhm) 8) Checks pin L for large values ( > 1 uH) Chris Rokusek Quad Design/Viewlogic crokusek@qdt.com From owner-ibis Fri Mar 14 06:30:51 1997 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA13618 for ; Fri, 14 Mar 1997 06:30:49 -0800 (PST) Received: from dsy-srv3.cern.ch (dsy-srv3.cern.ch [137.138.128.23]) by dxmint.cern.ch with SMTP id PAA01804 for ; Fri, 14 Mar 1997 15:27:52 +0100 (MET) Received: from sunmarco.cern.ch by dsy-srv3.cern.ch (SMI-8.6/SMI-4.0) id PAA15886; Fri, 14 Mar 1997 15:27:50 +0100 From: fzanogue@dsy-srv3.cern.ch (Zanogue Maria-Francisca) Received: by sunmarco.cern.ch (SMI-8.6/client-1.5) id PAA15338; Fri, 14 Mar 1997 15:27:52 +0100 Date: Fri, 14 Mar 1997 15:27:52 +0100 Message-Id: <199703141427.PAA15338@sunmarco.cern.ch> To: ibis-users@vhdl.org Subject: Problems with s2ibis2 Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 19 Hello, I have some problems with s2ibis2 version 1.0, and hope you can help me. I'm trying to create a model for an ECL output gate, and although all the intermediate files seem to be OK, I get a wrong .ibs file (it means a lot of zeros added to the voltage column in pullup and pulldown curves, and for the pulldown curve the 'voltage' and 'I(typ)' fields are swapped). Also, I run the program on Solaris 2.1 and on SunOS4 with the same files, and in one case I get a 'Bus Error' message and the program crashes, and in the other case I simply get wrong results, but there's neither crash nor error message. As intermediate files are correct, I don't think the problem is in the spice circuit. Does anyone have experience running s2ibis2 with ECL gates? I'd like to see an input file for an ECL model, as it's my first attempt to run the s2ibis converter and I'm not sure mine is correct. I've attached it in case you want to have a look at it. Thank you all. Francisca. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: eclinps.s2i X-Sun-Charset: us-ascii X-Sun-Content-Lines: 45 |INPUT FILE FOR S2IBIS2 CONVERSION FOR AN ECL GATE [IBIS Ver] 2.1 [File rev] 0 [Spice type] PSpice [Spice command] pspice %s %s [Iterate] [Sim time] 5ns [Temperature Range] 27 27 27 [Vil] -1.7V -1.7V -1.7V [Vih] -0.9V -0.9V -0.9V [Tr] 0.1ns 0.1ns 0.1ns [Tf] 0.1ns 0.1ns 0.1ns [Component] eclinps_gate [Spice file] peclinps.cir [Pin mapping] 1 NC NC NC NC 2 vee vcc NC NC 3 vee vcc NC NC 4 NC vcc NC NC 5 vee NC NC NC [Pin] 1 1 input dummy 2 11 out1 ecl_output -> 1 3 77 out2 ecl_output -> 1 4 100 vcc POWER 5 113 vee GND [Model] dummy [NoModel] [Model] ecl_output [Model Type] Output_ECL [Pullup Reference] 0V 0V 0V [Pulldown Reference] 0V 0V 0V [POWER Clamp Reference] 0V 0V 0V [GND Clamp Reference] -4.5V -4.5V -4.5V [Rref] 50 From owner-ibis Thu Mar 20 14:09:29 1997 Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id OAA04045; Thu, 20 Mar 1997 14:09:23 -0800 (PST) Received: from salope.cse.tek.com by inet1.tek.com id ; Thu, 20 Mar 1997 14:06:47 -0800 Received: from salope (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with SMTP id OAA05855; Thu, 20 Mar 1997 14:06:47 -0800 (PST) Sender: brockh@mdhost.cse.tek.com Message-ID: <3331B4F7.47F3@mdhost.cse.tek.com> Date: Thu, 20 Mar 1997 14:06:47 -0800 From: Brock Hannibal X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ibis@vhdl.org CC: awglaser@eos.ncsu.edu, ibis-users@vhdl.org, bob@icx.com Subject: s2ibis2 Content-Type: multipart/mixed; boundary="------------46BC211D71CE" This is a multi-part message in MIME format. --------------46BC211D71CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I've been trying to run some of the examples in the v1.1 distribution of s2ibis2. I'm using Hspice. I'm admittedly not very familiar with Hspice since we have our own internal Spice. Unfortunately converinting hspice to our internal Spice is not an option at the moment.I get the following standard output: [salope:ex2] /proj/cae/brockh/data/icx/ibis/tools/s2ibis2/bin/s2ibis2.solaris tristate.s2i s2ibis2.solaris v1.1 -- North Carolina State University s2ibis2.solaris: Reading input file tristate...done. s2ibis2.solaris: Analyzing component MCM Trisate Driver . s2ibis2.solaris: Starting HSpice job with input putout.spi. s2ibis2.solaris: Spice run (TYP) aborted. See file putout.msg for information. Curve pullup not generated. s2ibis2.solaris: Starting HSpice job with input dutout.spi. s2ibis2.solaris: Spice run (TYP) aborted. See file dutout.msg for information. Curve pullup (output disabled) not generated. Any clue as to why the pullup and pulldown curves aren't generated. I looked in the putout.spi file and it looks OK to me but I'll attach it. The file putout.msg is very short and looks like this: ^G>error ***** hspice job aborted real 7.0 user 0.5 sys 0.2 Thanks for any insight you may have. I've fiddled around quite a bit and am just not seeing the problem or oversight. -- Brock Hannibal Hardware Design Engineer Tektronix, Inc. Beaverton, Oregon "Any ideas or opinions expressed here do not necessarily reflect the ideas or opinions of my employer." --------------46BC211D71CE Content-Type: text/plain; charset=us-ascii; name="putout.spi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="putout.spi" * Typ pullup curve for model tristate_driver * * Spice deck created by s2ibis v 1.1 * North Carolina State University * minva vdd enable nena vdd pfet w=3.6e-06 l=6e-07 ad=2.1015e-11 as=5.4e-12 +pd=2.355e-05 ps=6.6e-06 minvb gnd enable nena gnd nfet w=1.8e-06 l=6e-07 ad=1.107e-11 as=2.7e-12 +pd=1.35e-05 ps=4.8e-06 mx33 n5 enable vdd vdd pfet w=3.84e-05 l=6e-07 ad=5.76e-11 as=5.76e-11 +pd=4.14e-05 ps=4.14e-05 mx24 n5 in n2 vdd pfet w=3.6e-06 l=6e-07 ad=2.1015e-11 as=5.4e-12 pd=2.355e-05 +ps=6.6e-06 mx25 n3 n2 n5 vdd pfet w=1.41e-05 l=6e-07 ad=2.115e-11 as=2.1015e-11 +pd=1.71e-05 ps=2.355e-05 mx27 n5 n3 n4 vdd pfet w=3.21e-05 l=6e-07 ad=9.3915e-11 as=2.889e-11 +pd=1.0125e-05 ps=1.8e-06 mx26 n4 n3 n5 vdd pfet w=3.21e-05 l=6e-07 ad=2.889e-11 as=4.815e-11 pd=1.8e-06 +ps=3.51e-05 mx32 out n4 n5 vdd pfet w=4.215e-05 l=9e-07 ad=1.0116e-10 as=7.587e-11 +pd=4.695e-05 ps=3.6e-06 mx31 n5 n4 out vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=7.587e-11 +pd=3.6e-06 ps=3.6e-06 mx30 out n4 n5 vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=7.587e-11 +pd=3.6e-06 ps=3.6e-06 mx29 n5 n4 out vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=7.587e-11 +pd=3.6e-06 ps=3.6e-06 mx28 out n4 n5 vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=9.3915e-11 +pd=3.6e-06 ps=1.0125e-05 mx14 n7 in n2 gnd nfet w=1.8e-06 l=6e-07 ad=1.107e-11 as=2.7e-12 pd=1.35e-05 +ps=4.8e-06 mx23 gnd nena n7 gnd nfet w=3.6e-05 l=6e-07 ad=5.4e-11 as=5.4e-11 pd=3.9e-05 +ps=3.9e-05 mx15 n3 n2 n7 gnd nfet w=7.2e-06 l=6e-07 ad=1.08e-11 as=1.107e-11 pd=1.02e-05 +ps=1.35e-05 mx17 n7 n3 n4 gnd nfet w=1.62e-05 l=6e-07 ad=4.725e-11 as=1.458e-11 +pd=7.575e-06 ps=1.8e-06 mx16 n4 n3 n7 gnd nfet w=1.62e-05 l=6e-07 ad=1.458e-11 as=2.43e-11 pd=1.8e-06 +ps=1.92e-05 mx22 out n4 n7 gnd nfet w=2.115e-05 l=9e-07 ad=5.076e-11 as=3.807e-11 +pd=2.595e-05 ps=3.6e-06 mx21 n7 n4 out gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=3.807e-11 +pd=3.6e-06 ps=3.6e-06 mx20 out n4 n7 gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=3.807e-11 +pd=3.6e-06 ps=3.6e-06 mx19 n7 n4 out gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=3.807e-11 +pd=3.6e-06 ps=3.6e-06 mx18 out n4 n7 gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=4.725e-11 +pd=3.6e-06 ps=7.575e-06 * N56S SPICE BSIM1 (Berkeley Level 4; HSPICE Level 13) PARAMETERS * *NMOS PARAMETERS * .MODEL nfet NMOS LEVEL=13 VFB0= +-6.67767E-01,-9.88313E-03,-3.29367E-02 + 8.60647E-01, 0.00000E+00, 0.00000E+00 + 8.17935E-01,-4.65708E-02, 4.75791E-02 + 4.25774E-02, 3.52629E-02,-2.77046E-03 +-6.14649E-05, 1.89078E-02,-1.18479E-02 + 5.83829E+02,1.40291E-001,5.07562E-001 + 3.29586E-01, 9.77520E-02,-9.32319E-02 + 1.99382E-02, 3.61973E-02,-2.86830E-03 + 1.29121E+01,-8.28086E+00, 6.90864E+00 + 7.54028E-04,-3.43366E-03, 5.18763E-04 + 2.37991E-04,-1.61033E-03,-5.39861E-03 +-6.35761E-03,-3.86200E-03, 5.33022E-03 +-5.68012E-04, 1.22523E-03, 2.85097E-04 + 6.84165E+02,-2.54285E+01, 9.21339E-01 + 4.89160E+00,-1.90933E+00, 7.94142E+00 + 4.83048E+00, 4.02423E+00,-5.33716E+00 + 7.20765E-03,-1.37194E-04,-3.70674E-03 +1.00000E-002, 2.70000E+01, 5.00000E+00 +3.63E-010,3.63E-010,4.52505E-010 +1.00000E+000,0.00000E+000,0.00000E+000 +1.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 * *N+ diffusion:: * +2.4, 7.732100e-04, 2.900000e-10, 1e-08, 0.8 +0.8, 1.10106, 0.26, 0, 0 * *PMOS PARAMETERS * .MODEL pfet PMOS LEVEL=13 VFB0= +-6.59693E-02,-1.78327E-02,-2.45473E-03 + 7.68179E-01, 0.00000E+00, 0.00000E+00 + 2.85648E-01,-1.64579E-02, 3.08917E-02 +-6.62532E-02, 2.49518E-02, 4.62778E-04 +-7.90844E-03, 1.92294E-02,-2.34646E-03 + 1.41704E+02,2.14000E-001,5.34406E-001 + 1.95407E-01, 6.22059E-02,-5.94668E-02 + 8.56390E-03, 1.39477E-02, 7.65802E-04 + 6.79470E+00,-1.43654E+00, 6.56475E-01 + 1.08483E-04,-1.24539E-03, 9.77240E-05 + 4.33468E-04, 1.42453E-04,-1.71650E-03 + 8.73535E-03,-1.31646E-03, 4.78072E-04 + 3.06834E-04, 4.41194E-04, 3.49198E-04 + 1.47746E+02, 1.78644E+01, 1.24739E-01 + 6.09155E+00,-1.61404E-01, 1.24507E+00 +-3.18656E-01, 2.79732E+00, 1.71058E+00 +-1.22826E-03, 1.06181E-04, 1.07711E-03 +1.00000E-002, 2.70000E+01, 5.00000E+00 +5.540E-010,5.54E-010,4.67045E-010 +1.00000E+000,0.00000E+000,0.00000E+000 +1.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 * *P+ diffusion:: * +2.1, 9.319100e-04, 1.563700e-10, 1e-08, 0.85 +0.85, 0.487073, 0.47848, 0, 0 * simple diode model .model clamp d vj=0.7 rs=100 VOUTS2I out 0 DC 0 VCCS2I vdd 0 DC 3.3 VGNDS2I gnd 0 DC 0 VENAS2I enable 0 DC 0 VINS2I in 0 DC 3.3 .TEMP 27 .OPTIONS INGOLD=2 .DC VOUTS2I -3.3 6.6 0.1 .PRINT DC I(VOUTS2I) .END --------------46BC211D71CE-- From owner-ibis Thu Mar 20 17:41:43 1997 Received: from netcomsv.netcom.com (uucp13.netcom.com [163.179.3.13]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id RAA07796 for ; Thu, 20 Mar 1997 17:41:42 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA07031; Thu, 20 Mar 1997 17:33:55 -0800 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA24392; Thu, 20 Mar 97 10:20:17 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA22103; Thu, 20 Mar 1997 10:27:34 +0800 Date: Thu, 20 Mar 1997 10:27:34 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9703201827.AA22103@contec13.contec.COM> To: ibis-users@vhdl.org Subject: Question - BIRD 36.2 - Electrical Board Description Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Hello, The present version of BIRD 36.2 allows the description of only un-coupled lines. I would like to know if the users and designers think that this description is adequate for them. It will not be possible to use the IBIS models to analyze crosstalk due to interconnects. Dileep Divekar From owner-ibis Fri Mar 21 04:36:20 1997 Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id EAA17891 for ; Fri, 21 Mar 1997 04:36:18 -0800 (PST) From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Type: text Message-Id: <9703210737.ZM11082@eagle> Date: Fri, 21 Mar 1997 07:37:36 -0500 In-Reply-To: dileep@contec.contec.COM (Dileep Divekar) "Question - BIRD 36.2 - Electrical Board Description" (Mar 20, 10:27am) References: <9703201827.AA22103@contec13.contec.COM> X-Mailer: Z-Mail (2.1.4 02apr93) To: dileep@contec.contec.COM (Dileep Divekar), ibis-users@vhdl.org Subject: Re: Question - BIRD 36.2 - Electrical Board Description It sure beats the lumped load approach for DIMM/SIMMs. My experience is that (on DIMM/SIMM boards) uncoupled models hit 90%+ of fight time and RAS/CAS like fidelity issues. Hopefully a DIMM/SIMM mfg. has done parallelism checks. :-) ... Richard Mellitz, NCR On Mar 20, 10:27am, Dileep Divekar wrote: > Subject: Question - BIRD 36.2 - Electrical Board Description > Hello, > The present version of BIRD 36.2 allows the description > of only un-coupled lines. I would like to know if the > users and designers think that this description is adequate > for them. It will not be possible to use the IBIS models > to analyze crosstalk due to interconnects. > Dileep Divekar >-- End of excerpt from Dileep Divekar From owner-ibis Fri Mar 21 07:43:37 1997 Received: from wotan.compaq.com (root@wotan.compaq.com [207.18.199.254]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id HAA21071 for ; Fri, 21 Mar 1997 07:43:32 -0800 (PST) Received: from mail.compaq.com(really [207.18.199.36]) by wotan.compaq.com via smtpd with smtp id for ; Fri, 21 Mar 97 09:41:43 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: from galois.eng.hou.compaq.com(really [131.168.159.131]) by mail.compaq.com via sendmail with smtp id for ; Fri, 21 Mar 97 09:41:41 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: by galois.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0w86Rp-00026kC; Fri, 21 Mar 97 09:41 CST Message-Id: Date: Fri, 21 Mar 97 09:41 CST From: beal@galois.eng.hou.compaq.com (Weston Beal) To: ibis-users@vhdl.org Subject: s2ibis error Someone had a problem with S2IBIS a couple of days ago. I extracted the mail message and hastily chopped off the header in order to run the spice file include, so I don't know who sent it. Anyway, the problem was rather simple. The circuit doesn't converge at -3.3V. Just decrease the DC sweep to -1.5V to 5.0V and the circuit runs under HSPICE 96.1. This doesn't go to the limits that IBIS asks for, but on the other hand, the current at 5.0V is already 1.936e+11A. The model isn't well defined outside it's normal operating range. Sometimes we take whatever we can get, eh. Later, -- Weston Beal Signal Integrity Engineer beal@twisto.compaq.com beal@bangate.compaq.com "A little bit of knowledge is a dangerous thing" From owner-ibis Fri Mar 21 08:25:20 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA21858 for ; Fri, 21 Mar 1997 08:25:18 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA28466 for ; Fri, 21 Mar 1997 08:23:11 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA26255; Fri, 21 Mar 1997 08:13:44 -0800 (PST) Message-Id: <199703211613.IAA26255@ichips.intel.com> To: ibis-users@vhdl.org Subject: Question - BIRD 36.2 - Electrical Board Description Date: Fri, 21 Mar 1997 08:23:20 -0800 From: Stephen Peters Hello Dileep: Yes, the present description -- by design-- does not allow for describing coupling bettween traces. If a user does wish to give enough information about a board in order to do coupling the best medium in a physical description (PCB data base). This takes advantage of the vendors already existing path into there products, and there are now hooks into EDIF 4.0 that will call out IBIS files. Regards, Stephen Hello, The present version of BIRD 36.2 allows the description of only un-coupled lines. I would like to know if the users and designers think that this description is adequate for them. It will not be possible to use the IBIS models to analyze crosstalk due to interconnects. Dileep Divekar From owner-ibis Fri Mar 21 09:55:43 1997 Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id JAA23447; Fri, 21 Mar 1997 09:55:42 -0800 (PST) Received: from salope.cse.tek.com by inet1.tek.com id ; Fri, 21 Mar 1997 09:53:14 -0800 Received: from salope (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with SMTP id JAA10810; Fri, 21 Mar 1997 09:53:03 -0800 (PST) Sender: brockh@mdhost.cse.tek.com Message-ID: <3332CAFF.45AE@mdhost.cse.tek.com> Date: Fri, 21 Mar 1997 09:53:03 -0800 From: Brock Hannibal X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ibis@vhdl.org, awglaser@eos.ncsu.edu, ibis-users@vhdl.org, bob@icx.com Subject: Re: s2ibis2 References: <3331B4F7.47F3@mdhost.cse.tek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks to all who responded to my plea for enlightenment. Once I ran hspice in stand alone mode on the deck that s2ibis2 created and kept the .lis file, I was able to understand what was happening. The problem was failure to converge due to excessive current in the nfet and pfet models at the Ibis sweep extremes(-3.3 to +6.6 volts). I reduced the sweep range and everything ran. Oh, I had to fix the "gnd" node by calling it "mygnd", still tying it to node 0 in hspice. This was for ex2 in the examples. Is there anyway to limit the automatically generated sweep range in the .s2i file? This was with hspice 96.1. Solaris. Mark Simpson wrote that the deck I attached ran fine in hspice 95.2, SunOS. Brock Hannibal wrote: > > Hi, > > I've been trying to run some of the examples in the v1.1 distribution of > s2ibis2. I'm using Hspice. > I'm admittedly not very familiar with Hspice since we have our own > internal Spice. Unfortunately converinting hspice to our internal Spice > is not an option at the moment.I get the following standard output: > > [salope:ex2] > /proj/cae/brockh/data/icx/ibis/tools/s2ibis2/bin/s2ibis2.solaris > tristate.s2i > > s2ibis2.solaris v1.1 -- North Carolina State University > s2ibis2.solaris: Reading input file tristate...done. > s2ibis2.solaris: Analyzing component MCM Trisate Driver . > s2ibis2.solaris: Starting HSpice job with input putout.spi. > s2ibis2.solaris: Spice run (TYP) aborted. See file putout.msg for > information. > Curve pullup not generated. > s2ibis2.solaris: Starting HSpice job with input dutout.spi. > s2ibis2.solaris: Spice run (TYP) aborted. See file dutout.msg for > information. > Curve pullup (output disabled) not generated. > > Any clue as to why the pullup and pulldown curves aren't generated. I > looked in the putout.spi > file and it looks OK to me but I'll attach it. The file putout.msg is > very short and looks like > this: > > ^G>error ***** hspice job aborted > > real 7.0 > user 0.5 > sys 0.2 > > Thanks for any insight you may have. I've fiddled around quite a bit and > am just not seeing the > problem or oversight. -- Brock Hannibal Hardware Design Engineer Tektronix, Inc. Beaverton, Oregon "Any ideas or opinions expressed here do not necessarily reflect the ideas or opinions of my employer." From owner-ibis Fri Mar 21 15:54:15 1997 Received: from netcomsv.netcom.com (uucp13.netcom.com [163.179.3.13]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id PAA29583 for ; Fri, 21 Mar 1997 15:54:14 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA27209; Fri, 21 Mar 1997 15:42:52 -0800 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA08333; Fri, 21 Mar 97 13:20:05 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA23036; Fri, 21 Mar 1997 13:27:22 +0800 Date: Fri, 21 Mar 1997 13:27:22 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9703212127.AA23036@contec13.contec.COM> To: ibis-users@vhdl.org Subject: Re: Question - BIRD 36.2 - Electrical Board Description Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII I am trying to get an understanding of how many users and designers consider doing only delay analysis adequate enough for their designs. If they have to use some other interface for crosstalk analysis, then they might as well use that interface for delay analysis also, instead of switching back and forth between two different interfaces. Therefore, they will use BIRD 36.2, if they think that only delay analysis is sufficeint and there is no need to perform crosstalk analysis. Dileep Divekar > From owner-ibis@vhdl.vhdl.org Fri Mar 21 09:11:03 1997 > To: ibis-users@vhdl.org > Subject: Question - BIRD 36.2 - Electrical Board Description > Content-Length: 762 > X-Lines: 23 > > > Hello Dileep: > > Yes, the present description -- by design-- does not > allow for describing coupling bettween traces. If a user > does wish to give enough information about a board in > order to do coupling the best medium in a physical description > (PCB data base). This takes advantage of the vendors already > existing path into there products, and there are now hooks > into EDIF 4.0 that will call out IBIS files. > > Regards, > Stephen > > > > Hello, > The present version of BIRD 36.2 allows the description > of only un-coupled lines. I would like to know if the > users and designers think that this description is adequate > for them. It will not be possible to use the IBIS models > to analyze crosstalk due to interconnects. > Dileep Divekar > From owner-ibis Sat Mar 22 12:35:20 1997 Received: from wotan.compaq.com (root@wotan.compaq.com [207.18.199.254]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id MAA19679 for ; Sat, 22 Mar 1997 12:35:19 -0800 (PST) From: MLeonard@bangate.compaq.com Received: from mail.compaq.com(really [207.18.199.36]) by wotan.compaq.com via smtpd with smtp id for ; Sat, 22 Mar 97 14:33:26 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: from bangate.compaq.com(really [131.168.114.234]) by mail.compaq.com via sendmail with smtp id for ; Sat, 22 Mar 97 14:33:25 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: by bangate.compaq.com; Sat, 22 Mar 97 14:33:05 -0600 Date: Sat, 22 Mar 97 13:46:16 CST Message-ID: X-Priority: 3 (Normal) To: Cc: Subject: Re: Question - BIRD 36.2 - Electrical Board Description Dileep, We have a pressing need for board-level descriptions of memory modules and AGP cards. For the most part, board-level crosstalk isn't too much of a concern there. Accordingly I'm very willing to forgo coupling information if we can get this BIRD approved and out in the hands of these module and card vendors. This BIRD, as well as a couple others in work, are very important. Unfortunately the approval process has become a long, drawn out affair. The modeling capabilities of IBIS are falling further and further behind our simulation needs. I would, however, welcome coupling information on Intel's processor daughter cards. Their board descriptions are currently being provided in a non-IBIS format. The descriptions do not include coupling information. Would we get it with an expanded BIRD 36.2? Probably not. My preference is to get this BIRD approved, then worry about board descriptions with coupling information later. Mark Leonard Compaq Computer Corporation ------------- Original Text From: dileep@contec.contec.COM (Dileep Divekar), on 3/21/97 1:27 PM: To: Cc: I am trying to get an understanding of how many users and designers consider doing only delay analysis adequate enough for their designs. If they have to use some other interface for crosstalk analysis, then they might as well use that interface for delay analysis also, instead of switching back and forth between two different interfaces. Therefore, they will use BIRD 36.2, if they think that only delay analysis is sufficeint and there is no need to perform crosstalk analysis. Dileep Divekar > From owner-ibis@vhdl.vhdl.org Fri Mar 21 09:11:03 1997 > To: ibis-users@vhdl.org > Subject: Question - BIRD 36.2 - Electrical Board Description > Content-Length: 762 > X-Lines: 23 > > > Hello Dileep: > > Yes, the present description -- by design-- does not > allow for describing coupling bettween traces. If a user > does wish to give enough information about a board in > order to do coupling the best medium in a physical description > (PCB data base). This takes advantage of the vendors already > existing path into there products, and there are now hooks > into EDIF 4.0 that will call out IBIS files. > > Regards, > Stephen > > > > Hello, > The present version of BIRD 36.2 allows the description > of only un-coupled lines. I would like to know if the > users and designers think that this description is adequate > for them. It will not be possible to use the IBIS models > to analyze crosstalk due to interconnects. > Dileep Divekar >