From cpk@Cadence.COM Mon Dec 6 08:23:17 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02906; Mon, 6 Dec 93 08:23:17 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id IAA21294 for ; Mon, 6 Dec 1993 08:15:05 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma021244; Mon Dec 6 08:14:59 1993 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA18089; Mon, 6 Dec 93 08:17:06 -0800 Received: by hot (5.65+/1.5) id AA25302; Mon, 6 Dec 93 11:21:12 -0500 Date: Mon, 6 Dec 93 11:21:12 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9312061621.AA25302@hot> To: ibis@vhdl.org Subject: Re: spice2ibis Hi Guys: One of the issues which keeps coming up in our relationship with customers is that there is a need to have some automated mechanism to generate ibis models from their Spice structural models. I know Quad (John , are you there?) provides similar service to their customers. I think this is a topic , where IBIS committee can set standards or at the minimum set guidelines on how to generate v-i data using simulated "measurements". Additional standards also may include actual physical measurements. I raised this issue at the summit and sensed a certain degree of support for that. Is that support still there? What do other IBISians think of it? Do you think we should work toward a bird on this issue? Thanx -kumar From 71436.1314@CompuServe.COM Mon Dec 6 09:21:49 1993 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03509; Mon, 6 Dec 93 09:21:49 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id MAA08718; Mon, 6 Dec 1993 12:20:37 -0500 Date: 06 Dec 93 12:17:20 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: "INTERNET:cpk@Cadence.COM" Cc: IBIS ALL Subject: +Postage Due+Re: spice2ibis Message-Id: <931206171720_71436.1314_BHA77-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx Re: Automatically converting SPICE models to IBIS format. This sounds like a great idea. I have been considering something like this myself. A program could be written which could take a spice model and assemble it into a new spice deck which allows the model to generate V/I data, measure capacitance, slew times etc. from within spice. Another program could than translate the output data into an IBIS file. Companys like Texas Instruments already have extensive lists of SPICE models available which could than be converted into IBIS format. I wonder if you would comment on this Bob? (Bob Ward, TI) This type of program would be relatively generic, however it would probably require a few tweeks to make it work with the different flavors of spice. It seems to me that the companys with SPICE packages and large investments in SPICE models are the ideal candidates to do a translation program like this. It is in everyone's best interest including the SPICE companies because everyone end's up with more models. Perhaps several companys could jointly sponser a consultant to create the generic form of the translator for say Berkley SPICE. Than the other SPICE companys could modify it to their own needs. If there is suffient interest from other people we could put out an official BIRD on this proposing the translator as an official IBIS project. Kellee From mbs@eos.ncsu.edu Mon Dec 6 10:38:33 1993 Return-Path: Received: from mbs.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04108; Mon, 6 Dec 93 10:38:33 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA04370; Mon, 6 Dec 1993 13:37:26 -0500 From: mbs@eos.ncsu.edu Message-Id: <9312061837.AA04370@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: Automatically converting SPICE models to IBIS format. Date: Mon, 06 Dec 93 13:37:25 EST Kellee Crisafulli, HyperLynx, writes >A program could be written which could >take a spice model and assemble it into a new spice deck which allows the >model to generate V/I data, measure capacitance, slew times etc. from >within spice. Another program could than translate the output data into an >IBIS file. We are are being funded by ARPA to develop just such a translation program. We also plan to use laboratory measurements (in particular large signal TDR/TDT) to develop IBIS models. We begin work on the project on January 1, 1994. The work was initially suggested by C. Kumar of Cadence. A detailed plan and schedule will be available at the end of December. Michael Steer North Caraolina State University mbs@ncsu.edu From bward@dadhb1.ti.com Mon Dec 6 11:11:26 1993 Return-Path: Received: from lobby.ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04280; Mon, 6 Dec 93 11:11:26 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by lobby.ti.com with SMTP (5.65c/LAI-3.2) id AA18265; Mon, 6 Dec 1993 13:10:39 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA03221; Mon, 6 Dec 1993 13:07:05 -0600 Message-Id: <199312061907.AA03221@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA19791; Mon, 6 Dec 1993 13:04:43 -0600 Date: Mon, 6 Dec 1993 13:04:43 -0600 From: Bob Ward To: ibis@vhdl.org Subject: Spice2ibis Ibis folks! This is in specific reply to Kellee's letter, but it is applicable to the whole group. As part of selling the concept of ibis around here, I find that I have to come up with just such a conversion as Spice to ibis and / or real live measurements to ibis. I have been thinking about a program to do just about what Kellee proposed, specifically making "Spice measured data" into a data file in much the same form as would be "Lab measured data", such as from a nest of GPIB controlled instruments for instance, so that a common back end formatter could be written to convert either one to ibis format. As I am envisioning it there would be a "spice front end", one or more "instrument front end(s)", an "ibis generating back end", and a user interface to control all this. I would not want to be tied to GPIB, I only use it as one example. There are several competing lab instrument control "standards", any of which could be made to work. In fact if the system be designed modularly enough, it would just be another module called by the user interface so that GPIB is used one time, VXI another, and something else later, all with minimal impact on the code. Yes I am interested in doing something like this since I will have to anyway for my own purposes. In fact the Spice invocation module should be replaceable, as well, to accommodate different spice dialects, invocation styles, and measurement capabilities. I can even foresee having several dialects of Spice available through the user interface. I have less interest in a consultant at this time, but I am not outrightly against the idea either. I think we should have a little proof of concept experimentation to see what it is we REALLY want the consultant to do before we engage him, however. I had thought that there was a move afoot to standardize a measurement methodology, at least for "elderly" parts. If so, that is a prerequisite, in my mind, for this kind of a program so that we can all make measurements with some assurance of comparability. Was there not a BIRD to be issued on this already? If not I would like to see one so that we have a written "requirements document" of sorts for such a measurement methodology. I would be interested in contributing to such a document, but cannot take ownership of it at this time due to time constraints. ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From cpk@Cadence.COM Mon Dec 6 11:39:17 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04450; Mon, 6 Dec 93 11:39:17 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id LAA29961; Mon, 6 Dec 1993 11:31:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma029927; Mon Dec 6 11:30:07 1993 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA08079; Mon, 6 Dec 93 11:32:12 -0800 Received: by hot (5.65+/1.5) id AA25448; Mon, 6 Dec 93 14:36:20 -0500 Date: Mon, 6 Dec 93 14:36:20 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9312061936.AA25448@hot> To: ibis@vhdl.org, bward@dadhb1.ti.com Subject: Re: Spice2ibis Hi folks: As I mentioned earlier Quad has something similar. Is Quad (hi John) willing to share/spread their ideas/experience on this subject? Spice2Ibis is a good vechile for getting industry support for IBIS from vendors like TI, MOTO etc. I suggest that we confine our initial efforts to just DC v-i measurements and simple AC measurements like slew rate. - kumar From lmsi!milpitas.lmc.com!randyh@UB.com Mon Dec 6 13:51:10 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05324; Mon, 6 Dec 93 13:51:10 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA14053; Mon, 6 Dec 93 13:35:57 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA24938; Mon, 6 Dec 93 12:55:18 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA02729; Mon, 6 Dec 93 12:55:18 PST Date: Mon, 6 Dec 93 12:55:18 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312062055.AA02729@fiji.lmsi.com> To: 71436.1314@compuserve.com Subject: Re: SPICE to IBIS translator Cc: ibis@vhdl.org Kelley, If this is truly that simple a project (1 man-month), LMC will fund it out of our current DIE work. Kelly, can you or your organization due it in that time? Do people feel we could get a useful tool with that amount of effort. (By the way, the results (source code) would be public domain.) If it is a 2-3 man-month effort, we may still be able to fund it but would need to get contracting officer approval. If it is a larger project, there is a government BAA coming out in 2 weeks dealing with model availability. I would be glad to team with anyone interested to put a larger proposal (response) together to support the effort. Again, all results would be in the public domain. What about NC State? My understanding is they are under some funding from ASEM to do basic measurement and extraction work on I/O Buffer models? Is there a related project here? Have you already solved the problem? Randolph Harr, Program Manager and Senior Scientist Corporate Technology Office Logic Modeling Corporation randyh@lmc.com From 71436.1314@CompuServe.COM Tue Dec 7 08:52:29 1993 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14900; Tue, 7 Dec 93 08:52:29 PST Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.930129sam) id LAA17041; Tue, 7 Dec 1993 11:51:21 -0500 Date: 07 Dec 93 11:47:27 EST From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: "INTERNET:mbs@eos.ncsu.edu" Cc: IBIS ALL Subject: From: Kellee Crisafulli, Re: SPICE2IBIS and North Carolina State Message-Id: <931207164727_71436.1314_BHA20-1@CompuServe.COM> From: KELLEE Crisafulli Michael, I really like what I read in your email. If your group is definintely working on this translation perhaps the IBIS group can rely on North Carolina State to create this program. I have a few questions: 1) Do you have any delivery schedule, start, stop dates? 2) Have you broken the problem into phases that you could tell us about. The reason I ask is that this would give us (IBIS) a method of monitoring your progress. 3) Is the project funded, proposed, staffed? 4) What language will the translation portions be written in? 5) Which flavor and version of SPICE would you use? 6) Could you share a copy of the proposal with the IBIS committee. 7) Would you be willing to allow the IBIS committee to comment on your proposal and suggest changes. 8) Could the IBIS committee help you in any way? 9) Would there be any problem in making all the source code available to industry? 10) If students will be involved what level are they (under grad, Masters, PhD etc.)? There seems to be alot of interest in this possibility. It seems alot of people all had similiar thoughts. It would be good if there isn't alot of duplicated effort. It seems that Quad design, Cadence, and TI are also very interested. Here's hoping that all your IBIS birds fly smooth and high. Kellee From mbs@eos.ncsu.edu Tue Dec 7 09:35:41 1993 Return-Path: Received: from mbs.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15137; Tue, 7 Dec 93 09:35:41 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08154; Tue, 7 Dec 1993 12:34:36 -0500 From: mbs@eos.ncsu.edu Message-Id: <9312071734.AA08154@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: spice/measurements to IBIS model converter Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 93 12:34:36 EST Kellee, Randy, Kumar and other IBI, I am in the process of extracting the schedule etc. for the SPICE/Measurement to IBIS modeling effort from a larger document. It was part of a system partitioning project funded by CSTO (Computer Systeme Technology Office) of ARPA (Contact: Bob Parker). Yes, everything will be entirely open, written in C, and hopefully with experimental verification. The effort funded is essentially one graduate student for a year plus a fraction of my time. However we have done this sort of thing before and have many software tools available. We received our final piece of equipment (a Tektronix IPA-310 system) last week. Our ARPA kick-off meeting is January 19 so I hope to have comments on the document and a plan worked out before then. More in a day or so. ***************************************************************************** Dr. Michael Steer mbs@ncsu.edu Associate Professor 919-515-5191 Electrical and Computer Engineering Department 919-515-5523 (fax) North Carolina State University, Raleigh, NC 27695-7911 From bward@dadhb1.ti.com Tue Dec 7 10:48:59 1993 Return-Path: Received: from lobby.ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15738; Tue, 7 Dec 93 10:48:59 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by lobby.ti.com with SMTP (5.65c/LAI-3.2) id AA00577; Tue, 7 Dec 1993 12:48:19 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA07967; Tue, 7 Dec 1993 12:26:20 -0600 Message-Id: <199312071826.AA07967@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA21728; Tue, 7 Dec 1993 12:23:57 -0600 Date: Tue, 7 Dec 1993 12:23:57 -0600 From: Bob Ward To: ibis@vhdl.org Subject: AC IV Curves All- At the recent summit in Santa Clara, someone observed that measuring IV data into a variety of terminating impedances allowed for the construction of so- called AC IV curves. Now I think I know what is being referred to here, but I would like to be sure I am thinking the same thing as was alluded to. So since I cannot remember who said it, would whoever that was that mentioned it please elaborate on it a little? You can reply either in personal e-mail or on the reflector as you see fit, but please do reply. I am trying to gather some ammunition for making the argument that ibis CAN capture AC phenomena in spite of what certein detractors here within think. Thanks in advance! ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From ccm!Will_Hobbs@intelhf.intel.com Thu Dec 9 10:52:59 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08610; Thu, 9 Dec 93 10:52:59 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p7qSv-000MO9C; Thu, 9 Dec 93 10:51 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p7qY3-0000NCC; Thu, 9 Dec 93 10:57 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 9 Dec 93 10:57:11 PST Date: Thu, 9 Dec 93 10:57:11 PST From: Will Hobbs Message-Id: <931209105711_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Bird #5 ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 5 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: 6 December 1993 DATE ACCEPTED BY IBIS OPEN FORUM: 7 December, 1993 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 20 characters. Two additional columns named "gnd" and "pwr" are added to the IBIS file's [Pin] section, indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin] specification would be as follows: [Pin] signal_name model_name gnd pwr 1 RAS0# Recvr1 GNDBUS1 PWRBUS1 2 OUT1# Driver1 GNDBUS2 PWRBUS2 .... ... ... 11 GND GND GNDBUS1 NA 12 GND GND GNDBUS1 NA 13 GND GND GNDBUS1 NA .... 21 GND GND GNDBUS2 NA 22 GND GND GNDBUS2 NA 23 GND GND GNDBUS2 NA .... 31 VDD POWER NA PWRBUS1 32 VDD POWER NA PWRBUS1 33 VDD POWER NA PWRBUS1 .... 41 VDD POWER NA PWRBUS2 42 VDD POWER NA PWRBUS2 43 VDD POWER NA PWRBUS2 Please note that in the above example, we have excluded the columns of the [Pin] specification (such as R_pin, etc.) which are not relevant to the present BIRD. Explanation: In the above example, the "model_name" parameters for the power and ground pins are the reserved names "POWER" and "GND", as they were before. For a GND pin, the entry in the "gnd" column designates the ground bus to which it is attached. The entry in the "pwr" column is NA because there is, of course, no connection to any power bus. The situation for a POWER pin is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the I-V model Recvr1 which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of the I-V model Driver1 which connects to PWRBUS2 and GNDBUS2. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. ****************************************************************************** From ccm!Don_A_Telian@intelhf.intel.com Thu Dec 9 11:39:51 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09218; Thu, 9 Dec 93 11:39:51 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p7rCH-000MNoC; Thu, 9 Dec 93 11:38 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p7rHR-00008mC; Thu, 9 Dec 93 11:44 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 9 Dec 93 11:44:04 PST Date: Thu, 9 Dec 93 11:44:04 PST From: Don A Telian Message-Id: <931209114404_2@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Subject: Re: Bird #5 Text item: Text_1 A couple comments on BIRD 5: 1) These new columns MUST be optional. I could not find the word "optional" anywhwere in the text. 2) It's presently marked "accepted" on Dec. 7, one day after it was submitted. I assume this is an error. 3) The team had worked to make sure a line of information does not exceed 80 characters. How does it fold in if R_pin (etc) is still used. There are currently rules on using 3 or 6 columns. What are the new rules? Is 80 characters no longer a concern? This BIRD needs to show what EXACTLY is the new text proposed for IBIS. Don Telian From lmsi!milpitas.lmc.com!randyh@UB.com Thu Dec 9 12:02:23 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09513; Thu, 9 Dec 93 12:02:23 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA11235; Thu, 9 Dec 93 11:54:34 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA10728; Thu, 9 Dec 93 11:24:50 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA03967; Thu, 9 Dec 93 11:24:50 PST Date: Thu, 9 Dec 93 11:24:50 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312091924.AA03967@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: Bird #5 Based on our experience on developing the DIE spec and talking to many IC vendors, I might caution us on the wording used to describe the power / ground bus mechanism. The end users of bare die take this information as a license to partially connect the power and ground pads. Also, in many cases, we found that the busses were actually fully interconnected internally. The specification of which drivers are connected to which power / ground pads is merely provided as a "nearest neighbor" relation. This relation gives an indication of which drivers when taken together could induce problems. Multiple busses may exist locally to create an interspersed connection to expected simultaneous switching drivers, but they end up being shorted at some point internally. At least this is what our IC research uncovered. Any comments from IC vendors? Randolph E. Harr, Logic Modeling Corp., randyh@lmc.com From cer@Cadence.COM Thu Dec 9 13:11:48 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10035; Thu, 9 Dec 93 13:11:48 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id NAA26298 for ; Thu, 9 Dec 1993 13:03:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma026285; Thu Dec 9 13:02:33 1993 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA05651; Thu, 9 Dec 93 13:04:17 -0800 Received: by oahu (5.65+/1.5) id AA02576; Thu, 9 Dec 93 16:09:00 -0500 Date: Thu, 9 Dec 93 16:09:00 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312092109.AA02576@oahu> To: ibis@vhdl.org Subject: Re: Bird #5 Howdy, As far as I'm concerned there is no reason to confine a line to 80 characters. That's an ancient restriction born of punched-cards that I think we can safely ignore. Chris From lmsi!milpitas.lmc.com!randyh@UB.com Thu Dec 9 15:15:37 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10776; Thu, 9 Dec 93 15:15:37 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA19496; Thu, 9 Dec 93 15:04:54 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA11613; Thu, 9 Dec 93 15:00:42 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA04075; Thu, 9 Dec 93 15:00:42 PST Date: Thu, 9 Dec 93 15:00:42 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312092300.AA04075@fiji.lmsi.com> To: ibis@vhdl.org, cer@cadence.com Subject: Re: Bird #5 Should we be so quick to dismiss 80 column limitations or encouraged styles. Most "default" window sizes still come up as 80 characters; most screen fonts are still mono-spaced and support this paradigm. Printing of unformatted text files always still defaults to 10 pt mono-spaced fonts (even on many postscript systems) and only allow 72-80 characters across per page. Although the source of the size (80 characters) actually pre-dates even punched cards, it is still prevalent IF you desire human-readable and easily processable "documentation". The real question seems to be whether we desire human readable files. We can change it to a style issue only if we remove the "newline" (carriage return or whatever; depending on the file system) as an active part of the syntax. randy > From Cadence.COM!cer@lmc.com Thu Dec 9 13:14:27 1993 > To: ibis@vhdl.org > Subject: Re: Bird #5 > > Howdy, > > As far as I'm concerned there is no reason to confine a line > to 80 characters. That's an ancient restriction born of > punched-cards that I think we can safely ignore. > > Chris > > From bward@dadhb1.ti.com Thu Dec 9 15:31:30 1993 Return-Path: Received: from ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10922; Thu, 9 Dec 93 15:31:30 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA10772; Thu, 9 Dec 1993 17:30:56 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA09659; Thu, 9 Dec 1993 17:27:19 -0600 Message-Id: <199312092327.AA09659@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA26829; Thu, 9 Dec 1993 17:23:57 -0600 Date: Thu, 9 Dec 1993 17:23:57 -0600 From: Bob Ward To: ibis@vhdl.org Subject: BIRD #5 Hi ibis'ians! I was just reading Randy's note about BIRD #5, and it sparks the following comments. First, I agree fully with Randy's observation that the bussing structures are generally more complicated that what BIRD #5 allows for. In fact the power and ground tree structures I was harrangueing about earlier are prime examples of this carried to something of an extreme. Now in the last forum we discussed this at some length, and concluded, I think :^), as follows. BIRD #5 should be slightly amended as we discussed it and then basically accepted pending any further comment. I would make a try at BIRD #6 to try to improve on BIRD #5. I saw BIRD #5 as a good evolutionary improvement over the original and so spoke for its acceptance, and I hope BIRD #6 will be another evolutionary improvement over it. I think that the original spec is adequate for the "elderly" parts we talked about at the summit. I think that BIRD #5 gets us quite a ways toward modelling todays parts, possibly about as well as can be by basing the model on external measurements. I hope that BIRD #6 will take that to the point where one needs the vendors circuitry insights to do full justice to it. If that is the case it seems to fit together with the notion of levels of compliance present ( I think ) in the die work, and I would like to see in the ibis spec. I am remembering that we "kinda" agreed to levels in the last forum, but someone quick correct me if I am remembering what I want to instead of reality :-) ( I am good at doing that! ). I will base BIRD #6 on that memory, if no one points up that I am wrongly remembering. As we discussed, the topology of these busses can get pretty involved. Arpad ( I think it was he ) came up with the idea of a tree fanning out roots on one side and branches on the other and we start it in the middle, at the trunk, instead of at the root as in graph theory. That will be the central theme of the BIRD when I write it ( which was to be Real Soon Now (tm), but I am starting to think it should be sooner ). This, too is an approximation, but if we are going to go with anything less than a full Spice deck, or RLGC matrix at the same level of detail, we simply will have an approximation. Also if the ground rule is that we should be able to determine the parameters from measurements we simply will have an approximation. More discussion is certainly welcome and invited! I am starting to formulate my thoughts for the next BIRD and so this is a good time to get any more comments than we got in the forum. I won't wait too long, though, because the structure of the BIRD will probably spark some more comment in its own right. Thanks, ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From ccm!Will_Hobbs@intelhf.intel.com Thu Dec 9 16:30:15 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12066; Thu, 9 Dec 93 16:30:15 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p7vjA-000MNyC; Thu, 9 Dec 93 16:29 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p7voL-0000IwC; Thu, 9 Dec 93 16:34 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 9 Dec 93 16:34:20 PST Date: Thu, 9 Dec 93 16:34:20 PST From: Will Hobbs Message-Id: <931209163420_8@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, ibis@vhdl.org Subject: Re[2]: Bird #5 Text item: Text_1 A couple comments on BIRD 5: 1) These new columns MUST be optional. I could not find the word "optional" anywhwere in the text. Will replies: Agreed. The earlier version of this did say it was optional and it escaped my attention on this version. 2) It's presently marked "accepted" on Dec. 7, one day after it was submitted. I assume this is an error. Will: I misinterpreted this line. By accepted, I meant that it now has an official number and is ready for comment. Ignore the "accepted" line. 3) The team had worked to make sure a line of information does not exceed 80 characters. How does it fold in if R_pin (etc) is still used. There are currently rules on using 3 or 6 columns. What are the new rules? Is 80 characters no longer a concern? This BIRD needs to show what EXACTLY is the new text proposed for IBIS. Don Telian From ccm!Will_Hobbs@intelhf.intel.com Thu Dec 9 16:38:01 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12098; Thu, 9 Dec 93 16:38:01 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p7vqg-000MNuC; Thu, 9 Dec 93 16:36 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p7vvr-00004uC; Thu, 9 Dec 93 16:42 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 9 Dec 93 16:42:07 PST Date: Thu, 9 Dec 93 16:42:07 PST From: Will Hobbs Message-Id: <931209164207_3@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, lmsi!milpitas.lmc.com!randyh@UB.com, ibis@vhdl.org, cer@cadence.com Subject: Re[2]: Bird #5 Due to the amount of e-mail traffic that everyone engages in, along with printer defaults that truncate longer lines, I think the 80 column limitiation is very much alive. I vote for human-readability and a continuation of 80 column restriction. Will Should we be so quick to dismiss 80 column limitations or encouraged styles. Most "default" window sizes still come up as 80 characters; most screen fonts are still mono-spaced and support this paradigm. Printing of unformatted text files always still defaults to 10 pt mono-spaced fonts (even on many postscript systems) and only allow 72-80 characters across per page. Although the source of the size (80 characters) actually pre-dates even punched cards, it is still prevalent IF you desire human-readable and easily processable "documentation". The real question seems to be whether we desire human readable files. We can change it to a style issue only if we remove the "newline" (carriage return or whatever; depending on the file system) as an active part of the syntax. randy > From Cadence.COM!cer@lmc.com Thu Dec 9 13:14:27 1993 > To: ibis@vhdl.org > Subject: Re: Bird #5 > > Howdy, > > As far as I'm concerned there is no reason to confine a line > to 80 characters. That's an ancient restriction born of > punched-cards that I think we can safely ignore. > > Chris > > From ccm!Will_Hobbs@intelhf.intel.com Thu Dec 9 17:29:42 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12554; Thu, 9 Dec 93 17:29:42 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p7we2-000MNkC; Thu, 9 Dec 93 17:27 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p7wjD-0000BsC; Thu, 9 Dec 93 17:33 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 9 Dec 93 17:33:06 PST Date: Thu, 9 Dec 93 17:33:06 PST From: Will Hobbs Message-Id: <931209173306_3@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, bward@dadhb1.ti.com, ibis@vhdl.org Subject: Re: AC IV Curves I believe that was Jon Powell of Quad. Jon? Will All- At the recent summit in Santa Clara, someone observed that measuring IV data into a variety of terminating impedances allowed for the construction of so- called AC IV curves. Now I think I know what is being referred to here, but I would like to be sure I am thinking the same thing as was alluded to. So since I cannot remember who said it, would whoever that was that mentioned it please elaborate on it a little? You can reply either in personal e-mail or on the reflector as you see fit, but please do reply. I am trying to gather some ammunition for making the argument that ibis CAN capture AC phenomena in spite of what certein detractors here within think. Thanks in advance! ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From bracken@valhalla.performance.com Thu Dec 9 20:40:23 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13786; Thu, 9 Dec 93 20:40:23 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA14685; Thu, 9 Dec 93 23:40:28 EST Message-Id: <9312100440.AA14685@valhalla.performance.com> To: ibis@vhdl.org Subject: 80 Columns Date: Thu, 09 Dec 93 23:40:25 -0500 From: bracken@valhalla.performance.com Y'all, Being mostly human, I am 100% totally for human readable files. Is it time to contemplate an "extension" character (a la the famed "+" in Spice) that can be used to break long lines up across several "physical" lines of the input file without violating the sacred and venerable limit of 80 characters? Say we had: A very long line of input such as this very very very long one and I'm talking really REALLY long. This would become: A very long line of input such as this very very very long one and I'm + talking really REALLY long. I think we need something like this, otherwise the 80 char limit becomes crippling to our expressiveness. --Eric Bracken P.S. I suggest that we also put a filter on the reflector, to squelch any messages that have lines exceeding 80 characters in width. This will prevent the pain and suffering I experience when I need to resize my X window. From speters@ichips.intel.com Fri Dec 10 08:38:27 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21449; Fri, 10 Dec 93 08:38:27 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 10 Dec 93 08:37:16 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 10 Dec 93 08:37:07 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 10 Dec 93 08:37:10 PST Message-Id: <9312101637.AA08326@xtg801.intel.com> To: ibis@vhdl.org Subject: 80 column line extension Date: Fri, 10 Dec 1993 08:37:08 -0800 From: Stephen Peters Hello IBIS folks -- Eric Bracken writes: >Is it time to contemplate an "extension" character (a la the famed "+" >in Spice) that can be used to break long lines up across several >"physical" lines of the input file without violating the sacred and >venerable limit of 80 characters? Well, we could, but in the case were talking about the information is suposed to be formated in specific columns with column headers. It doesn't do much for human readability (or understanding) to have something like: COLUMN 1 COLUMN2 COLUMN 3 + --------- ------- -------- COLUMN4 COLUMN5 ------- ------- DATA DATA DATA + DATA DATA DATA DATA DATA + DATA DATA It seems to me that the problem is with trying to DISPLAY the essential pwr/gnd mapping information. Perhaps there is a better way to format this information? Maybe another keyword? I don't know, im just offering food for thought. Best Regards, Stephen Peters Intel Corp. From cer@Cadence.COM Fri Dec 10 08:53:39 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21542; Fri, 10 Dec 93 08:53:39 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id IAA04937 for ; Fri, 10 Dec 1993 08:45:04 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma004887; Fri Dec 10 08:44:23 1993 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA26610; Fri, 10 Dec 93 08:46:01 -0800 Received: by oahu (5.65+/1.5) id AA03114; Fri, 10 Dec 93 11:50:55 -0500 Date: Fri, 10 Dec 93 11:50:55 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312101650.AA03114@oahu> To: Ibis@vhdl.org Subject: Re: 80 column line extension Steve, Good point on the continuation character. Column formatted data is not very readable when broken across multiple lines. Still, readability is important, but not at the expense of functionality. Perhaps we can keep the limit to 132 characters? If we cannot fit the data in 80 characters then I suggest the line-length limit is the requirement that should be eliminated. Besides, the continuation character significantly complicates parsing. Chris Reid From cer@Cadence.COM Fri Dec 10 09:03:38 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21609; Fri, 10 Dec 93 09:03:38 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id IAA05265 for ; Fri, 10 Dec 1993 08:55:04 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma005215; Fri Dec 10 08:54:57 1993 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA27308; Fri, 10 Dec 93 08:56:35 -0800 Received: by oahu (5.65+/1.5) id AA03123; Fri, 10 Dec 93 12:01:30 -0500 Date: Fri, 10 Dec 93 12:01:30 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312101701.AA03123@oahu> To: ibis@vhdl.org Subject: YACC & Ibis Hello, Has anyone written a YACC grammar for Ibis? Chris Reid cer@cadence.com From bracken@valhalla.performance.com Fri Dec 10 09:08:51 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21623; Fri, 10 Dec 93 09:08:51 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA15002; Fri, 10 Dec 93 12:08:58 EST Message-Id: <9312101708.AA15002@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: Bird #5, 80 columns In-Reply-To: Your message of "Fri, 10 Dec 93 08:37:08 PST." <9312101637.AA08326@xtg801.intel.com> Date: Fri, 10 Dec 93 12:08:55 -0500 From: bracken@valhalla.performance.com Well, we could add a new section to the file, [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ... 11 GNDBUS1 NA 12 GNDBUS1 NA 13 GNDBUS1 NA ... 31 NA PWRBUS1 32 NA PWRBUS1 33 NA PWRBUS1 This would come after the [Pin] section, and would be TOTALLY OPTIONAL and NOT REQUIRED. Furthermore, it leaves probably 30 characters or so for upward expansion while still observing the 80 character limit that everyone seems to feel is so essential to preserving Western civilization as we know it; and it does not add horrendous complexity to the parser. Comments? --Eric From cer@Cadence.COM Fri Dec 10 09:17:38 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21687; Fri, 10 Dec 93 09:17:38 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id JAA05749 for ; Fri, 10 Dec 1993 09:09:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma005723; Fri Dec 10 09:08:09 1993 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA28231; Fri, 10 Dec 93 09:09:47 -0800 Received: by oahu (5.65+/1.5) id AA03138; Fri, 10 Dec 93 12:14:41 -0500 Date: Fri, 10 Dec 93 12:14:41 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312101714.AA03138@oahu> To: ibis@vhdl.org Subject: Re: Bird #5, 80 columns Eric, Your suggested addtion of a section: ----------------------------------------------------- Well, we could add a new section to the file, [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ... 11 GNDBUS1 NA 12 GNDBUS1 NA 13 GNDBUS1 NA ... 31 NA PWRBUS1 32 NA PWRBUS1 33 NA PWRBUS1 This would come after the [Pin] section, and would be TOTALLY OPTIONAL and NOT REQUIRED. --------------------------------------------------------------- does maintain the 80-character limit without complicating the parser, but it also requires a duplication of the pin-map, which is also undesirable. Chris From lmsi!milpitas.lmc.com!randyh@UB.com Fri Dec 10 11:30:27 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22459; Fri, 10 Dec 93 11:30:27 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA07001; Fri, 10 Dec 93 11:18:39 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA14288; Fri, 10 Dec 93 11:14:16 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA04321; Fri, 10 Dec 93 11:14:15 PST Date: Fri, 10 Dec 93 11:14:15 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312101914.AA04321@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: 80 Columns ----- Begin Included Message ----- From valhalla.performance.com!bracken@lmc.com Thu Dec 9 20:55:38 1993 To: ibis@vhdl.org Subject: 80 Columns A very long line of input such as this very very very long one and I'm + talking really REALLY long. ----- End Included Message ----- In scenarios like this, experience in language design tells me it is better to a) consider all "newlines" (or applicable record terminator / separator) the same as spaces (for that matter, any white space such as tabs, etc. should be considered a space for parsing purposes also) and b) introduce a separator (or terminator) character such as a comma (','), semicolon (';'), or whatever. (Note: for you language purists, the only difference between a separator and terminator is after the last occurrence of a list of objects. A terminator is placed at the end of the list whereas a separator is not!) It does not add that much extra to the syntax but separates the "pretty layout" (human readable) issue from the computer sensible / parseable one. We would then remove the 80 column limitation and suggest / require its use for style reasons only. randy From lmsi!milpitas.lmc.com!randyh@UB.com Fri Dec 10 12:19:38 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22791; Fri, 10 Dec 93 12:19:38 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA09070; Fri, 10 Dec 93 12:11:57 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA14406; Fri, 10 Dec 93 11:58:02 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA04381; Fri, 10 Dec 93 11:58:02 PST Date: Fri, 10 Dec 93 11:58:02 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312101958.AA04381@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: YACC & Ibis Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 20 > From Cadence.COM!cer@lmc.com Fri Dec 10 09:22:52 1993 > To: ibis@vhdl.org > Subject: YACC & Ibis > > Hello, > > Has anyone written a YACC grammar for Ibis? > > Chris Reid > cer@cadence.com > We tried but, as I presume you are implying, it could not be accurate for several reasons. See the file /pub/die/wrkshop2/electric.{mif or ps} on vhdl.org; appendix A, page 11-12. The grammer only is attached below for convenience. randy ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: electric.txt X-Sun-Content-Lines: 115 Appendix A Notation -------- Terminals of the grammar are enclosed by apostrophes. They are the actual keyword used in the DIE file format. Keywords are not case sensitive and are put in upper case in this definition only. The vertical bar "|" separate alternatives. For example, A | B | C, represents exactly one occurrence of A or B or C. Braces "{}" indicate zero or more occurrences of the enclosed syntactic construct. For example, { A } represents the empty sequence, as well as A , and A A, A A A, and so on. The terminals of DIE file format are keyWord token and item token. They are defined as entries in the semantic definition for each section. Definition ---------- $goal ::= ibisFileFormat ibisFileFormat ::= fileHeaderSection sections `[` `END' `]' fileHeaderSection ::= ibisVersion { fileHeaderItems } fileHeaderItems ::= commentChar | fileName | fileVersion | date | source | notes | disclaimer ibisVersion ::= `[` `IBIS Ver' `]' string commentChar ::= `[` `comment char' `]' commentString commentString ::= character `_char' fileName ::= `[` `File name' `]' fileNameString fileNameString ::= string `.ibs' fileVersion ::= `[` `File Rev' `]' string date ::= `[` `date' `]' text source ::= `[` `source' `]' text notes ::= `[` `notes' `]' text disclaimer ::= `[` `disclaimer' `]' sections ::= section { section } section ::= componentDefinitionSection | modelDefinitionSection componentDefinitionSection ::= component component_items component_items ::= manufacturer | package | pin manufacturer ::= `[` `manufacturer' `]' text package ::= `[` `package' `]' package_RLC package_RLC ::= [ `R_pkg' | `L_pkg' | `C_pkg' ] typ_min_max typ_min_max ::= real real_na real_na real_na ::= [ real | `NA' ] pin ::= `[` `pin' `]' { pin_entry } pin_entry ::= integer string [model_identifier | `power' | `gnd' | `NC'] real_na real_na real_na modelDefinitionSection ::= `[` `model' `]' modelEntry modelEntry ::= [ modelType | polarity | enable | vinl | vinh | c_comp | voltage_range | pulldown | pullup | gndClamp | powerClamp | ramp ] modelType :: = `[` `model_type' `]' [ `input' | `output' | `i/o' | `3- state' | `open_drain' ] polarity ::= `[` `polarity' `]' [ `non-inverting' | `inverting' ] enable ::= `[` `enable' `]' [ `active-high' | `active-low' ] vinl ::= `vinl' `=' voltage_spec vinh ::= `vinh' `=' voltage_spec voltage_spec ::= real [ `v' ] c_comp ::= `c_comp' typ_min_max voltage_range ::= `[` `voltage range' `]' typ_min_max pulldown ::= `[` `pulldown' `]' viDefinitions pullup ::= `[` `pullup' `]' viDefinitions gndClamp ::= `[` `gnd_clamp' `]' viDefinitions powerClamp ::= `[` `power_clamp' `]' viDefinitions viDefinition ::= { real typ_min_max } ramp ::= `[` `ramp' `]' { dvdtR | dvdtF } dvdtR ::= `dV/dt_r' typ_min_max_rate dvdtF ::= `dV/dt_r' typ_min_max_rate typ_min_max ::= rate [ rate | `NA' ] [ rate | `NA' ] rate ::= real `/' real From ccm!Will_Hobbs@intelhf.intel.com Fri Dec 10 12:22:26 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22824; Fri, 10 Dec 93 12:22:26 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p8EKg-000MOTC; Fri, 10 Dec 93 12:20 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p8EPx-0000IwC; Fri, 10 Dec 93 12:26 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 10 Dec 93 12:26:24 PST Date: Fri, 10 Dec 93 12:26:24 PST From: Will Hobbs Message-Id: <931210122624_9@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, cer@Cadence.COM, ibis@vhdl.org Subject: Re[2]: Bird #5, 80 columns As I stated before, I feel human readability is important for several reasons. One thing I didn't mention is how easy it is for a mistake to go unnoticed if it's off beyond the right side of the screen. At first blush, I like Chris's suggestion. The files are already fairly long so a little longer won't be too bad, ASCII text is cheap, and this proposal maintains readability. Will Eric, Your suggested addtion of a section: ----------------------------------------------------- Well, we could add a new section to the file, [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ... 11 GNDBUS1 NA 12 GNDBUS1 NA 13 GNDBUS1 NA ... 31 NA PWRBUS1 32 NA PWRBUS1 33 NA PWRBUS1 This would come after the [Pin] section, and would be TOTALLY OPTIONAL and NOT REQUIRED. --------------------------------------------------------------- does maintain the 80-character limit without complicating the parser, but it also requires a duplication of the pin-map, which is also undesirable. Chris From ccm!Arpad_Muranyi@intelhf.intel.com Mon Dec 13 20:02:09 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26924; Mon, 13 Dec 93 20:02:09 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p9QwR-000MNiC; Mon, 13 Dec 93 20:00 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p9R25-0001T2C; Mon, 13 Dec 93 20:06 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 13 Dec 93 20:06:44 PST Date: Mon, 13 Dec 93 20:06:44 PST From: Arpad Muranyi Message-Id: <931213200644_9@ccm.hf.intel.com> To: ibis@vhdl.org Subject: 80-columns and EMAIL One more comment on the 80-column issue. The IBIS files should not only be human readable but easy to transfer via EMAIL. We need to consider that some EMAIL softwares automatically wrap long lines and not only wrap but add an extra symbol to the beginning of the wrapped line to indicate that it was wrapped. Now, imagine you get an ibis file that is several thousand lines long, full with such automatically added trash in it. Are you going to edit it manually, or write a program to put it back to it's original format? CCMAIL does this, and there were times when I could not use electronically received SPICE model files for this reason. Arpad From cer@Cadence.COM Tue Dec 14 05:45:58 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03362; Tue, 14 Dec 93 05:45:58 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id FAA11121 for ; Tue, 14 Dec 1993 05:37:03 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma011106; Tue Dec 14 05:36:51 1993 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA25528; Tue, 14 Dec 93 05:38:10 -0800 Received: by oahu (5.65+/1.5) id AA06024; Tue, 14 Dec 93 08:43:41 -0500 Date: Tue, 14 Dec 93 08:43:41 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312141343.AA06024@oahu> To: ibis@vhdl.org Subject: Re: 80-columns and EMAIL Arpad writes: > One more comment on the 80-column issue. The IBIS files should not only be > human readable but easy to transfer via EMAIL. > We need to consider that some EMAIL softwares automatically wrap long lines and > not only wrap but add an extra symbol to the beginning of the wrapped line to > indicate that it was wrapped. Now, imagine you get an ibis file that is several > thousand lines long, full with such automatically added trash in it. > Are you going to edit it manually, or write a program to put it back to it's > original format? > CCMAIL does this, and there were times when I could not use electronically > received SPICE model files for this reason. If we had to constrain our design to something that every existing system was capable of handling without any problems we would be sorely constrained. I sugest that any mail system with such properties should be trashed. As a work-around for those forced to use such things uuencode should solve the problem. Chris From ccm!Will_Hobbs@intelhf.intel.com Tue Dec 14 09:34:21 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05401; Tue, 14 Dec 93 09:34:21 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p9dcW-000MNbC; Tue, 14 Dec 93 09:33 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p9diI-0000GHC; Tue, 14 Dec 93 09:39 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 14 Dec 93 09:39:10 PST Date: Tue, 14 Dec 93 09:39:10 PST From: Will Hobbs Message-Id: <931214093910_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Bird #5 Fellow IBISers, After discussion on the reflector, Eric has revised BIRD 5 and has re-submitted it. I have re-numbered it BIRD 5.1 to differentiate it from the earlier version. Below are his comments and the BIRD itself. Regards, Will Hobbs Will, In hopes of getting the discussion "back on track", I'd like to submit the following revised Bird #5 which eliminates the need for any additional columns in the [Pin] section and which carefully observes the 80 character-per-line limit. I suggested this to the forum a few days ago and haven't heard much opposition... Perhaps there should be a new special-interest group for 80-column issues? :-) --Eric Bracken ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 5.1 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: 6 December 1993 DATE REVISED: 14 December 1993 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. The [Pin_Mapping] keyword must occur after the [Pin] declaration section for the component model when it is used. When [Pin_Mapping] is used, each power and ground bus is given a unique name which must not exceed 20 characters. Following the [Pin_Mapping] keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 .... ... ... 11 GNDBUS1 NA 12 GNDBUS1 NA 13 GNDBUS1 NA .... 21 GNDBUS2 NA 22 GNDBUS2 NA 23 GNDBUS2 NA .... 31 NA PWRBUS1 32 NA PWRBUS1 33 NA PWRBUS1 .... 41 NA PWRBUS2 42 NA PWRBUS2 43 NA PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd" column indicates the ground bus to which it is attached. The entry in the "pwr" column is NA because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pwr" and "gnd" entries for it may be NA. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation, while still observing an 80-character-per-line limit in the IBIS file. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. ******************************************************************************* From ccm!Arpad_Muranyi@intelhf.intel.com Tue Dec 14 09:43:22 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05489; Tue, 14 Dec 93 09:43:22 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p9dlG-000MNXC; Tue, 14 Dec 93 09:42 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p9dr2-0000L7C; Tue, 14 Dec 93 09:48 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 14 Dec 93 09:48:11 PST Date: Tue, 14 Dec 93 09:48:11 PST From: Arpad Muranyi Message-Id: <931214094811_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re[2]: 80-columns and EMAIL Chris, I agree with you, but since I do not make company wide desisions which EMAIL software to use, I have to put up with what I get. Also, does uuencode exist on the PC? I have not heared about one yet. As it is, I find myself showing files back and forth between my UNIX and PC accounts, and because many times I forget about binary or ASCII mode, I have to retry several times... How is that for wasting time? As far as the restrictions are concerned, I thought the purpose of IBIS was to make models easy to get or distribute. I am not in for more restrictions (that is why I live in the US), but I think this might be something to keep in mind. On the other hand, if we are migrating in the non-readble direction, we might even consider binary files. They would be much more compact. And noone could read them, except machines... Arpad Arpad writes: > One more comment on the 80-column issue. The IBIS files should not -only be > human readable but easy to transfer via EMAIL. > We need to consider that some EMAIL softwares automatically wrap long -lines and > not only wrap but add an extra symbol to the beginning of the wrapped -line to > indicate that it was wrapped. Now, imagine you get an ibis file that -is several > thousand lines long, full with such automatically added trash in it. > Are you going to edit it manually, or write a program to put it back -to it's > original format? > CCMAIL does this, and there were times when I could not use electronically > received SPICE model files for this reason. If we had to constrain our design to something that every existing system was capable of handling without any problems we would be sorely constrained. I sugest that any mail system with such properties should be trashed. As a work-around for those forced to use such things uuencode should solve the problem. Chris From lmsi!milpitas.lmc.com!randyh@UB.com Tue Dec 14 17:45:24 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08811; Tue, 14 Dec 93 17:45:24 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA18598; Tue, 14 Dec 93 17:34:17 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA09831; Tue, 14 Dec 93 17:00:34 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA05492; Tue, 14 Dec 93 17:00:33 PST Date: Tue, 14 Dec 93 17:00:33 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312150100.AA05492@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: Re[2]: 80-columns and EMAIL uuencode and many other UNIX style utilities exist for the PC and MAC in public domain form. See pub/tools/dos, pub/tools/macintosh, and pub/tools/ms-windows on the vhdl.org server for more details. randy harr randyh@lmc.com From qdt!sal!jonp@uunet.UU.NET Wed Dec 15 08:14:16 1993 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16345; Wed, 15 Dec 93 08:14:16 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22941; Wed, 15 Dec 93 11:13:03 -0500 Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 111207.5177; Wed, 15 Dec 1993 11:12:07 EST Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00475; Wed, 15 Dec 93 08:00:03 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA29729; Wed, 15 Dec 93 08:00:01 PST Date: Wed, 15 Dec 93 08:00:01 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9312151600.AA29729@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA04523; Wed, 15 Dec 93 08:00:02 PST To: ibis@vhdl.org Subject: Previous Mail Hello, I am not dead. I have had a email problem over the last few weeks and have just gotten deluged with good ideas. I will try to respond soon as appropriate. One Note: Quad would be happy to share our views/technology about converson of SPICE/MEASUREMENT to IBIS data. There isn't very much to it, really. The main thing is turning zillions of data points into the pertenaint ones using some simple linearization. chow jon From ccm!Will_Hobbs@intelhf.intel.com Wed Dec 15 10:04:14 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17292; Wed, 15 Dec 93 10:04:14 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pA0Yt-000MNzC; Wed, 15 Dec 93 10:02 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pA0en-0001OaC; Wed, 15 Dec 93 10:09 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 15 Dec 93 10:09:04 PST Date: Wed, 15 Dec 93 10:09:04 PST From: Will Hobbs Message-Id: <931215100904_2@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, qdt!sal!jonp@uunet.UU.NET, ibis@vhdl.org Subject: Re: Previous Mail Howdy, all, Re: Spice to IBIS Keep in mind that it can't be fully automated-- some human intelligence has to be applied to where the significant circuitry of the buffer ends, and which nodes to tie high or low to achieve the state you want to measure. Will Hello, I am not dead. I have had a email problem over the last few weeks and have just gotten deluged with good ideas. I will try to respond soon as appropriate. One Note: Quad would be happy to share our views/technology about converson of SPICE/MEASUREMENT to IBIS data. There isn't very much to it, really. The main thing is turning zillions of data points into the pertenaint ones using some simple linearization. chow jon From bward@dadhb1.ti.com Wed Dec 15 13:53:45 1993 Return-Path: Received: from lobby.ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18678; Wed, 15 Dec 93 13:53:45 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by lobby.ti.com with SMTP (5.65c/LAI-3.2) id AA26384; Wed, 15 Dec 1993 15:52:46 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA26865; Wed, 15 Dec 1993 15:47:46 -0600 Message-Id: <199312152147.AA26865@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA10027; Wed, 15 Dec 1993 15:44:42 -0600 Date: Wed, 15 Dec 1993 15:44:42 -0600 From: Bob Ward To: ibis@vhdl.org Subject: BIRD 5.1 I have been looking at BIRD 5.1 and have a few comments, mostly minor. I am thinking that the use of NA for the state of not being connected to a power or ground bus would be better cast as NC. The present day buzzword for the use of NA is "overloading" where in one context it means Not Available and in another it mean Not Connected. I would think that the semantic change is less if we use NC with all the same rules as for NA. Just one of those little consistencies that make writing parsers more tolerable. For effective power and ground bounce work one really should not ignore mutual couplings. These can be really significant in some cases. Now the statement that this BIRD allows for first order analysis ( I would add 'at least' since it could go a long way toward second order as well ) probably says that we do not need mutuals yet. I am at a loss just now as to whether these should be saved for a later BIRD or whether we should try to factor them in here. Doing so would affect quite a few things. Advice or comments? Thanks, ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From bracken@valhalla.performance.com Wed Dec 15 14:35:55 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18942; Wed, 15 Dec 93 14:35:55 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA20162; Wed, 15 Dec 93 17:36:00 EST Message-Id: <9312152236.AA20162@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: Bob Ward's mail on BIRD 5.1 In-Reply-To: Your message of "Wed, 15 Dec 93 15:44:42 CST." <199312152147.AA26865@tilde.csc.ti.com> Date: Wed, 15 Dec 93 17:35:58 -0500 From: bracken@valhalla.performance.com An open letter: Bob, Now that you mention it, I think "NC" is better, too. It will avoid confusion about what has to be specified. (I'd hate for someone to think that the pin mapping was simply unavailable...) Look for BIRD 5.2 with this amendment shortly. With regard to mutuals: I think that the issue is orthogonal to that of the pin mapping. That is, if the pins have mutual couplings to one another, they can be specified independently of the pin mappings, as long as we exclude from consideration the very general network topologies (like the one you described in that famous mail message of a week or two ago.) The [Pin_Mapping] isn't meant to handle those problems anyway, at least not in a rigorous fashion. If we come up with a spec for describing the pin-to-pin mutual couplings (I'd still like to do this), then it's straightforward to extend the concept of "parallel combination" to determine the impedances seen looking out into the board from the devices connected to the bus. In fact, now that we're talking about it, here's an EGG (even earlier than a BIRD) on how to do mutuals: [Mutuals] Pin1 Pin2 Rmut Lmut Cmut 1 2 1e-3 1n 1p 1 3 1e-4 0.1n 0.1p Columns "Pin1" and "Pin2" contain numbers of pins which are coupled together; the Rmut, etc. columns specify the values of the couplings. Not every coupling must be specified (in the interest of sparsity); you can assume that the self-inductances have been specified in the [Pin] section (talk about backward compatibility!) And it all fits into 80 characters. The only thing I'm not sure about here is where the C is; is it on the "outside" node (close to the board) or the inside node (near the die)? Kumar, or Chris, do you have an opinion on where C should be? --Eric Bracken From cer@Cadence.COM Thu Dec 16 06:02:54 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27765; Thu, 16 Dec 93 06:02:54 PST Received: from cadence.Cadence.COM (cadence.cadence.com [158.140.18.1]) by mailgate.cadence.com (8.6.4/8.6.4) with SMTP id FAA20688 for ; Thu, 16 Dec 1993 05:53:42 -0800 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA05236; Thu, 16 Dec 93 05:54:50 -0800 Received: by oahu (5.65+/1.5) id AA06871; Thu, 16 Dec 93 09:00:40 -0500 Date: Thu, 16 Dec 93 09:00:40 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312161400.AA06871@oahu> To: ibis@vhdl.org Subject: EGG1.0 : Mutual pin parasitics Hello, Eric's mail on mutual pin parasitics asked where the capacitance should be, on the inside or outside of a pin. Actually it does not make much difference. Either way the circuit has the same transfer function. As for representing mutuals, we are using banded-symmetric RLC matricies. That is the form most 3-D field solvers deliver the result, and it is an easy format to deal with in software. Eric's suggested format is up to the task, but it is somewhat more verbose than required, and requires more processing by the software. We added a key-word to the IBIS spec, [PackageModel], which specifies a package-model (RLC matrix) to use by name instead of putting the data directly in the pin-map. This was done because many devices may share the same package. In otherwords, a TI_DIP16_PLASTIC package may be used for many different IC's, but the package-model is entered in our library only once. If the [PackageModel] is specified for some device, the RLC parasitics in the pin-map are ignored in favor of the diagonal entries in the package-model matrix. I will write a BIRD for this one. The pertinent section of Eric's mail: ------------------------------------------------------------------------- In fact, now that we're talking about it, here's an EGG (even earlier than a BIRD) on how to do mutuals: [Mutuals] Pin1 Pin2 Rmut Lmut Cmut 1 2 1e-3 1n 1p 1 3 1e-4 0.1n 0.1p Columns "Pin1" and "Pin2" contain numbers of pins which are coupled together; the Rmut, etc. columns specify the values of the couplings. Not every coupling must be specified (in the interest of sparsity); you can assume that the self-inductances have been specified in the [Pin] section (talk about backward compatibility!) And it all fits into 80 characters. The only thing I'm not sure about here is where the C is; is it on the "outside" node (close to the board) or the inside node (near the die)? Kumar, or Chris, do you have an opinion on where C should be? ----------------------------------------------------------------------- From bward@dadhb1.ti.com Thu Dec 16 06:56:29 1993 Return-Path: Received: from ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28027; Thu, 16 Dec 93 06:56:29 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA25878; Thu, 16 Dec 1993 08:56:24 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA04300; Thu, 16 Dec 1993 08:52:58 -0600 Message-Id: <199312161452.AA04300@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA15778; Thu, 16 Dec 1993 08:48:38 -0600 Date: Thu, 16 Dec 1993 08:48:38 -0600 From: Bob Ward To: ibis@vhdl.org Subject: Yet Another Comment ( Sorry, I can't get another "C" in here ) All - I actually agree that the question of mutuals is othogonal to the pin mapping that this BIRD deals with. It occurred to me at the time of writing so I mentioned it. I have no problem at all with saving it for another BIRD, and had thought about adding it to one I am trying to work out to generalize the mapping for more complex cases such as I presented earlier. Still the suggested EGG ( I like that ! ) has a lot of merit. I also like the idea of the separate [PackageModel] keyword. It occurs to me that some kind of file include mechanism, such as the (in)famous #include in C or ~r in many e-mail programs which takes a path name as argument and merges the contents of it in line in the text would be useful in this context. It should fit into the established keyword syntax, however, such as maybe [Include], [Library], [Merge], or [Read] or some such variation. Path names can easily exceed the 80 character limit, though, and I do support that limit as a matter of practical convenience, even though not dogmatically. Thus we may have some extra baggage here such as a [path] keyword, use of the path environment variable on UNIX(tm) and DOS systems, or even add an environment variable such as ibispath. I am still thinking about how to best represent mutuals. Much can be said for the matrix approach, as well as the text based approach in the EGG, and I have yet to convince myself of a compelling reason to come down on one side or the other. One caveat though: beware of arbitrarily deciding that some mutuals can be eliminated due to their small magnitude. Jacob White of the Research Laboratory of Electronics at MIT has some interesting examples of packaging where, due to the nature of the internal circuitry, a number of "far away", and thus small magnitude, mutuals "ganged up" on another signal pin and ruined the waveform there during certain transitions. So there needs to be a basis for discard of mutuals, probably based on knowledge of some constraints on simultaneous switching patterns. Anyway this sounds like just the level of discussion I had wanted to start about mutuals, etc. Sounds like a number of good ideas coming forth, and that is the stuff that will move ibis forward. Thanks, ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From lmsi!milpitas.lmc.com!randyh@UB.com Thu Dec 16 10:02:07 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29357; Thu, 16 Dec 93 10:02:07 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA02026; Thu, 16 Dec 93 09:57:03 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA15582; Thu, 16 Dec 93 09:52:20 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA06138; Thu, 16 Dec 93 09:52:19 PST Date: Thu, 16 Dec 93 09:52:19 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312161752.AA06138@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: Yet Another Comment ( Sorry, I can't get another "C" in here ) I agree with the [PackageModel] concept and will await the BIRD eagerly. Concerning the "include" mechanism, there is much previous experience which can be learned from here. Newer standards (VHDL, EDIF, etc.) have learned that referencing an outside file invaribly leads to trouble. The biggest portion of that trouble is a "path" specification, if included. When "path"s are allowed, they invaribly represent a fixed, hard path on the source machine and are never represented the same on the receiving machine. It forces someone to go around looking for files, reorganizing directories, changing the IBIS files to fix the path, etc. VHDL solved this by allowing a "library" designator -- single word. It is not defined how a "file name" and "library" map to a given OS file system. In addition, many times one wants to transmit (in an EDI sense; possibly via email, etc.) the IBIS file to someone else. Transmissions of this sort usually do not have good conventions for dealing with multiple file designations. On top of that, when there are multiple files involved, it requires the concientious sender to peruse the IBIS file to find any and all file references, find the files, and then send them. DIE format and SGML DTD's (instance models of ISO 8879 style documents) allow for either a file reference or direct inclusion of the text. The direct inclusion method complicates parsing a little but guarantees inclusion when the intent is transmittal of the IBIS model. We have precedence in the format now where some boxed ([]) keywords are followed immediately by processable information; some followed by (implicit) comments on the rest of the line with the real information starting on the next line. Look carefully at the IBIS 1.1 spec for this. Based on this, I would suggest the following prototypes: 1) Combined: [PackageModel] << included file text if library name and file name not present >> [***] 2) Split [PackageModelFile] or [PackageModelInclude] << included file text >> [***] In both cases above, [***] represents the next allowable IBIS keyword. Note that to make this work (simply), one needs to be careful about allowing IBIS Keywords in the included file / text of the Package Model. We might want to consider the [Model] to be "includable" in this same light. Many times, one might want to transmit a single part to a user which is created from a library of many parts sharing the same "Model"s. From first glance this could be an "upward compatible" change. To do this though, we need to refine the 1.1 description. Currently, it is not explicitely stated that a [Voltage range], [Pulldown], [Pullup], [GND_clamp], [POWER_clamp], and [Ramp] are always in reference to the preceding [Model] definition (that is, they are sub-keywords of the [Model]). That is, we need to create a flow chart (Syntax chart or BNF) for the boxed keyword sections allowable. I propose, at minimum, the following be described more formally and included in the specification (in lieu of a formal BNF or syntax chart): [IBIS Ver] [Comment char]? [File name] [File Rev] [Date]? [Source]? [Notes]? [Disclaimer]? [Component]+ [Manufacturer] [Package] [Pin] [Model]+ [Voltage range] [Pulldown]?* [Pullup]?* [GND_clamp]?* [POWER_clamp]?* [Ramp]?* Keywords at the same level of indentation that have no intervening blank lines are in the same group. Keywords in a group can occur in any order. (allowable, in general? If a modification instead of clarification of the current spec to make this true, this is an upward compatible but not backward compatible change. Is that ok?) Groups of keywords at the same level must occur in the order the groups are specified. Keywords followed with a "+" in this chart can occur one or more times. Keywords followed with a '?' can occur zero or one time. Keywords followed by a '?*' can occur zero or one times but have extra requirements on when they can or cannot occur. All keywords one level down from a previous indentation before the indentation goes back up a level are part of a group and sub to the keyword in the previous level of indentation. If a keyword that heads a subgroup can be repeated, then the subgroup members can be repeated after another occurrence of the subgroup header keyword. Optimally, we should develop a formal BNF (and information model) for IBIS as this will clarify many items and lead to clearer thinking and understanding of the syntax. This is especially true for the 80 column discussion going on. When is the (, whatever) a terminator/separator for a keyword or other item? LMC will accept a task to develop and maintain a BNF description (or syntax chart), at minimum, if this is desired. (There is precendence. VHDL 1993 had a formal requirements generation committee (like BIRD's), which fed a formal language design/change committee (BNF, syntax, semantics, etc.), which fed a formal Language Reference Manual change committee.) randy From cer@Cadence.COM Thu Dec 16 12:36:03 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00622; Thu, 16 Dec 93 12:36:03 PST Received: from cadence.Cadence.COM (cadence.cadence.com [158.140.18.1]) by mailgate.cadence.com (8.6.4/8.6.4) with SMTP id MAA04346 for ; Thu, 16 Dec 1993 12:26:56 -0800 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA19227; Thu, 16 Dec 93 12:28:04 -0800 Received: by oahu (5.65+/1.5) id AA06923; Thu, 16 Dec 93 15:33:57 -0500 Date: Thu, 16 Dec 93 15:33:57 -0500 From: cer@cadence.com (Christopher E. Reid) Message-Id: <9312162033.AA06923@oahu> To: ibis@vhdl.org Subject: BNF and EGG 1.0 Hello, Randy Harr suggests a formal BNF notation for Ibis. I could not agree more. I'm planning a YACC parser for IBIS, and have the results from previous attempts. Anything I do in that domain can be contributed to the forum. I also agree with the "include" syntax. A library mechanism is much preferable. When EGG 1.0 hatches into a BIRD I'll be sure to take Randy's comments into account. Chris From ccm!Will_Hobbs@intelhf.intel.com Fri Dec 17 14:56:57 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12748; Fri, 17 Dec 93 14:56:57 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pAo5H-000MNjC; Fri, 17 Dec 93 14:55 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pAoBS-00002gC; Fri, 17 Dec 93 15:02 PST Received: by ccm.hf.intel.com (ccmgate) Fri, 17 Dec 93 15:02:06 PST Date: Fri, 17 Dec 93 15:02:06 PST From: Will Hobbs Message-Id: <931217150206_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Bird 5.2--minor revision ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 5.2 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: 6 December 1993 DATE REVISED: 17 December 1993 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 20 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 .... ... ... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC .... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC .... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 .... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd" column indicates the ground bus to which it is attached. The entry in the "pwr" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pwr" and "gnd" entries for it may be NC. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation, while still observing an 80-character-per-line limit. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. Bird 5.2 has been issued in response to comments from the Forum members over the use of the term "NA" in Bird to indicate the lack of a connection. NA = "not available," which would have caused confusion. This version of the Bird has been updated to use "NC" (= "no connection") instead. Otherrwise, there are no changes from Bird 5.1. ****************************************************************************** From lmsi!milpitas.lmc.com!randyh@UB.com Tue Dec 21 12:00:53 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26091; Tue, 21 Dec 93 12:00:53 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA03334; Tue, 21 Dec 93 11:56:37 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA29428; Tue, 21 Dec 93 11:51:53 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA07353; Tue, 21 Dec 93 11:51:53 PST Date: Tue, 21 Dec 93 11:51:53 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312211951.AA07353@fiji.lmsi.com> To: ibis@vhdl.org Subject: forwarded holiday greeting IBIS Group: Attached below is a message circulating the net foretelling of futures to come. A little humor for your holiday season. Happy Holidays! Randolph E. Harr, Logic Modeling Corp., randyh@lmc.com P.S. - This is an electronic holiday card! ------- Start of forwarded message ------- Return-Path: <70026.647@CompuServe.COM> Received: from eeel.nist.gov (sparky.eeel.nist.gov) by express.eeel.nist.gov (4.1/SMI-3.2-del.5) id AA07274; Tue, 21 Dec 93 08:08:31 EST Received: from dub-img-2.compuserve.com by eeel.nist.gov (4.1/SMI-3.2-del.6) id AA04056; Tue, 21 Dec 93 08:08:03 EST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.930129sam) id IAA25416; Tue, 21 Dec 1993 08:07:22 -0500 Message-Id: <931221130323_70026.647_FHA55-1@CompuServe.COM> From: "Edward L. Stull" <70026.647@CompuServe.COM> To: X3H7 Cc: Barbara LM Goldstein , Selden Stewart Subject: Serious Stuff Date: 21 Dec 93 08:03:24 EST Here is a little poem that I received from Dr Kerry Raymond, University of Queensland. I'm On a Committee - -------------------- Oh, give me your pity, I'm on a committee Which means that from morning to night We attend and amend and contend and defend Without a conclusion in sight. We confer and concur, we defer and demur And re-iterate all of our thoughts We revise the agenda with frequent addenda And consider a load of reports. We compose and propose, we suppose and oppose And the points of procedure are fun! But though various notions are brought up as motions There's terribly little gets done. We resolve and absolve, but never dissolve Since it's out of the question for us What a shattering pity to end our committee Where else could we make such a fuss? - ----------------------------------------------------- Happy Holidays !!! Ed ------- End of forwarded message ------- From cpk@Cadence.COM Tue Dec 21 19:35:12 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01785; Tue, 21 Dec 93 19:35:12 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id SAA00339; Tue, 21 Dec 1993 18:09:26 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma000235; Tue Dec 21 18:08:40 1993 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA18493; Mon, 20 Dec 93 06:56:37 -0800 Received: by hot (5.65+/1.5) id AA01119; Mon, 20 Dec 93 10:03:05 -0500 Date: Mon, 20 Dec 93 10:03:05 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9312201503.AA01119@hot> To: ibis@vhdl.org, bward@dadhb1.ti.com Subject: Re: BIRD 5.1 My view is that the mutuals should be addressed as part of a more general package modelling problem. The resolution of the mutuals (as we know from the summit - rlgc vs spice sub circuits or both) requires further discussion. So I propose that we adopt BIRD 5.1 as it is, i.e. without the mutuals - kumar From bward@dadhb1.ti.com Wed Dec 22 05:53:01 1993 Return-Path: Received: from ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07791; Wed, 22 Dec 93 05:53:01 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA18318; Wed, 22 Dec 1993 07:53:24 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA12309; Wed, 22 Dec 1993 07:51:10 -0600 Message-Id: <199312221351.AA12309@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA22470; Wed, 22 Dec 1993 07:47:23 -0600 Date: Wed, 22 Dec 1993 07:47:23 -0600 From: Bob Ward To: ibis@vhdl.org Subject: BIRD 5.2 I agree that this BIRD should be accepted as an evolutionary step forward without mutuals, and further work and discussion be carried out separately on other package related issues. ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= From bracken@valhalla.performance.com Wed Dec 22 07:46:35 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08456; Wed, 22 Dec 93 07:46:35 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA26260; Wed, 22 Dec 93 10:46:41 EST Message-Id: <9312221546.AA26260@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: BIRD 5.2 Date: Wed, 22 Dec 93 10:46:38 -0500 From: bracken@valhalla.performance.com I also feel that BIRD 5.2 should be considered independently of what is done with mutuals. To reiterate, I feel that the two issues can be treated as orthogonal to one another; if you will, the "pin mapping" deals only with circuit *topology* and the EGG deals with element *values*. I only threw out the EGG to stimulate some more discussion on the coupling issue--hopefully it hasn't muddied the waters for anyone. I'll eagerly await the promised BIRD on mutuals from Cadence. Happy holidays, Eric Bracken ---- "On the first day of Christmas, my true love gave to me, an IBIS with a parse tree..." From ccm!Will_Hobbs@intelhf.intel.com Wed Dec 22 11:42:49 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10087; Wed, 22 Dec 93 11:42:49 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pCRwI-000MOBC; Wed, 22 Dec 93 03:41 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pCZSc-0000p5C; Wed, 22 Dec 93 11:43 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 22 Dec 93 11:43:01 PST Date: Wed, 22 Dec 93 11:43:01 PST From: Will Hobbs Message-Id: <931222114301_1@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, bracken@valhalla.performance.com, ibis@vhdl.org Subject: Re[2]: BIRD 5.2 Eric, et alii IBISi, The EGG did not muddy the waters, and I agree with the other mail that suggests keeping the discussions in two separate BIRDs. Re: passing BIRD 5.2, I would like this to be a topic at our 1/7 meeting, and would urge anyone with input to let their voices be heard by then. Will I also feel that BIRD 5.2 should be considered independently of what is done with mutuals. To reiterate, I feel that the two issues can be treated as orthogonal to one another; if you will, the "pin mapping" deals only with circuit *topology* and the EGG deals with element *values*. I only threw out the EGG to stimulate some more discussion on the coupling issue--hopefully it hasn't muddied the waters for anyone. I'll eagerly await the promised BIRD on mutuals from Cadence. Happy holidays, Eric Bracken ---- "On the first day of Christmas, my true love gave to me, an IBIS with a parse tree..." From ccm!Will_Hobbs@intelhf.intel.com Thu Dec 23 16:49:19 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22809; Thu, 23 Dec 93 16:49:19 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0pD0hH-000MOxC; Thu, 23 Dec 93 16:48 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0pD0jH-00008pC; Thu, 23 Dec 93 16:50 PST Received: by ccm.hf.intel.com (ccmgate) Thu, 23 Dec 93 16:50:07 PST Date: Thu, 23 Dec 93 16:50:07 PST From: Will Hobbs Message-Id: <931223165007_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Open Forum Minutes of 12/3 Meeting Text item: Text_1 Date: December 23, 1993 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Modeling Manager, Xcceleration Tools Group Intel Corporation Hillsboro, Oregon Subject: Minutes from IBIS Open Forum 12/03/93 To: Anacad Petra Osterman AnSoft Henri Maramis* Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski, Kumar* Contec Maah Sango*, Dermott Lynch, Clark Cochran High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd*, David Wiens IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr* Mentor Graphics Greg Seltzer, Ravender Goyal* Meta-Software Stephen Fenstermaker, Mei Wong* MicroSim Arthur Wong, Meeling Wei, Jerry Brown, Graham Bell North Carolina State U. Paul Franzon, Michael Steer Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell Quantic Labs Mike Ventham, Zhen Mu Siemens Nixdorf Werner Rissiek*, Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl*, Samie Samaan, Tay Wu Cc: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the 12/3 meeting are indicated by * Next Meeting: January 7, 1994, 9:00 AM to 11:00 PST. The Phone number and Reservation number will be sent out in the week of Jan 2. Please note: If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), or have updates to your e-mail address, e- mail to ibis-request@vhdl.org. 12/3 Meeting Agenda: 9:00 Check-in 9:05 Introductions of new IBIS members 9:10 11/12 Summit Minutes Review Opens for New Issues 9:15 Enlisting new IC Vendors 9:20 Opens from Summit, BIRDS BIRD 5: Complex Package parameters, Pin Mapping New Model types BIRD 2.1 (VIH, VIL) 9:55 Other Opens How Do various EDA vendors support IBIS? Open Side IBIS V1.1 Wording error (Ramp rate versus time) Non-intrusive package parameter extraction Press Coverage IBIS Version 2.0 Plans 10:25 Wrap-Up Next Meeting Plans 1/7 Agenda In keeping with the wishes of various participants, I have arranged the order to keep technical discussions later so that those who wish to leave early may do so. 9:00 Check-in 9:05 Introductions of new IBIS members 9:10 12/3 Summit Minutes Review Opens for New Issues 9:15 Another IBIS Press Release Hobbs Enlisting new IC Vendors Forms of EDA support of IBIS Hobbs 9:30 BIRD 5, Pin Mapping Bracken EGG 1, mutual pin coupling Bracken 10:00 80 Column restriction? Non-intrusive pkg param extraction Ward Formal BNF notation Reed, Harr VIH, VIL Thresholds for Inputs, BIRD 2 Powell Spice to IBIS Converter 10:30 IBIS 2.0 Goals Hobbs 3D Modeling Muranyi New model_types (r-packs, etc.) Modeling Feedback Hobbs, Peters 10:45 Phased turn-on/off of multiple devices Powell Open Side Devices Crisafulli Other Updates (U of NC, DIE, etc.) All 10:55 Wrap-up, Next Meeting Plans Minutes: I. 11/12 Minutes review, Open time for new issues: There was one minor correction to the 11/12 IBIS minutes and a clarification. Mentor was present at the summit (though only briefly during the lunch hour) and RLGC stands for resistance, inductance, conductance and capacitance. II. Enlisting new IC Vendors Generally, everyone would like to have more IC vendors on board, but progress remains slow. We need to keep informing customers and IC vendors of IBIS and be patient. Kellee has been pushing IBIS during visits with customers. As a result of this, Cypress Semiconductor has received inquiries from their customers and is now very interested in IBIS. Bob Ward called from another site in TI, where a TI modeling council is held. He discussed IBIS with the council. In addition, one of TI's key customers has expressed interested. Together, these should help increase IBIS interest at TI. I (Will) have now received inquiries from, and sent information to, Cypress, Motorola, IBM, Toshiba, Signetics, Atmel, National Semiconductor, NEC, AT&T, Phillips, IDT and Micron, in addition to Texas Instruments and Intel, of course. Derrick Duehren, who works with me, will be contacting individuals at these companies to gauge their interest. III. BIRD 5. Pin Mapping Between the summit and the December meeting, several messages went out on the reflector about pin mapping in the package, with the hope of being able to better model ground bounce and problems resulting from simultaneous switching of outputs. One of the messages was a preliminary proposal from Eric Bracken. We discussed this. Eric stated that RLGC, which most people in the discussion and at the summit appeared to like, "works pretty well when there is only a single path from the pad to the pin, but it gets more complicated when you have branching, or several segments such as bonding wire, lead frame, etc." The question is how do you handle the more complex cases? Kumar suggested we keep IBIS simple, handling the simplest cases now with an RLGC matrix, then tackle the more difficult cases later, or provide a way of breaking out into a sub-circuit. E.g., if you have 14 pins, you could have a 14X14 matrix. We could use a keyword that says that there is an RLGC matrix present. If the vendor is supplying the model, the vendor could put out the pin mapping information, but determining that from outside measurements would be very difficult. In the DIE work, according to Randy, most of the tools can't handle the complexity we're describing now anyway, so do we want to deal with this yet? Kellee feels that ground bounce is the biggest missing piece right now. He likes what Eric described regarding a bus structure. Bob Ward raised the issue of mutual coupling through the lead frames, which is probably less than the coupling through the chip metallization. This complexity is not addressed by BIRD 5 yet, but we should probably go with the proposal as a start. Power buses are inside the chip which don't correspond cleanly with the pins that connect to the power and ground pins. Kellee wondered if we have to have that level of complexity represented in BIRD 5 needed to be successful to at least 70% as opposed to 0 that we have now. The discussion then turned to more complex pin mappings, such as a power bus tied to several pins on one side and supplying current to several buffers on the other end. Arpad suggested the possibility of a power tree structure? The discussion touched on various complications, such as rings, or parallel interconnected power structures. Bob Ward suggested the concept of a "threaded tree" that could be interconnected by naming certain levels with the same name (a trunk!). Kellee and Bob suggested that BIRD 5 be cleaned up and a separate BIRD 6 be issued that covers trees. We should then continue the discussion on e-mail. A/R Kumar, Eric Bracken: Re-write BIRD 5 in standard format by next week. Update: Done, with two revisions prompted by e-mail discussions, giving us BIRD 5.2. A/R Bob Ward: Generate initial crack (quack) at another BIRD to address power trees, with understanding that further discussion will occur. This new BIRD may be, but is not required to be, a superset of BIRD 5. IV. New Model types Several discussions in the past have alluded to a desire to represent other types of components in an IBIS-compatible format, such as pull- up resistors, etc. We did not spend much time discussing this topic, but would urge anyone with a string desire for that capability in IBIS to generate a BIRD, or an EGG. (OK, for those that haven't been following the e-mail discussion, Eric Bracken kicked off a discussion on mutual coupling between pins, and because it was preliminary and thus preceded a BIRD, he termed the suggestion an EGG.) V. BIRD 2.1 (VIH, VIL) This discussion was tabled until next meeting. Jon Powell not present. VI. How Do various EDA vendors support IBIS? Although we have active participation by quite a few simulator vendors, nowhere have we gathered together data that describes how each vendor supports IBIS. Some vendors have created a product- specific IBIS-to-their model converter, others accept native IBIS models, still others may have written application notes describing how to use IBIS data in their simulators. I (Will) asked for descriptions from everyone on how their company supports IBIS. This information will be given to our field sales and applications engineers and marketing folks so we can answer customer questions. I stated that if someone did not want to make their information publicly available, I would still like the information and would protect the information. A/R All EDA vendors: Please describe how you support IBIS (converter, application note, native IBIS models, etc.). Send this information to Will Hobbs, hobbswil@ccm.hf.intel.com A/R Will: compile the information, and make it available to the IBIS Open Forum, excluding that information which the vendors do not wish to share publicly. Update, after the meeting I received the following information from Kellee at HyperLynx. This is exactly the type of information I am seeking: IBIS support by Linesim Pro from HyperLynx 1) Any IBIS file can be used directly as a 'NATIVE' file by Linesim Pro Version 3.0 or newer. 2) A single model in an IBIS file can selected, loaded and viewed directly by LineSim Pro. 3) Several IBIS models can be included in a single file and used as a library. Note: this library file still complies completely with the IBIS specification and can be checked with the IBIS check program. VII. Open Side Kellee suggested he generate a BIRD and that we keep this topic as an open. A/R Kellee: Generate a BIRD describing the Open Side issues and proposing how to handle them. VIII. IBIS V1.1 Wording error (Ramp rate versus time) Stephen Peters and I noticed a wording problem in IBIS V1.1 with respect to the description of ramp rates. The particular offending section describes ramp rates as ramp times, which is confusing, since the min ramp data is the slow corner and thus relates to ramp rate, not time: | Ramp times for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "Y%" | | max = hi voltage tol, 0 degrees C, typical process, plus "Y%" | | | | Ramp times for bipolar devices: | | To be determined by manufacturer. | A/R Will Hobbs or Stephen Peters: Generate a BIRD to have the above wording refer to ramp rate rather than ramp time. IX. Non-intrusive package parameter extraction At the summit, Bob Ward alluded to work being done at Texas Instruments to dynamically and non-invasively extract package parameter information by measurement. Because he was unsure if this was proprietary, he said he would look into it and describe the work if he could. Since then, he has learned that TI has published some papers on this work and that it is not classified. Bob also mentioned that Bob Canwright of Convex has done some good work on this subject, too. At the time of the December meeting, however, Bob Ward had not yet received the material, and was therefore unable to comment. This will be a future topic. A/R Bob Ward: When you receive the papers, summarize via e-mail and we will put the topic on the agenda for future discussions. X. Press Coverage The press response to our October press release was underwhelming. This is somewhat surprising, given the nearly unprecedented level of cooperation happening between the large number of companies participating in the IBIS consortium. Kellee felt the magnitude of this effort is significant enough for front page coverage, not obscure footnote coverage. I brought up the summit as having been a good opportunity to use as a press generator, but felt that too much time has now elapsed. Kellee disagreed, feeling that it wasn't too late. Mei Wong of Meta-Software would like Intel Marcom to drive this. A/R Will: Fire up Intel Marcom to generate press. Update: In process. XI. 2.0 Goals Kellee asked what the goals for IBIS V2.0 were, indicating that hot needs must be the driving force behind the next revision. I stated that I felt February was a good target date, though not cast in concrete, but that we still needed to define everything we need to put into 2.0. My primary goal is to make sure the devices I need to model can be handled by IBIS and that key customer requests are addressed. The key items I was hoping for in 2.0 are controlled slew rate support and feedback. Customers are clearly interested in support for ground bounce studies. There was some fear expressed that if we introduce new IBIS revisions too quickly that may scare off newcomers. Kellee indicated we must communicate clearly with IC Vendors that they can produced 1.1 models, even though there may be a 2.0. We discussed how to handle allowing both very complex models and simple models, and that perhaps we should define IBIS model levels; The simplest acceptable IBIS model would be a level 1 model, ones that added some advanced IBIS features such as power and ground structure, would be higher level models, level 2, 3, .... Perhaps we should identify each parameter as participating in a particular level. We agreed to address these levels as we put together IBIS Version 2.0. Regarding controlled slew rate modeling, Arpad feels it can be addressed through his 3-D modeling work. 3-D descriptions can probably be handled with two to four more tables with % scaling factors to interpolate. A/R Arpad: Generate a BIRD describing the 3-D proposal. Feedback is probably a superset of surface curves. Will wondered if there could be a feedback transfer function approach that would allow the V/I curves to be scaled appropriately based on the feedback. We weren't sure if or how such transfer functions can be measured. XII. IBIS Overview Document: Will mentioned that he and Robin Rosenbaum had finished making all the changes to the introduction to IBIS document and was now distributing it to people inquiring about IBIS. A/R Will: Make the overview document available to the Forum. Update: I sent the Word For Windows file to Randy Harr who will put it onto vhdl.org. XIII. Next Meeting Plans Due to the impending holidays, the next meeting was set for January 7, 1994. See the first page of these minutes for details. A closing quote from Eric Bracken's mail: "On the first day of Christmas, my true love gave to me, an IBIS with a parse tree..." Happy Holidays, IBIS team! This has been a great year. See you next year!