(vhdl.org was down from December 18, 1996 to January 12, 1997. No mail was transmitted.) From owner-ibis Mon Jan 13 20:18:11 1997 Received: from alcatel.fr (ns.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id UAA00668 for ; Mon, 13 Jan 1997 20:12:19 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id BAA26668 for ; Tue, 14 Jan 1997 01:48:41 +0100 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id MAA05169 for ; Thu, 9 Jan 1997 12:00:36 +0100 (MET) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA14184; Thu, 9 Jan 97 12:02:04 +0100 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA02330; Thu, 9 Jan 97 12:01:33 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <32D4D00C.446B9B3D@ln.cit.alcatel.fr> Date: Thu, 09 Jan 1997 12:01:32 +0100 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Modelling bus switches and other series elements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Happy New Year, IBIS cannot correctly model series devices. This isn't much of a problem for simple passive devices (R,L,C) or diodes. However, it's a major handicap for bus-switches (e.g. 74CBT range from Texas Inst). I've seen seen this feature on the wish-list, but am not aware of any proposals to handle it. So here's my suggestion for extending IBIS to model series switches. It requires 3 new keywords and one new modeltype. 1) Define a new keyword [Series Pin] This keyword is at the same level as, say, [Diff Pin] [Series Pin] |Pin1 Pin2 Buffer 3 4 switchA |switchA is buffer from 3 to 4 4 3 switchAneg |Buffer from 3 to 4 is non-symmetric 12 13 switchA 12 14 switchB |12 can be routed to 13 or 14 The two pins of the series element are identified, along with the the associated series buffer. This buffer corresponds to measurements made at Pin1. If the buffer is not symmetric, a different buffer may be specified with the pin order swapped. In the case of a crossbar switch, all possible series connections must be listed. IBIS contains no information concerning how or when one of the connections is selected. The buffer name given here supersedes that given under the [Pin] keyword. 2) Define new model type SERIES-SWITCH Define new keywords [Series] and [Series OFF] Four curves are obligatory: [Pulldown] [GND Clamp] [Series] [Series OFF] [GND Clamp] and [Series OFF] are measured for switch OFF. [Pulldown] and [Series] are measured for switch ON. [GND Clamp] + [Pulldown] are standard measurements, made at one pin. The other pin, identified under the [Series Pin] keyword, is assumed connected to ground. [Series] and [Series OFF] are through measurements ie between the two pins. The [Ramp] keyword is also required. The test load must include a voltage source. This gives enough information to model a switchable non-linear resistor. We could also define a model type SERIES which would not be switchable: only [Pulldown] and [Series] needed in this case. To allow for series frequency-dependent devices, additional R,L,C paths might be defined. Looking forward to your feedback, Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Tue Jan 14 05:09:32 1997 Received: from maildeliver0.tiac.net (maildeliver0.tiac.net [199.0.65.19]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id FAA01484 for ; Tue, 14 Jan 1997 05:09:31 -0800 (PST) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by maildeliver0.tiac.net (8.8.0/8.8) with ESMTP id IAA27176 for ; Tue, 14 Jan 1997 08:08:19 -0500 (EST) Received: from bcwadell.tiac.net (bcwadell.tiac.net [204.215.133.114]) by mailnfs0.tiac.net (8.8.0/8.8) with SMTP id IAA28200 for ; Tue, 14 Jan 1997 08:08:18 -0500 (EST) Received: by bcwadell.tiac.net with Microsoft Mail id <01BC01F2.EF0002C0@bcwadell.tiac.net>; Tue, 14 Jan 1997 08:14:16 -0500 Message-ID: <01BC01F2.EF0002C0@bcwadell.tiac.net> From: "Brian C. Wadell" To: "'ibis@vhdl.org'" Subject: IBIS to SPICE Date: Tue, 14 Jan 1997 08:03:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by vhdl.vhdl.org id FAA01485 I have been writing a script to convert IBIS files into SPICE files. So far it looks doable. I've converted the clamp and the package and Ccomp. I'm not quite certain what the meaning of the pullup and pulldown should be with respect to the edge rate specified in the IBIS file. My thought was to create a PWL edge out of the edge rates and drive a voltage-controlled resistance having the pulldown characteristics with that voltage. However, the voltage in the IBIS pulldown table seems to be the voltage across the pulldown resistance/conductance? I've read the cookbook and it doesn't answer my question. Has anyone got any experience or advice on this or can you refer me to an IBIS document? I'm pretty sure my question is just a matter of understanding the definitions better. Regards, Brian C. Wadell Guided Wave Solutions From owner-ibis Tue Jan 14 08:34:55 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id IAA01794 for ; Tue, 14 Jan 1997 08:34:55 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Tue, 14 Jan 1997 16:33:39 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id IAA07769 for ibis@vhdl.org; Tue, 14 Jan 1997 08:30:25 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 14 Jan 97 08:30:25 PST Date: Tue, 14 Jan 97 08:28:00 PST From: Arpad Muranyi Message-ID: To: owner-ibis@vhdl.vhdl.org, ibis@vhdl.org Subject: Re: IBIS to SPICE Text item: Brian, I would like to send you something, but I don't want to send it to the reflector. Could you please give me your direct EMAIL address? Arpad Muranyi Intel Corporation arpad_muranyi@ccm.fm.intel.com (916) 356-2558 ========================================================================= I have been writing a script to convert IBIS files into SPICE files. So = far it looks doable. I've converted the clamp and the package and = Ccomp. I'm not quite certain what the meaning of the pullup and pulldown should = be with respect to the edge rate specified in the IBIS file. My thought = was to create a PWL edge out of the edge rates and drive a = voltage-controlled resistance having the pulldown characteristics with = that voltage. However, the voltage in the IBIS pulldown table seems to = be the voltage across the pulldown resistance/conductance? =20 I've read the cookbook and it doesn't answer my question. Has anyone got any experience or advice on this or can you refer me to = an IBIS document? I'm pretty sure my question is just a matter of = understanding the definitions better. =20 Regards, Brian C. Wadell Guided Wave Solutions Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Date: Tue, 14 Jan 1997 08:03:15 -0500 Subject: IBIS to SPICE To: "'ibis@vhdl.org'" From: "Brian C. Wadell" Message-ID: <01BC01F2.EF0002C0@bcwadell.tiac.net> Received: by bcwadell.tiac.net with Microsoft Mail id <01BC01F2.EF0002C0@bcwadell.tiac.net>; Tue, 14 Jan 1997 08:14:16 -0500 Received: from bcwadell.tiac.net (bcwadell.tiac.net [204.215.133.114]) by mailnf s0.tiac.net (8.8.0/8.8) with SMTP id IAA28200 for ; Tue, 14 Jan 1 997 08:08:18 -0500 (EST) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by maildelive r0.tiac.net (8.8.0/8.8) with ESMTP id IAA27176 for ; Tue, 14 Jan 1997 08:08:19 -0500 (EST) Received: from maildeliver0.tiac.net (maildeliver0.tiac.net [199.0.65.19]) by vh dl.vhdl.org (8.8.4/8.8.3) with ESMTP id FAA01484 for ; Tue, 14 Ja n 1997 05:09:31 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.4/8.7.3) with ESMTP id FAA08234; Tue, 14 Jan 1997 05:15:49 -0800 (PST) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.8.2/8.7.3) with ESMTP id FAA14458; Tue, 14 Jan 1997 05:13:19 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Jan 14 09:19:45 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id JAA01882 for ; Tue, 14 Jan 1997 09:19:43 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 14 Jan 97 09:18 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 14 Jan 97 09:21 PST Message-Id: Date: Tue, 14 Jan 97 09:21 PST From: chris@icx.com ( Chris Reid) To: ibis@vhdl.org Subject: Modelling bus switches and other series elements Hello and happy new year everyone. I'm glad to have the reflector finally working again. John Fitzpatrick wrote about modeling series elements in IBIS. I believe there is a need that IBIS should address on this issue. However, thinking about it from a simulation vendor's point of view I think the proposal needs some additional features. When the simulation tool builds an electrical model for a particular network it must include all connections through series elements. Thus if a large switch is encountered with many branches then a lot of extra information must be included in the electrical model. If most of that information is wasted because, say, only one path through the switch is actually connected at any one time, then our users will not be pleased waiting a long time for a simulation result that should have taken only seconds. I think John's proposal is good for connections that always exist, but not, actually, for switches. It needs a bit more for that. Chris Reid From owner-ibis Tue Jan 14 09:43:22 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id JAA01932 for ; Tue, 14 Jan 1997 09:43:21 -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 JAA20005 for ; Tue, 14 Jan 1997 09:42:03 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id JAA20173; Tue, 14 Jan 1997 09:41:52 -0800 (PST) Message-Id: <199701141741.JAA20173@ichips.intel.com> To: ibis@vhdl.org Subject: Modelling bus switches and other series elements Date: Tue, 14 Jan 1997 09:42:07 -0800 From: Stephen Peters Hello John: Happy new year to you also! I read your proposal, and I was wondering why you felt the [Pulldown] keyword was needed, and why only the [GND Clamp] keyword was required (and not both [GND Clamp and [PWR Clamp] keywords). If you are trying to describe a "series pass transistor" type of switch, then I think one waveform describing the switch when "on, along with the [GND clamp] and [PWR clamp] keywords for when the switch is off would suffice. Could you explain more why you chose the keywords you did? Regards, Stephen Peters Intel Corp. Happy New Year, IBIS cannot correctly model series devices. This isn't much of a problem for simple passive devices (R,L,C) or diodes. However, it's a major handicap for bus-switches (e.g. 74CBT range from Texas Inst). I've seen seen this feature on the wish-list, but am not aware of any proposals to handle it. So here's my suggestion for extending IBIS to model series switches. It requires 3 new keywords and one new modeltype. 1) Define a new keyword [Series Pin] This keyword is at the same level as, say, [Diff Pin] [Series Pin] |Pin1 Pin2 Buffer 3 4 switchA |switchA is buffer from 3 to 4 4 3 switchAneg |Buffer from 3 to 4 is non-symmetric 12 13 switchA 12 14 switchB |12 can be routed to 13 or 14 The two pins of the series element are identified, along with the the associated series buffer. This buffer corresponds to measurements made at Pin1. If the buffer is not symmetric, a different buffer may be specified with the pin order swapped. In the case of a crossbar switch, all possible series connections must be listed. IBIS contains no information concerning how or when one of the connections is selected. The buffer name given here supersedes that given under the [Pin] keyword. 2) Define new model type SERIES-SWITCH Define new keywords [Series] and [Series OFF] Four curves are obligatory: [Pulldown] [GND Clamp] [Series] [Series OFF] [GND Clamp] and [Series OFF] are measured for switch OFF. [Pulldown] and [Series] are measured for switch ON. [GND Clamp] + [Pulldown] are standard measurements, made at one pin. The other pin, identified under the [Series Pin] keyword, is assumed connected to ground. [Series] and [Series OFF] are through measurements ie between the two pins. The [Ramp] keyword is also required. The test load must include a voltage source. This gives enough information to model a switchable non-linear resistor. We could also define a model type SERIES which would not be switchable: only [Pulldown] and [Series] needed in this case. To allow for series frequency-dependent devices, additional R,L,C paths might be defined. Looking forward to your feedback, Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Tue Jan 14 17:02:53 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id RAA03078 for ; Tue, 14 Jan 1997 17:02:52 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id RAA18208 for ; Tue, 14 Jan 1997 17:02:34 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma017954; Tue Jan 14 17:02:15 1997 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA10233 for ibis@vhdl.org; Tue, 14 Jan 97 17:01:13 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27664; Tue, 14 Jan 97 17:03:09 PST Date: Tue, 14 Jan 97 17:03:09 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9701150103.AA27664@rockie.nsc.com> To: ibis@vhdl.org Subject: Agenda for Jan20th IBIS Summit Meeting Cc: huq@rockie.nsc.com Agenda for Jan20th 1997 IBIS Summit Place: Westin Hotel (Santa Cruz conference Room - 1st floor) 5101 Great America Parkway Santa Clara, California (408)986-0700 Date: Jan 20th Monday(one day) Time: 8am - 5pm Time Topic Presentor --------------------------------------------------------------------- 8:00 Continental Breakfast All 8:30 - Sign-In All - Intros of Attendees Huq - Miscellany/Announcements Huq - Open for New Issues All 8:50 Review of summit Agenda Huq 9:00 ANSI/EIA-656(IBIS)overview Huq - Web site at EIA - ftp site at vhdl.org - Currect activities - EIA Membership 9:30 Problems representing ABT Powell Models using IBIS 10:00 IBIS modeling at Alcatel Fitzpatrick 10:30 Overview of Visiual IBIS Crisafulli Editor for Windows, and Solicitation of Ideas for Version 2.0" 11:00 BIRD 36: Elec. Descrp Peters 12:00 Lunch 1:00 BIRD 36: Elec. Descrp Contd..... Other items -DAC 97 IBIS meeting plans -IBISv3.0 ratification -s2ibis2 -cookbook for v2.1 Next Teleconference schedule Huq 5:00 Meeting adjourned From owner-ibis Tue Jan 14 18:56:53 1997 Received: from maildeliver0.tiac.net (maildeliver0.tiac.net [199.0.65.19]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id SAA03295 for ; Tue, 14 Jan 1997 18:56:52 -0800 (PST) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by maildeliver0.tiac.net (8.8.0/8.8) with ESMTP id VAA16295; Tue, 14 Jan 1997 21:55:36 -0500 (EST) Received: from bcwadell.tiac.net (bcwadell.tiac.net [204.215.133.114]) by mailnfs0.tiac.net (8.8.0/8.8) with SMTP id VAA20534; Tue, 14 Jan 1997 21:55:34 -0500 (EST) Received: by bcwadell.tiac.net with Microsoft Mail id <01BC0266.82095260@bcwadell.tiac.net>; Tue, 14 Jan 1997 22:01:35 -0500 Message-ID: <01BC0266.82095260@bcwadell.tiac.net> From: "Brian C. Wadell" To: "'John V Fitzpatrick'" Cc: "'ibis@vhdl.org'" Subject: RE: IBIS to SPICE Date: Tue, 14 Jan 1997 22:00:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by vhdl.vhdl.org id SAA03296 John, Thank you for replying. I have defined the voltage controlled resistors AOK in the manner you have described. Maybe it is a simple point I am stuck on. What voltage should I drive the voltage controlled resistor control line with? My first thought was to drive it with a ramp having the rise time specified in the IBIS file. But then when I think about it a bit more I think that the voltage controlled resistor is also controlled by the voltage from VCC (or ground for the pulldown R) to the output voltage (Ccomp node). The table of (V, I) leads me to this question because of the range of voltages shown (2*Vcc, I think) which doesn't seem relevant for an internally generated ramp. I'm certain this is just a matter of my own lack of understanding of the IBIS model. Thank you for taking the time to reply. Regards, BCW Guided Wave Solutions ---------- From: John V Fitzpatrick[SMTP:John.Fitzpatrick@ln.cit.alcatel.fr] Sent: Tuesday, January 14, 1997 9:46 AM To: Brian C. Wadell Subject: Re: IBIS to SPICE Brian, This is a good approach. I don't understand your problem. The V-controlled resistances can be defined directly by the IBIS tables. For the pulldown case, your PWL will be at 0V, so the V-controlled resistance will correspond to the IBIS table directly. Similarly for pullup, your PWL will be at Vcc, do you can use the Vcc-referenced IBIS table directly. During the transition time of the PWL, you just hope for the best - it's usually good enough. This is what I've seen from models I've built (manually) in PSpice using IBIS data. Regards, John > I'm not quite certain what the meaning of the pullup and pulldown should be with respect to the edge rate specified in the IBIS file. My thought was to create a PWL edge out of the edge rates and drive a voltage-controlled resistance having the pulldown characteristics with that voltage. However, the voltage in the IBIS pulldown table seems to be the voltage across the pulldown resistance/conductance? -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Wed Jan 15 01:22:07 1997 Received: from alcatel.fr (ns.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id BAA03719 for ; Wed, 15 Jan 1997 01:22:03 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id JAA31966; Wed, 15 Jan 1997 09:57:05 +0100 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id JAA13128; Wed, 15 Jan 1997 09:52:01 +0100 (MET) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA19346; Wed, 15 Jan 97 09:53:37 +0100 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01146; Wed, 15 Jan 97 09:53:19 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <32DC9AFE.52BFA1D7@ln.cit.alcatel.fr> Date: Wed, 15 Jan 1997 09:53:18 +0100 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Cc: "Stephen Peters chris@icx.com ( Chris Reid)" Subject: Re: Modelling bus switches and other series elements References: <199701141741.JAA20173@ichips.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks to Chris and Stephen for your comments, Hopefully we'll be able to discuss this topic on Monday. Below is a clarification of some points: 1) Path info I agree with Chris when he says that extra information is needed within IBIS to reduce the number of potential simulations. But this means giving more than an electrical description of the component; a functional description would be necessary, something IBIS doesn't do (yet!). The proposal I sent would require all possible series paths to be listed. This, in my opinion, is a minimum requirement. (With this, a simulator could ask the user to select the paths to simulate). A further optimisation might be to group series paths together to indicate to the simulator that if one path is selected, then all paths are selected. What do simulator companies do today to model series devices such as bus-switches? 2) Keywords Regarding the choice of keywords, my original idea was to use only the keywords [GND Clamp] and [Pulldown]. [GND Clamp] would be for switch that is OFF, [Pulldown] for a switch that is ON. To measure [Pulldown], one side of the series device would be connected to GND. Optionally, a [PWR Clamp] keyword could be used, but I don't like this keyword !! In my opinion, it is redundant, but that's another debate. Instead, the proposal I make is more general, based somewhat on network-analysis approach: - one input impedance measurement per operating state - one through (thru) impedance measurement per op. state So for a switch, which can be ON or OFF, there are two operating states => 4 measurement curves. I think this is enough to describe fully the device. What is the opinion of simultor companies? Aside: For a standard buffer (one-port), only input impedances are measured. There are, at most, three operating states: HI-Z, LO and HI => 3 measurement curves. IBIS defines 4 curves, hence my view that one curve is redundant. Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 Original proposal: IBIS cannot correctly model series devices. This isn't much of a problem for simple passive devices (R,L,C) or diodes. However, it's a major handicap for bus-switches (e.g. 74CBT range from Texas Inst). I've seen seen this feature on the wish-list, but am not aware of any proposals to handle it. So here's my suggestion for extending IBIS to model series switches. It requires 3 new keywords and one new modeltype. 1) Define a new keyword [Series Pin] This keyword is at the same level as, say, [Diff Pin] [Series Pin] |Pin1 Pin2 Buffer 3 4 switchA |switchA is buffer from 3 to 4 4 3 switchAneg |Buffer from 3 to 4 is non-symmetric 12 13 switchA 12 14 switchB |12 can be routed to 13 or 14 The two pins of the series element are identified, along with the the associated series buffer. This buffer corresponds to measurements made at Pin1. If the buffer is not symmetric, a different buffer may be specified with the pin order swapped. In the case of a crossbar switch, all possible series connections must be listed. IBIS contains no information concerning how or when one of the connections is selected. The buffer name given here supersedes that given under the [Pin] keyword. 2) Define new model type SERIES-SWITCH Define new keywords [Series] and [Series OFF] Four curves are obligatory: [Pulldown] [GND Clamp] [Series] [Series OFF] [GND Clamp] and [Series OFF] are measured for switch OFF. [Pulldown] and [Series] are measured for switch ON. [GND Clamp] + [Pulldown] are standard measurements, made at one pin. The other pin, identified under the [Series Pin] keyword, is assumed connected to ground. [Series] and [Series OFF] are through measurements ie between the two pins. The [Ramp] keyword is also required. The test load must include a voltage source. This gives enough information to model a switchable non-linear resistor. We could also define a model type SERIES which would not be switchable: only [Pulldown] and [Series] needed in this case. To allow for series frequency-dependent devices, additional R,L,C paths might be defined. Looking forward to your feedback, Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Wed Jan 15 05:39:44 1997 Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id FAA04014 for ; Wed, 15 Jan 1997 05:39:42 -0800 (PST) From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Type: text Message-Id: <9701150842.ZM22206@eagle> Date: Wed, 15 Jan 1997 08:42:20 -0500 In-Reply-To: John V Fitzpatrick "Re: Modelling bus switches and other series elements" (Jan 15, 9:53am) References: <199701141741.JAA20173@ichips.intel.com> <32DC9AFE.52BFA1D7@ln.cit.alcatel.fr> X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis@vhdl.org Subject: Re: Modelling bus switches and other series elements Cc: "Stephen Peters chris@icx.com ( Chris Reid)" On Jan 15, 9:53am, John V Fitzpatrick wrote: > Subject: Re: Modelling bus switches and other series elements > Thanks to Chris and Stephen for your comments, > > Hopefully we'll be able to discuss this topic on Monday. > > Below is a clarification of some points: > > > 1) Path info > > I agree with Chris when he says that extra information is needed > within IBIS to reduce the number of potential simulations. But this > means giving more than an electrical description of the component; > a functional description would be necessary, something IBIS doesn't > do (yet!). > > The proposal I sent would require all possible series paths to be > listed. This, in my opinion, is a minimum requirement. (With this, > a simulator could ask the user to select the paths to simulate). > A further optimisation might be to group series paths together to > indicate to the simulator that if one path is selected, then all > paths are selected. > > What do simulator companies do today to model series devices > such as bus-switches? > As a user I don't find this to be a big problem. We use CBTs all the time. IBIS is only a starting point to the simulation process. In the simulation language I hard code in the switch instances I need and selectively iterate runs. Our application uses the CBTs as mostly crossbars with logically a limited number of configs. Richard Mellitz, NCR From owner-ibis Wed Jan 15 07:18:26 1997 Received: from gate.chips.ibm.com (gate.chips.ibm.com [192.91.197.61]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id HAA04161 for ; Wed, 15 Jan 1997 07:18:23 -0800 (PST) Received: from mailrelay.btv.ibm.com (mailrelay.btv.ibm.com [9.66.4.12]) by gate.chips.ibm.com (8.8.4/8.8.4) with ESMTP id KAA25290 for ; Wed, 15 Jan 1997 10:16:34 -0500 Received: from postoffice.btv.ibm.com (postoffice.btv.ibm.com [9.66.4.40]) by mailrelay.btv.ibm.com (8.8.4/8.8.4) with ESMTP id KAA31628 for ; Wed, 15 Jan 1997 10:16:33 -0500 Received: from wind.btv.ibm.com (wind.btv.ibm.com [9.66.57.118]) by postoffice.btv.ibm.com (8.8.4/8.8.4) with SMTP id KAA80733 for ; Wed, 15 Jan 1997 10:16:34 -0500 Received: by btv.ibm.com (AIX 4.1/UCB 5.64/fs4.03) id AA25780; Wed, 15 Jan 1997 10:16:33 -0500 Message-Id: <9701151516.AA25780@btv.ibm.com> X-Mailer: exmh version 2.0beta 12/23/96 To: ibis@vhdl.org X-Note-Format: RFC822 Subject: >> Subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:16:33 -0500 From: "Ezra D. Hall" --- Please add me to the EIA IBIS Open Forum distibution list. Thanks, Ezra Hall (ehall@btv.ibm.com) -- +-------------------------------+-----------------------------+ | Ezra D.B. Hall | Internet: ehall@btv.ibm.com | | IBM Microelectronics | VM: ehall at btvlabvm | | D/G8G B/863-2 | Phone: (802) 769-7329 | | 1000 River Street | FAX: (802) 769-6800 | | Essex Junction, VT 05452-4299 | | +-------------------------------+-----------------------------+ From owner-ibis Wed Jan 15 08:28:18 1997 Received: from hermes.intel.com (hermes.intel.com [143.183.152.3]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id IAA04332 for ; Wed, 15 Jan 1997 08:28:16 -0800 (PST) Received: from fmmail.fm.intel.com by hermes.intel.com (8.8.4/10.0i); Wed, 15 Jan 1997 08:25:42 -0800 Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id IAA12512; Wed, 15 Jan 1997 08:22:28 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 15 Jan 97 08:22:28 PST Date: Wed, 15 Jan 97 08:19:00 PST From: Arpad Muranyi Message-ID: To: John.Fitzpatrick@ln.cit.alcatel.fr cc: ibis@vhdl.org Subject: Re[2]: IBIS to SPICE Text item: Brian, I would suggest that you drive that VCR with the voltage between the output node and the ramp node. However, I would suggest not to use VCRs (as I stated to you in my private EMAIL to you). A Thevenin or Norton circuit with voltage controlled current or voltage source (and some tricks) will work better. Arpad ================================================================================ John, Thank you for replying. I have defined the voltage controlled resistors = AOK in the manner you have described. Maybe it is a simple point I am = stuck on. What voltage should I drive the voltage controlled resistor = control line with? =20 My first thought was to drive it with a ramp having the rise time = specified in the IBIS file. But then when I think about it a bit more I = think that the voltage controlled resistor is also controlled by the = voltage from VCC (or ground for the pulldown R) to the output voltage = (Ccomp node). The table of (V, I) leads me to this question because of = the range of voltages shown (2*Vcc, I think) which doesn't seem relevant = for an internally generated ramp. =20 I'm certain this is just a matter of my own lack of understanding of the = IBIS model. Thank you for taking the time to reply. Regards, BCW Guided Wave Solutions ---------- From: John V Fitzpatrick[SMTP:John.Fitzpatrick@ln.cit.alcatel.fr] Sent: Tuesday, January 14, 1997 9:46 AM To: Brian C. Wadell Subject: Re: IBIS to SPICE Brian, =20 This is a good approach. I don't understand your problem. The V-controlled resistances can be defined directly by the IBIS tables.=20 For the pulldown case, your PWL will be at 0V, so the V-controlled resistance will correspond to the IBIS table directly. Similarly for pullup, your PWL will be at Vcc, do you can use the Vcc-referenced IBIS table directly. During the transition time of the PWL, you just hope for the best - it's usually good enough. This is what I've seen from models I've built (manually) in PSpice using IBIS data. Regards, John > I'm not quite certain what the meaning of the pullup and pulldown = should be with respect to the edge rate specified in the IBIS file. My = thought was to create a PWL edge out of the edge rates and drive a = voltage-controlled resistance having the pulldown characteristics with = that voltage. However, the voltage in the IBIS pulldown table seems to = be the voltage across the pulldown resistance/conductance? =20 --=20 John Fitzpatrick =20 Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Date: Tue, 14 Jan 1997 22:00:19 -0500 Subject: RE: IBIS to SPICE Cc: "'ibis@vhdl.org'" To: "'John V Fitzpatrick'" From: "Brian C. Wadell" Message-ID: <01BC0266.82095260@bcwadell.tiac.net> Received: by bcwadell.tiac.net with Microsoft Mail id <01BC0266.82095260@bcwadell.tiac.net>; Tue, 14 Jan 1997 22:01:35 -0500 Received: from bcwadell.tiac.net (bcwadell.tiac.net [204.215.133.114]) by mailnf s0.tiac.net (8.8.0/8.8) with SMTP id VAA20534; Tue, 14 Jan 1997 21:55:34 -0500 ( EST) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by maildelive r0.tiac.net (8.8.0/8.8) with ESMTP id VAA16295; Tue, 14 Jan 1997 21:55:36 -0500 (EST) Received: from maildeliver0.tiac.net (maildeliver0.tiac.net [199.0.65.19]) by vh dl.vhdl.org (8.8.4/8.8.3) with ESMTP id SAA03295 for ; Tue, 14 Ja n 1997 18:56:52 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.4/8.7.3) with ESMTP id TAA11706; Tue, 14 Jan 1997 19:04:39 -0800 (PST) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.8.2/8.7.3) with ESMTP id TAA14965; Tue, 14 Jan 1997 19:02:09 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Jan 15 09:00:17 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id JAA04436 for ; Wed, 15 Jan 1997 09:00:15 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 15 Jan 97 08:59 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 15 Jan 97 09:01 PST Message-Id: Date: Wed, 15 Jan 97 09:01 PST From: chris@icx.com ( Chris Reid) To: ibis@vhdl.org Subject: Modelling bus switches and other series elements Good morning, Maybe instead of a syntax that defines all possible connections simultaneously (making it look like there are many simultaneous paths) we should find one that clearly calls out the different switch states. Something like: [State] StateName1 | Pin Pin Model 1 3 SMC [State] StateName2 | Pin Pin Model 1 5 SMCx I'm not suggesting this as the actual syntax, only as an example to explain my concept. The simulator must be told witch state of the switch to use in any particular simulation. Of course, if the goal is to model the transition between states this is not helpful. However, users of our system have not asked for that capability, but they have done things like Richard Mellitz suggests, swapping out one model for another, manually. This syntax would give the user a way to specify the different switch states. It would be up to the simulator to allow the user to specify whitch state to use when. The same, or a degenerate syntax without the [State] specified could be used for series elements that are not switchable. Chris Reid From owner-ibis Wed Jan 15 18:25:24 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id SAA05346 for ; Wed, 15 Jan 1997 18:25:24 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id SAA03966 for ; Wed, 15 Jan 1997 18:25:06 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma003787; Wed Jan 15 18:24:47 1997 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07727 for ibis@vhdl.org; Wed, 15 Jan 97 18:23:49 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA00577; Wed, 15 Jan 97 18:25:46 PST Date: Wed, 15 Jan 97 18:25:46 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9701160225.AA00577@rockie.nsc.com> To: ibis@vhdl.org Subject: Meeting minutes Jan10th 1997 Cc: huq@rockie.nsc.com DATE: January15th, 1997 SUBJECT: 1/10/97 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann, Tim Minnick, Russ Moser, Ray Ziesse, Jeff Walden Applied Simulation Technology Dileep Divekar*, Norio Matsui, Antonis Orphanou (formerly Contec) Cadence Design C. Kumar Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier, Ralf Bruening Intel Corporation Stephen Peters, Will Hobbs, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, [Donald Telian], Jim Kruchowski Interconnectix Bob Ross, Chris Reid Meta-Software (Sanjay Gangal) Mitsubushi Tam Cao, Hoang Nguyen Motorola Ahmed Omer* National Semiconductor Syed Huq*, Chune-Sin Yeh, NCR (formerly ATT-GIS) Dave Moxley, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell*, Chris Rokusek Quantic Laboratories Mike Ventham Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia Veribest Ian Dodd, David Wiens VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery, D.C. Sessions, Hrish Patel Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: 3M Fran Hart, George Hare Actel Scott Schlachter Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu* EIA Patti Rusher IC Works Eric Chen Mentor Graphics Kim Owen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella* North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Symmetry Andy Hughes Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison VTC, Inc. Bob Ward Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Upcoming Meetings: 1/20/97 FACE TO FACE MEETING All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS No new introductions of participants. EIA MEMBERSHIP AND TREASURER'S REPORT Patti Rusher(EIA) was not present for updates. MINUTES REPORT, MISC. Could not confirm if commitment letter to Patti Rusher about DAC97 poster was sent by Bob Ross. MISCELLANY/ANNOUNCEMENTS vhdl.org was compromised by hackers and was pulled off the network. This disrupted the IBIS reflector as well as links establised from the ANSI/EIA-656 web site. Randy Harr of DARPA was actively working on getting the server up and running. Jon Powell has sent out a message thru the alias list extracted out from the IBIS reflector Bob Ross(Chair)was unable to attend teleconference due to health reasons. Several members were concerned of his absense. PRESS AND WEB PAGE UPDATES Syed Huq reported EDN Product Edition Dec11th'96 pg24 had an article on 'PC Graphics System Design' that mentions IBIS for modeling. NEW MODELS Syed Huq reported various models from National Semiconductor being released from the website at http://www.national.com ds36c200, pc87338 & lm78 Arpad reported various models being updated that are avialable under NDA from Intel OPENS FOR NEW ISSUES None DESIGN SUPERCON97 IBIS SUMMIT MEETING Received a lot of confirmation from over 22 companies who will be attending the IBIS summit. Syed Huq and Jon Powell are working on an Agenda to be published the week of Jan13th. AR= Syed/Jon publish Summit agenda S2IBIS2 The new version of s2ibis2 is available from the vhdl.org ftp site. Syed will compile any issues users encounter on this new version. All bugs should be forwared to syed (huq@rockie.nsc.com) DAC97 PLANNING None IEC PROGRESS None COOKBOOK for 2.1 None PARSER BUG DISCUSSION None PACKAGE COMMITTEE REPORT None. Concerns were highlighted by various participants regarding BIRD36. These were the use of SPICE models to describe connectors over the new syntax described by BIRD36. Many felt that SPICE was more appropriate and are readily available and IBIS syntax need not be created again to model connectors. More disucssion regarding this will be held during the summit meeting. BIRD40 - SPECIFICATION ENHANCEMENT(vote) No vote was taken as qorum not established other technical discussion: --------------------------- Various discussions were held regarding an upcoming BIRD from Arpad about Quick Switch. Modeling of series devices with FET switches was the concern. AR=Arpad to generate BIRD NEXT MEETING: The next meeting is the IBIS Summit 1997: Place: Westin Hotel (Santa Cruz conference Room - 1st floor) 5101 Great America Parkway Santa Clara, California (408)986-0700 Date: Jan 20th Monday(one day) Time: 8am - 5pm ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Thu Jan 16 01:56:45 1997 Received: from alcatel.fr (ns.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id BAA05879 for ; Thu, 16 Jan 1997 01:56:39 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id KAA00264; Thu, 16 Jan 1997 10:59:49 +0100 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id KAA02829; Thu, 16 Jan 1997 10:54:49 +0100 (MET) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA05161; Thu, 16 Jan 97 10:56:24 +0100 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01362; Thu, 16 Jan 97 10:56:17 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <32DDFB40.4DAA423A@ln.cit.alcatel.fr> Date: Thu, 16 Jan 1997 10:56:16 +0100 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Cc: Chris Reid Subject: Re: Modelling bus switches and other series elements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bonjour, I like Chris's suggestion. So we could have a keyword [Series Models] followed by optional [State] keywords. Let's be careful about the word "switch". There is the case where a switch is ON or OFF, and then there's the case where different paths are switched in or selected. So [State] indicates when to use the ON model of a buffer. In all other states, the OFF model is used. i.e.[State] is used when there are selectable paths. Example: [Series Models] | Pin Pin Model 6 7 FET #always ON [State] StateName1 | Pin Pin Model 1 3 SMC #ON only when state=StateName1 [State] StateName2 | Pin Pin Model 1 5 SMCx Some questions: 1) I see from the minutes of the last meeting that Arpad is preparing a BIRD on this subject. Is a draft of this BIRD available? 2) A common application of bus switches is to protect components e.g. 3.3V from 5V, 2.5V from 3.3V. Should IBIS allow this to be modelled? Or is it too much an analog funcction? Regards to all, John Fitz -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 Chris Reid wrote: > > Good morning, > > Maybe instead of a syntax that defines all possible connections > simultaneously (making it look like there are many simultaneous > paths) we should find one that clearly calls out the different > switch states. Something like: > > [State] StateName1 > | Pin Pin Model > 1 3 SMC > > [State] StateName2 > | Pin Pin Model > 1 5 SMCx > > I'm not suggesting this as the actual syntax, only as an example > to explain my concept. The simulator must be told witch state of > the switch to use in any particular simulation. > > Of course, if the goal is to model the transition between states > this is not helpful. However, users of our system have not asked > for that capability, but they have done things like Richard Mellitz > suggests, swapping out one model for another, manually. > > This syntax would give the user a way to specify the different > switch states. It would be up to the simulator to allow the > user to specify whitch state to use when. > > The same, or a degenerate syntax without the [State] specified > could be used for series elements that are not switchable. > > Chris Reid From owner-ibis Thu Jan 16 02:04:40 1997 Received: from alcatel.fr (ns.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id CAA05896 for ; Thu, 16 Jan 1997 02:04:35 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id LAA00581; Thu, 16 Jan 1997 11:08:16 +0100 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id LAA04162; Thu, 16 Jan 1997 11:03:18 +0100 (MET) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA05424; Thu, 16 Jan 97 11:05:03 +0100 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01365; Thu, 16 Jan 97 11:04:35 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <32DDFD32.64880EEB@ln.cit.alcatel.fr> Date: Thu, 16 Jan 1997 11:04:34 +0100 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: Stephen Peters Cc: ibis@vhdl.org Subject: Bird 36: latest draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen, I have not followed the progress of Bird 36, so am trying to prepare myself for Monday's discussion. Is the version on vhdl.org dated 24-June-96 the latest version of this Bird? Or is there a working draft somewhere which indicates better the current state of work in progress? Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Thu Jan 16 11:13:05 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id LAA06812 for ; Thu, 16 Jan 1997 11:12:59 -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 LAA04462 for ; Thu, 16 Jan 1997 11:11:39 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id LAA28339; Thu, 16 Jan 1997 11:11:11 -0800 (PST) Message-Id: <199701161911.LAA28339@ichips.intel.com> To: ibis@vhdl.org Subject: Bird36.d Date: Thu, 16 Jan 1997 11:11:43 -0800 From: Stephen Peters Hello fellow IBISans: Per request, here is the latest version of BIRD 36. As yet, it does not contain a formatt for describing coupling in a connector. We have been concentrating on the simpler, uncoupled case. Syed, please feel free to make copies of this for distribution at the face to face Monday. I Looking forward to seeing everyone there.... Best regards, Stephen Peters Intel Corp. Buffer Issue Resolution Document (BIRD) BIRD ID#: 36.d ISSUE TITLE: Electric Descriptions of Boards and Connectors REQUESTER: Stephen Peters, Hank Herrmann DATE SUBMITTED: June 23, 1996, 11/4/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related type components that consist of one or more ICs mounted on a PCB board that connects them to a system thru a set of pins. The following BIRD proposes a new type of file called .eid (Electrical Interconnect Description) that addresses this need. A .eid file can also be used to describe connectors and sockets. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following text is placed in the specification after the .pkg file description and before the [End] keyword description. ==================== ELECTRICAL INTERCONNECT DESCRIPTION ==================== An Interconnect Level Component is defined as a part that connects one or more IC packages to another part or board thru a set of user visible pins. For example, a SIMM module is an interconnect level component in that it connects several DRAM packages to a PCB thru an edge connector. To provide a simple electrical description of the connection between the pins of the interconnect level component and the IC packages, an electrical interconnect description file (a .eid file) is defined. The .eid file is also used to describe the electrical characteristics of connectors and sockets. What is, and is not, included in an Electrical Interconnect Description is defined by its boundaries. For the definition of the boundaries, see the Description section under the [Path Description] Keyword. Usage Rules: A .eid file is intended to be a stand alone file, not associated with any .ibs file. Interconnect level component descriptions are stored in a file whose name looks like .eid, where must conform to the naming rules given in the general syntax section of this specification. The .eid extension is mandatory. Contents: A .eid file is structured similar to a standard IBIS file. It must contain the following keywords, as defined in the IBIS specification: [IBIS Ver], [File name], [File rev], and [End]. It may also contain the following optional keywords: [Comment char], [Date], [Source], [Notes], [Disclaimer] and [Copyright]. The actual interconnect level component description is contained between the keywords [Begin Electrical Description] and [End Electrical Description], and includes the keywords listed below. [Begin Electrical Description] [Manufacturer] [Application Info] [Number of Pins] note 1 [Number of Pairs] note 1 [Pin List] note 2 [Pair List] note 2 [Path Description] [Coupled Path Model] note 3 [Reference Designator Map] [Model Data] note 3 [Resistance Matrix] note 3 [Inductance Matrix] note 3 [Capacitance Matrix] note 3 [Bandwidth] note 3 [Row] note 3 [End Model Data] note 3 [End Electrical Description] (Note 1) Either the [Number of Pins] or [Number of Pairs] keyword must be used but not both. (Note 2) Either the [Pin List] or [Pair List] keyword must be used but not both. [Pin List] is used only when the [Number of Pins] keyword has been used and [Pair List] is used only when the [Number of Pairs] keyword has been used. (Note 3) The indicated keywords are reserved for future use in coupled models. More than one [Begin Electrical Description]/[End Electrical Description] keyword pair is allowed in a .eid file. |============================================================================= | Keyword: [Begin Electrical Description] | Required: Yes |Description: Marks the beginning of an Electrical Interconnect description. |Usage Rules: The keyword is followed by the name of the interconnect level | component. If the .eid file contains more than one [Begin | Electrical Description] keyword, then each name must be unique. | The length of the component name must not exceed 40 characters | in length, and blank characters are allowed. For every | [Begin Electrical Description] keyword there must be a | matching [End Electrical Description] keyword. |----------------------------------------------------------------------------- [Begin Electrical Description] 16Meg X 8 Simm Module | |============================================================================= | Keyword: [Manufacturer] | Required: Yes |Description: Declares the manufacturer of the part(s) that use this .eid | file. |Usage Rules: Following the keyword is the manufacturers name. It must not | exceed 40 characters, and can include blank characters. Each | manufacturer must use a consistent name in all .eid files. |----------------------------------------------------------------------------- [Manufacturer] Quality SIMM Corp. | |============================================================================= | Keyword: [Application Info] | Required: Yes, if any subparameters need to be specified. |Description: This keyword provides general model application information. |Sub-params: Min_edge_time, Cpad1, Cpad2 |Usage Rules: This keyword is followed by one to three listed subparameters. | All three subparameters are optional. Subparameters are | followed by an equals sign (=); whitespace around the equals | sign is optional. | | The Min_edge_time subparameter is used to specify the minimum | edge time of a signal for which an interconnect model is | considered accurate. This value is based on the smallest | physical feature that is modeled in the electrical description. | Note that a simulator may choose to produce a warning message | if a signal with a faster edge enters the model. Simulators | should also use this subparameter in determining how to | model a section with non-zero length. | | The Min_edge_time subparameter is a single numeric argument | specifying the 20% to 80% edge time of the fastest pulse the | model will accurately pass. This value will be the minimum | value at which the measured signal line impedance is within 10% | of the simulated impedance. The point at which impedance | deviations exceed 10% is the point at which the model needs | more structural detail. This is not the same as dividing a long | section into stages as is required when using lumped values in | SPICE. Long uniform sections should be specified as distributed | sections. (Len <> 0 under [Path Description]) Measured line | impedance is the impedance plot of the part's connection path | taken by a Time Domain Reflectometer (TDR) with the edge time | indicated by the Min_edge_time subparameter. The simulated | impedance is the ratio of the dynamic model input voltage to input | current with the same source waveform and the same configuration | as the test. The usual configuration is to ground all appropriate | lines and use source and load impedances of 50 ohms. | | The Cpad1 subparameter defines the default pad capacitances | for all circuit board edge pads or all pins on the first side | of a connector model. Cpad2 is the default pad capacitance on | the second side of a connector. The first and second sides | refer to the order as used in the pin-pairs of the [Pin List] | keyword. If either is omitted, the default value is zero pF. | Do not omit Cpad1 (set it equal to zero) if Cpad2 is needed. | In all cases the simulator may override the listed or default | value with values extracted from the actual pad dimensions | provided in a physical board description. | |--------------------------------------------------------------------------- | | AN EXAMPLE CONNECTOR DESCRIPTION | Min_edge_time = 1.5n Cpad1 = 0.5p Cpad2 = 1.0p | | AN EXAMPLE PATH ON A SIMM MODULE | Min_edge_time = 1.0n Cpad1 = 1.5p | | ANOTHER EXAMPLE PATH ON A SIMM MODULE | Min_edge_time = 1.5n | |============================================================================= | Keyword: [Number of Pins] | Required: Yes, if the .eid file describes a circuit board, an unmated | connector or similar structure. This keyword must not be | used if the [Number of Pairs] keyword is used. |Description: Tells the parser the number of pins to expect. Pins are any | externally accessible electrical connection to the part. |Usage Rules: The field must be a positive decimal integer. | Note: The simulator must not limit the Number of Pins to any | value less than 1,000. |----------------------------------------------------------------------------- [Number of Pins] 128 | |============================================================================= | Keyword: [Number of Pairs] | Required: Yes, if the .eid file describes a mated connector, socket or | other similar interconnection structure. This keyword must not | be used if the [Number of Pins] keyword is used. |Description: Tells the parser the number of pairs to expect. Pairs are | simply the number of conductive paths in an interconnection. | Pairs are necessary since each path has at least two external | pins; one on each side of the interconnection device. |Usage Rules: The field must be a positive decimal integer. | Note: The simulator must not limit the Number of pin-pairs to | any value less than 1,000. |----------------------------------------------------------------------------- [Number of Pairs] 240 | |============================================================================= | Keyword: [Pin List] | Required: Yes, if the [Number of Pins] keyword has been used. | Either the [Pin List] or [Pair List] keyword must be used but | not both. [Pin List] is used only when the [Number of Pins] | keyword has been used and [Pair List] is used only when the | [Number of Pairs] keyword has been used. |Description: Tells the parser the set of names that are used for the part's | external pins and also defines pin ordering. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest". |Usage Rules: Following the [Pin List] keyword, the names for the pins are | listed. There must be as many entries listed as there are pins | given by the preceding [Number of Pins] keyword. Pin names must | be the alphanumeric external pin names of the part. The pin | names cannot exceed eight characters in length. | PWR, GND and NC are not legal pin names. |----------------------------------------------------------------------------- | | A SIMM CIRCUIT BOARD OR UNMATED CONNECTOR EXAMPLE | [Pin List] A1 A2 A3 | . | . A22 B1 | . | . |etc. | |============================================================================= | Keyword: [Pair List] | Required: Yes, if the [Number of Pairs] keyword has been used. | Either the [Pair List] or [Pin List] keyword must be used but | not both. [Pair List] is used only when the [Number of Pairs] | keyword has been used and [Pin List] is used only when the | [Number of Pins] keyword has been used. |Description: Tells the parser the set of names that are used for the part's | external pins, matches the names that are at opposite sides of | each conductive path and also defines pin ordering. The first | pin name given is the "lowest" pin, and the last pin name given | is the "highest". Pin names are assigned in column order. That | is, first all pin names on one side are assigned in the order | given, then the other side is assigned in the order given. |Usage Rules: Following the [Pair List] keyword, the paired pin names for the | pairs are listed. There must be as many pair entries listed as | there are pairs given by the preceding [Number of Pairs] keyword. | Pin names must be alphanumeric. They provide the internal names | that are used in the [Path Description] keyword. They are | matched to the external pin names of the part. The pin names | cannot exceed eight characters in length. The special pin name, | NC, is reserved to represent no-connection if a pin name is not | used on one side or the other of the interconnection. | PWR and GND are not legal pin names. |----------------------------------------------------------------------------- | | A MATED CONNECTOR EXAMPLE | [Pair List] RA1 PA1 RA2 PA2 RA3 PA3 | . . | . . RA22 PA22 RB1 PB1 | . . | . . |etc. etc. | |============================================================================ | Keyword: [Path Description] | Required: Yes, unless the [Coupled Path Model] Keyword is used. |Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of | the ICs mounted on that part. If describing a connector, | this keyword is used to describe the path from one pin of a | connector pin-pair to the other pin of the same pair. The | Fork and Endfork subparameters allow branching to other | pin-pair paths. NOTE that this means that pin names can appear | more than once. | | BOUNDARIES OF MODEL PATHS: | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. The pads need to be included | in the connector model. | | For any THROUGH-HOLE MOUNTED PART, the boundary should be at | the surface of the board on which the part is mounted. This | also applies to an IC plugged into a socket. The portion of | the IC pins that project into the socket must be included in | the socket model. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | CONNECTOR models must be mated connections unless the | connector is commonly used in an unmated condition such as in | a digital bus where all slots are not filled. Unmated | connector models would have only one boundary; the board- | connector boundary. | | Combination models can be made when two parts are always used | together, such as with a chip that is always intended to be | socketed. In that case, the socket-to-board boundary is the only | one used. | | Sub-params: Len, L, R, C, Fork, Endfork, Pin, Node |Usage Rules: Each individual connection path (user pin to node(s) | description or connector pin-to-pin description) begins with the | [Path Description] keyword and a path name, followed by the | subparameters used to describe the path topology and the | electrical characteristics of each section of the path. The | path name must not exceed 40 characters, blanks are not allowed, | and each occurrence of the [Path Description] keyword must be | followed by a unique path name. The individual subparameters | are broken up into those that describe a section's electrical | properties, and those that describe the topology of a path. | | SECTION DESCRIPTION SUBPARAMETERS: | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | treated as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0nH and the length of the | section is 2 'units', the inductance would be listed | as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | TOPOLOGY DESCRIPTION SUBPARAMETERS: | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference an external component | description file. The Pin subparameter is used to indicate | the point at which a path connects to a user visible pin. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a | branch. For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no arguments. | Node reference_designator.pin | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the pin | and reference designator of the external component. The | pin and reference designator portions of the argument are | separated by a period ("."). The reference designator is | mapped to an external component description (another .eid | file or a .ibs file) by the [Reference Designator Map] | Keyword. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also contain | the reserved word NC. The value of the Pin subparameter | must be one of the pin names listed in the [Pin List] or | [Pair List] section. | | Using The Subparameters to Describe Paths: | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R and C subparameters and the subparameter itself are separated | by an equals sign (=); whitespace around the equals sign is | optional. The Fork, Endfork, Node and Pin subparameters are | placed between section descriptions (i.e. between the concluding | slash of one section and the 'Len' parameters that starts | another). The arguments of the Pin and Node subparameter are | separated by white space; no equal sign nor slash (/) | character is used. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. However, as noted below, if a non- | zero length is specified, that section MUST be treated as | distributed elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the Len subparameter | is non-zero, then the L/R/C subparameters represent distributed | elements and both L and C must be specified, R is optional. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a node, | another pin or the reserved word, NC. | |--------------------------------------------------------------------------- | | A TYPICAL CONNECTOR DESCRIPTION EXAMPLE | [Path Description] J1-P1 Pin J1 Len = 2.0 L=8.35n C=3.34p R=0.01 / Len = 0.5 L=1.0n C=2.7p / Pin P1 | | AN EXAMPLE PATH FOR A SIMM MODULE | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u21.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u22.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u23.15 | | A DESCRIPTION USING THE FORK AND ENDFORK SUBPARAMETERS | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L= 1.0 C= 2p Node u23.15 Endfork Len = 1.0 l = 6.0n C=2.0p / Pin A5 | | A MORE COMPLEX CONNECTOR or BOARD DESCRIPTION EXAMPLE | | A metal part or trace with 2 connections on one side and one | connection on the other side. | +--------------+ | | | | RG1 +====+\ | NC | | L1 | | | R1 | | RG2 +====+/____L2__R2___+====+ PG2 | | | | +--------------+ [Path Description] RG1-NC Pin RG1 Fork Len = 1.0 L=0.3n R=0.01 / Pin RG2 Endfork Pin NC | [Path Description] RG2-PG2 Pin RG2 Len = 1.0 L=1.3n R=0.04 / Pin PG2 | |============================================================================= | Keyword: [Coupled Path Model] | Required: Not at the present time. This keyword is reserved for future use. |Description: This keyword will introduce a coupled model path description in | some format yet to be determined. | Sub-params: TBD |Usage Rules: TBD | |----------------------------------------------------------------------------- | [Coupled Path Model] Example TBD | |============================================================================= | Keyword: [Reference Designator Map] | Required: Yes, if any of the path descriptions use the Node subparameter. |Description: Indicates the linkage between a reference designator and the | external part it represents. |Usage Rules: The [Reference Designator Map] keyword must be followed by a | list of all of the reference designators defined in the Node | subparameter under the [Path Description] keyword. Each | reference designator is followed by the Name of the part to which | it is linked and the terms are separated by whitespace. The part | Name may be another .eid or .ibs model. A referenced .eid model | may be internal to the calling .eid file or it may be an external | file with an appropriately given pathname. |----------------------------------------------------------------------------- [Reference Designator Map] | | EXTERNAL PART REFERENCES | u23 80286.ibs u24 SIMM.eid u25 C:\LIBS\LS244.ibs | | AN INTERNALLY DEFINED .eid MODEL OF A 10K RESISTOR | u26 R10K | |============================================================================= | Keyword: [Model Data], [End Model Data], [Resistance Matrix], | [Inductance Matrix], [Capacitance Matrix], [Bandwidth], [Row] | Required: Not at the present time. These keywords are reserved for future | use for coupled models. |============================================================================= | Keyword: [End Electrical Description] | Required: Yes |Description: Marks the end of an Electrical Interconnect Description. |Usage Rules: This keyword must come at the end of each complete electrical | interconnect model description. | | Optionally, a comment may be added after the [End Electrical | Description] keyword to clarify which interconnect model has | ended. |----------------------------------------------------------------------------- [End Electrical Description] | End: 16Meg X 8 Simm Module | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: ------ =_NextPart_000_01BC0388.0B121020-- From owner-ibis Fri Jan 17 17:50:05 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id RAA09632 for ; Fri, 17 Jan 1997 17:50:01 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id RAA14485 for ; Fri, 17 Jan 1997 17:49:46 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma014348; Fri Jan 17 17:49:20 1997 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA13383 for ibis@vhdl.org; Fri, 17 Jan 97 17:48:17 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA29801; Fri, 17 Jan 97 17:50:16 PST Date: Fri, 17 Jan 97 17:50:16 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9701180150.AA29801@rockie.nsc.com> To: ibis@vhdl.org Subject: Final Agenda of IBIS Summit (Jan20th 1997) Cc: huq@rockie.nsc.com Agenda for Jan20th 1997 IBIS Summit Place: Westin Hotel (Santa Cruz conference Room - 1st floor) 5101 Great America Parkway Santa Clara, California (408)986-0700 Date: Jan 20th Monday(one day) Time: 8am - 5pm Time Topic Presentor --------------------------------------------------------------------- 8:00 Continental Breakfast All 8:30 - Sign-In All - Intros of Officers/Attendees Huq 8:50 Review of summit Agenda Huq - Open for New Issues 9:00 ANSI/EIA-656(IBIS)overview Huq(National Semi) - Web site at EIA - ftp site at vhdl.org 9:15 EIA Membership Rusher(EIA) IEC update 9:30 IBIS modeling at Alcatel Fitzpatrick(Alcatel) 10:00 Overview of Visiual IBIS Crisafulli(Hyperlynx) Editor for Windows, and Solicitation of Ideas for Version 2.0 10:30 Signal Integrity & IBIS Telian(Cadence) 11:20 Problems representing ABT Powell(Quad Design) Models using IBIS 12:00 Lunch 1:00 An IBIS survey - HPEEsof Wilson(HPEEsof) 1:20 Modeling Early Clamps in IBIS Muranyi(Intel) 2:00 BIRD 36d: Electric descriptions Peters(Intel) of boards and connectors Other items -DAC 97 IBIS meeting plans -IBISv3.0 ratification -s2ibis2 -cookbook for v2.1 Next Teleconference schedule Huq 5:00 Meeting adjourned From owner-ibis Wed Jan 22 23:24:58 1997 Received: from hupa.snfc21.pbi.net (hupa.snfc21.pbi.net [206.13.28.16]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id XAA17524 for ; Wed, 22 Jan 1997 23:24:58 -0800 (PST) Received: from default (ppp-206-170-26-202.sntc01.pacbell.net [206.170.26.202]) by hupa.snfc21.pbi.net (8.8.4/8.7.1) with SMTP id XAA27137 for ; Wed, 22 Jan 1997 23:23:38 -0800 (PST) Message-ID: <32E71192.79E6@pacbell.net> Date: Wed, 22 Jan 1997 23:21:54 -0800 From: Quad Design Technology X-Mailer: Mozilla 2.02E (Win95; I) MIME-Version: 1.0 To: ibis@vhdl.org Subject: IBIS face to face Content-Type: multipart/mixed; boundary="------------4F2A539D6659" This is a multi-part message in MIME format. --------------4F2A539D6659 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ibis type persons, I am still at Design Supercon but I thought you might like to get the minutes from the meeting such as they are. I will be working with Syed to make available some computer readable format of any of the presentations that the presenters wish to provide. take care, Jon --------------4F2A539D6659 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ibis meeting 1.20.txt" Minutes of the ANSI/EIA-656 Meeting IBIS 1/20/97 at SUPERCON97 at the Santa Clara Westin Secretaries Notes: This was an extremely well attended meeting containing representatives from all of the various areas of IBIS interest, including IC manufacturers, Connector manufacturers, EDA vendors, and end users. There were several interesting presentations on various topics. I have attempted to note some of the highlights of those topics and will work with Syed to make the actual presentations available to all IBIS members via the ftp reflector or WWW site. I apologize for the roughness of this data but it is hard to type and argue at the same time. Special thanks to Syed Huq and National Semiconductor for hosting the IBIS face to face. They provided an excellent room, superior refreshments, and a microphone so we could hear Stephen Peters. Introductions. Syed Huq: Presiding Jon Powell: acting secretary Patti Rusher: EIA Representative Review of schedule. Questions about who is providing models. Comments from the librarian on providing models to the library or seeking assistance in model development. Jon Powell has offered to run QA checks on ANY models that emailed to him at jonp@qdt.com. He is also soliciting models to be added to the IBIS reflector. Jon has not received any (new) models for release during the last 8 months. (well, maybe from Arpad but those don’t count because he is so good at it). Syed: IBIS Road map Use of the reflector IBIS Poster Page If you wish you company logo added or updated, please send your logo to jonp@qdt.com. It should be in bmp or tiff format and have a size of about 800x200 pixels. Bigger is better as he can size it down. EIA Membership Update (patty) 23 Members to date. Committee Membership is $500.00 Membership applications are available from patty and will soon be available on the web at the IBIS site. IBIS will be represented at DAC in EIA booth. IBIS is number 2 in the EIA on hits on the web page. Over 7000 hits since page inception. IEC Update: is going through the international technical committee. Will be assigned to Hillary Con. Hope to have out as a full standard in the next two years. Patti distributed membership bills at the meeting. John Fitzpatrick: User Presentation. Makes telephone switches. Alcaltel has committed to building a large library of IBIS models. Have classically solved this problem using Bergeron Diagrams. Want to use for simulation and extracting information to create design rules. Found %100 errors in IBIS models (but none of those were off the reflector). They found that they had to generate many of the models themselves. Will be building models from an SI lab and checking all Models. Want to use IBIS models to do constraint driven routing. Will be using IBIS files as a database to extract information for design rules. Such things as : do 3 volts devices need protection? Can also use IBIS to help with crosstalk control and route constraint generation for correct by design routing. Don’t know output impedance of a component to select proper series termination but you can get this information from IBIS. Wish lists: 1) Unable to model series components. (very important) 2) Non-monotonic IV curve models. 3) R,L,C description capability. 4) BUS Switch Models (This is a very important issue) They want to keep all models in IBIS format and right now they are being forced to keep things in multiple formats because IBIS does not support the above issues. Less Important wishes: 1) Easier to understand IV curves: suggests the need for new keywords that support pure measurement values and let the simulator do the necessary subtractions etc. (Audience suggests that development of a better editor or input technology). 2) More background information in the model. Contact information, Brief description of the component, or URL to component description. 3) Unique buffer names. Guidelines on buffer naming: each supplier should use a unique meaningful name. 4) Model Verification: 5) Long term goal: Full Electrical Specification (don’t need data-sheets). 6) Recommended paper data-sheet format for representing IBIS models 7) Better specification of “minimum” data to have a IBIS models. 8) IBIS as a specification tool ASICs (to allow for a choice of output buffers) Second sourcing (give us a part that matches this model) Industry-standard I/O (“Golden” ibis models representative of industry standard technologies (LCT, LVC, AC FAST, Memories etc.) Kelle on Visual IBIS editor for Windows Free on several websites. Seeking inputs on how to improve the editor. Win3.1, WIN95 or WINNT but runs better on 95 and NT has built in 2.1 and 1.1 syntax checker. Skeleton Generator Has built-in viewers for seeing the various tables graphically. (cannot edit graphically). This viewing can greatly assist in debugging the data. Can get this from www.hyperlynx.com Looking to do Feature Update and looking for suggestions. Sheets were passed out which asked people for their inputs. Suggestions given by Audience: 1) show loading conditions on waveforms 2) overlay multiple curves for comparison of different models. 3) Don’t show clamp of data beyond data range. Just show the end of the data. 4) Veribest might provide a SPICE2IBIS converter in WIN95 executable format. 5) remove “CONTROL-M” for output because they aren’t allowed in standard. (is this true?) 6) Graphically edit curve. 7) Pop-up Menu with blanks for all input values. email: kellee@hyperlynx.com ASIDE: we need to define in IBIS what happens at the end of the IBIS data. Contact Ian about putting SPICE2IBIS WINNT version on the web site. 5 minute break. Don Telian: Signal Integrity Engineering in High-speed Digital Systems Surveyed 5 managers of SI groups and put their feedback in this presentation (see don’s slides for actual presentation). The goal of this presentation is to define the SI engineer and put him on the map. Electrical description is moving from a static form to a dynamic form. 7 roles of SI Engineer: 1) Pioneering and Defining 2) Partitioning and Approximating 3) Modeling and Measuring 4) Design and Optimizing 5) Quantifying and verifying 6) Reducing and Simplifying 7) Correlating and Debugging Resolve not to whine and use good judgment. ABT simulation problems Jon Powell The TI abt SPICE model demonstrates a charged pumping and load dependent IV curve phenomena that jon does not believe can be represented with current IBIS technology. Jon presented an encapsulation of the circuit and showed some example simulations. Jon will post full report to the IBIS reflector for further discussion. Carl - HP EESOF IBIS survey How do people develop models: 1) Most use SPICE to develop models (in fact %100 of responders derived from SPICE) 2) Opportunity for commercialization of SPICE to IBIS converter (but the price they would pay is probably pretty small) 3) 4 out of 7 said they did use some measurement techniques to do the simulation. 4) No recognized budget for generating models. Arpad: Integrated Termination for Low Power, Low Cost, High Speed Signaling This is a new feature that Intel is working on putting in their chips. PCB needed to develop a low cost desktop chip set solution for the P6. Had to be low cost as the PC market is very competitive. GTL bus needs two terminators. This cost too much money and current. Found a good technique that works in both GTL and CMOS. Lets you get rid or resistors. Worst case circuit: T circuit with termination in the middle. Terminating at both ends causes. So they need a termination with a special IV curves with no currents at VOH and VOL. Use “Early” clamps to match diodes to desired curve. In GTL systems, VOL drifts because it varies on buffer strength (and the strength of the pullup device). Static Early clamps are easy to model by inserting IV curves into the clamps. Dynamic curves are harder. Perhaps shift a IV curve as controlled by a VT curve. But the shifted IV curve might not be the same as the original IV curve. The timing is completely dependent on the implementation of the method, which is not defined. Arpad wants to come up with a IBIS description method that encompasses all possible implementation techniques. Suggestion was made to try and fit this into the Multi-Driver bird. It would have to be modified to a multi- receiver technology with a threshold test. Arpad will get this onto the reflector Steven Peters: Bird 36.d Two Purposes: Simple board descriptions (SIMMS) Connectors (coupled and uncoupled) Complex (coupled) board descriptions best left to physical/layout extraction (EDIF 4.0 calls out IBIS models). Some Highlights: Bird 36.d defines interconnect boundaries. In general [application info] is used for connectors. Provides critical information that the connector vendors feel is important, like the rise time that the model is good for (bandwidth of model?) [Number of pins] used for boards, unmated connectors and such. [Number of pairs] is there to support connectors that use an eventual matrix description. Bird does not make clear that nodes is not a general named node for interconnection (this is being fixed). Makes clear that if length > 0, then it is a distributed element. COUPLING: goal is to describe a connector, not a general board interconnect. Basic approach is cascaded, name matrix One problem is data reduction: do you really want to describe a 200 pin, 4 row connector? Another Problem: Accuracy (?) Must agree on what data represents/ how to process data. Mated model includes both male and female pins in the same connection Unmated is only the male or female part. Lots of argument concentrating on what is an acceptable way to specify a coupling matrix for connectors. I think it was finally agreed that such a matrix formalization does exist and the syntax needs to be agreed on. DC Sessions was concerned that there is not a definition for the local ground on a SIMM to be able to model local ground bounce on the SIMM. Next Teleconference will be Feb. 14th Reservation number will be put on the reflector. First Topic for the 14th: Clarification of what needs to be done for 3.0 Discussion on model verification: Putting signatures into IBIS models that prove that certain checks were run? It is the EDA companies responsibility to service their customers. Actel asked for us to make the SOURCE keyword required such that all models can be traced. But that suggestion was met with some opposition as we have no way to enforce. Meeting Adjourned --------------4F2A539D6659-- From owner-ibis Thu Jan 23 16:05:49 1997 Received: from kaw.co.jp (kj24.kaw.co.jp [202.218.183.130]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id QAA18927 for ; Thu, 23 Jan 1997 16:05:46 -0800 (PST) From: mthai@kaw.co.jp Received: from kj46 (kj46.kaw.co.jp [202.218.183.147]) by kaw.co.jp (8.6.12+2.5Wb7/3.4W2) with SMTP id JAA12444 for ; Fri, 24 Jan 1997 09:09:10 +0900 Received: by kj46 (4.1/3.4W2) id AA04953; Fri, 24 Jan 97 08:59:55 JST Date: Fri, 24 Jan 97 08:59:55 JST Message-Id: <9701232359.AA04953@kj46> To: ibis@vhdl.org Subject: Unsubscribe me Please unsubscribe me. mthai@kaw.co.jp From owner-ibis Thu Jan 23 17:41:59 1997 Received: from ami4000.hei.co.kr ([202.30.128.30]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id RAA19053 for ; Thu, 23 Jan 1997 17:41:51 -0800 (PST) Received: from srgate.sr.hei.co.kr (srgate.sr.hei.co.kr [166.125.1.1]) by ami4000.hei.co.kr (8.6.12h2/8.6.9) with ESMTP id KAA17081 for ; Fri, 24 Jan 1997 10:42:17 +0900 Received: by srgate.sr.hei.co.kr; id KAA25685; Fri, 24 Jan 1997 10:36:17 +0900 Received: from unknown(166.125.47.85) by srgate.sr.hei.co.kr via smap (3.2) id xma025679; Fri, 24 Jan 97 10:36:12 +0900 Received: from dramh15.hei.kor (dramh15 [166.125.47.42]) by mrnd.sr.hei.co.kr (8.6.12h2/8.6.12) with ESMTP id KAA07487 for ; Fri, 24 Jan 1997 10:37:42 +0900 Received: from dramh15 by dramh15.hei.kor (SMI-8.6/SMI-SVR4) id KAA09133; Fri, 24 Jan 1997 10:36:50 +0900 Sender: jrchun@sr.hei.co.kr Message-ID: <32E81232.44ED@sr.hei.co.kr> Date: Fri, 24 Jan 1997 10:36:50 +0900 From: Chun Jung-Ryoon X-Mailer: Mozilla 2.02 [ko] (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Unsubscribe me Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Please unsubscribe me. ################################################# $)C Jung-Ryoon Chun (C5 A$ 7{) Technical Staff Design Dep.2, Memory R&D Division Hyundai Electronics Industries (HEI) Tel : 082-0336-30-4425 ################################################# From owner-ibis Mon Jan 27 18:42:07 1997 Received: from sisfw1.sis.com.tw ([203.67.208.1]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id SAA26575 for ; Mon, 27 Jan 1997 18:41:55 -0800 (PST) From: mhliao@sis.com.tw Received: from axp.sis.com.tw by sismg.sis.com.tw; (5.65v3.2/1.1.8.2/06Jan96-1220PM) id AA09927; Tue, 28 Jan 1997 10:38:12 +0800 Received: from [192.9.205.121] by axp.sis.com.tw; (5.65/1.1.8.2/03Jun96-0539PM) id AA06004; Tue, 28 Jan 1997 10:41:28 +0800 Message-Id: <9701280241.AA06004@axp.sis.com.tw> Comments: Authenticated sender is To: ibis@vhdl.org Date: Tue, 28 Jan 1997 22:42:36 +0000 Subject: (Fwd) Re: Where can I find an IBIS file for a DIMM module Reply-To: mhliao@sis.com.tw Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Forwarded message: From: Self To: ibis@vhdl.org ibis-user@vhdl.org Subject: Re: Where can I find an IBIS file for a DIMM module Reply-to: mhliao@sis.com.tw Date: Tue, 28 Jan 1997 21:19:25 Hi everyone : I need an IBIS file for a DIMM module. Where can I find an IBIS file for a DIMM module? I do have an IBIS file for one synchronous DRAM chip. Or is there any other way to modify the IBIS file I have to an IBIS file for the DIMM module? Thanks for any response. Best Regards Ming-Hao Liao, SiS Taiwan From owner-ibis Tue Jan 28 10:07:03 1997 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id KAA29002 for ; Tue, 28 Jan 1997 10:07:02 -0800 (PST) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQcama11344; Tue, 28 Jan 1997 13:04:59 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 28 Jan 1997 13:05:00 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00600; Tue, 28 Jan 97 09:40:42 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA04840; Tue, 28 Jan 97 09:40:41 PST Received: from uucp3.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp3.UU.NET [192.48.96.34]) id QQcalw15745; Tue, 28 Jan 1997 12:04:30 -0500 (EST) Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Tue, 28 Jan 1997 12:04:30 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00515; Tue, 28 Jan 97 08:42:02 PST Received: from peterbilt by hal.qdt.com (4.1/SMI-4.1) id AA04549; Tue, 28 Jan 97 08:42:02 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <32EE2BC8.4B761E89@qdt.com> Date: Tue, 28 Jan 1997 08:39:36 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: uunet!uunet!sis.com.tw!mhliao@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: (Fwd) Re: Where can I find an IBIS file for a DIMM module References: <9701280241.AA06004@axp.sis.com.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS does not currently support complex objects like DIMM modules. We are working on it but it will at least a year before there is official EIA standard approval of any complex package methodology. If you need to model a DIMM you will have to do it in the modeling language of whatever simulator you are using. sorry Jon Powell IBIS librarian. ps. if any other ibis people diagree with me I'm sure they will let you know. (and let me know too, please). From owner-ibis Wed Jan 29 16:14:39 1997 Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id QAA03151 for ; Wed, 29 Jan 1997 16:14:39 -0800 (PST) Received: from hawk.dtc.hp.com (hawk.dtc.hp.com [15.0.185.26]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id QAA19818 for ; Wed, 29 Jan 1997 16:13:13 -0800 (PST) Received: from localhost by hawk.dtc.hp.com with SMTP (1.39.111.2/16.2+CNS 4.0 ) id AA012393192; Wed, 29 Jan 1997 16:13:12 -0800 Message-Id: <199701300013.AA012393192@hawk.dtc.hp.com> To: ibis@vhdl.org Cc: pgregory@hpdmd48.boi.hp.com Subject: Clarification of Temperature Range Date: Wed, 29 Jan 1997 16:13:12 -0800 From: leandro Hi, I just wanted a clarification on what the temperature range values should be for the min and max columns in the IBIS models. From the Cookbook (what I believe is correct): For CMOS: min=max temp. <-- slowest, weakest case max=min temp. <-- fastest, strongest case The confusion comes with the IBIS spec, which has the example of: variable typ min max [Temperature Range] 27.0 -50 130.0 Is this example correct??? It seems to contradict what min and max stand for. I think that -50 should be 150 and the 130.0 should be 0. Thanks. -Leandro _________________________________________________________________ Leandro Chua Design Engineer HP ICBD/DTC -- PALO ALTO, CA Library Design Group mail-stop: 6U-I e-mail: leandro@dtc.hp.com phone: (415)857-7343 fax: (415) 852-8676 _________________________________________________________________ From owner-ibis Wed Jan 29 16:58:14 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.8.4/8.8.3) with ESMTP id QAA03242 for ; Wed, 29 Jan 1997 16:58:13 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Thu, 30 Jan 1997 00:56:53 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id QAA08671; Wed, 29 Jan 1997 16:53:19 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 29 Jan 97 16:53:19 PST Date: Wed, 29 Jan 97 16:52:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: pgregory@hpdmd48.boi.hp.com Subject: Re: Clarification of Temperature Range Text item: Leandro, If you read the section "Notes on Data Derivation Method" at the end of the spec. you will understand. The cookbook didn't consider the bipolar devices. Bipolars get stronger with higher temperatures, CMOS get weaker. The min. column should get the value that makes the buffer waeker, i.e. larger number for CMOS, smaller number for Biolar. Arpad ============================================================================= Hi, I just wanted a clarification on what the temperature range values should be for the min and max columns in the IBIS models. From the Cookbook (what I believe is correct): For CMOS: min=max temp. <-- slowest, weakest case max=min temp. <-- fastest, strongest case The confusion comes with the IBIS spec, which has the example of: variable typ min max [Temperature Range] 27.0 -50 130.0 Is this example correct??? It seems to contradict what min and max stand for. I think that -50 should be 150 and the 130.0 should be 0. Thanks. -Leandro _________________________________________________________________ Leandro Chua Design Engineer HP ICBD/DTC -- PALO ALTO, CA Library Design Group mail-stop: 6U-I e-mail: leandro@dtc.hp.com phone: (415)857-7343 fax: (415) 852-8676 _________________________________________________________________ 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***. From: leandro Date: Wed, 29 Jan 1997 16:13:12 -0800 Subject: Clarification of Temperature Range Cc: pgregory@hpdmd48.boi.hp.com To: ibis@vhdl.org Message-Id: <199701300013.AA012393192@hawk.dtc.hp.com> Received: from localhost by hawk.dtc.hp.com with SMTP (1.39.111.2/16.2+CNS 4.0 ) id AA012393192; Wed, 29 Jan 1997 16:13:12 -0800 Received: from hawk.dtc.hp.com (hawk.dtc.hp.com [15.0.185.26]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id QAA19818 for ; Wed, 29 Jan 1997 16:1 3:13 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by vhdl.vhdl.org ( 8.8.4/8.8.3) with ESMTP id QAA03151 for ; Wed, 29 Jan 1997 16:14: 39 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.4/8.7.3) with ESMTP id QAA25727; Wed, 29 Jan 1997 16:23:49 -0800 (PST) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.8.2/8.7.3) with ESMTP id QAA17700; Wed, 29 Jan 1997 16:21:19 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Jan 29 17:06:01 1997 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.8.4/8.8.3) with SMTP id RAA03265 for ; Wed, 29 Jan 1997 17:06:00 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id RAA12077 for ; Wed, 29 Jan 1997 17:04:39 -0800 Received: from cadence.cadence.com(158.140.98.115) by mailgate.cadence.com via smap (V1.0mjr) id sma854586278.012070; Wed Jan 29 17:04:38 1997 Received: from cds10018 (cds10018.cadence.com [158.140.8.28]) by cadence.Cadence.COM (8.7.3/8.7.3) with SMTP id RAA27772 for ; Wed, 29 Jan 1997 17:04:34 -0800 (PST) Received: by cds10018 (5.65+/1.4) id AA03870; Wed, 29 Jan 97 17:05:44 -0800 Date: Wed, 29 Jan 97 17:05:44 -0800 From: venu@cadence.com (Venugopal Paddabhiramaieyengar) Message-Id: <9701300105.AA03870@cds10018> To: ibis@vhdl.org I am interested in continuing to get latest information about ibis Please add my name to the reflectors distribution list. my name is venugopal pattabhiramaiyengar my e-mail is venu@cadence.com thanks venu