From owner-ibis Thu Sep 2 05:58:06 1999 Received: from mail.huawei.com.cn ([202.96.135.132]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA20244 for ; Thu, 2 Sep 1999 05:58:00 -0700 (PDT) Received: from huawei.com.cn ([129.9.129.7]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA20796 for ; Thu, 2 Sep 1999 20:50:15 +0800 Message-ID: <37CE733C.A965FB67@huawei.com.cn> Date: Thu, 02 Sep 1999 20:53:16 +0800 From: sunweifeng X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Help Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hello Sir, I'm Sun Weifeng, a modeling engineer, working for Huawei Co., which is a communication equipment company in P R C. Now we want to obtain the IBIS model and to check the model data accuracy by physical measure, so I hope you can offer me some advice about the physical measure of model data. In addition, because we can not obtain enough ibis model of device, and many ibis model data that download from vendor web are not accuray, the ibis model become a big problem in our SI. Would you please help me how to get more IBIS model, or what is better method to create a ibis model myself? Thank you very much, Looking forwards your response, Best Regards Sun Weifeng From owner-ibis Thu Sep 2 09:08:57 1999 Received: from hazard.hyperlynx.com (root@[209.20.246.211]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21637 for ; Thu, 2 Sep 1999 09:08:56 -0700 (PDT) Received: from squidge ([192.168.148.61]) by hazard.hyperlynx.com (8.9.3/8.9.3) with SMTP id JAA20442 for ; Thu, 2 Sep 1999 09:02:08 -0700 Message-ID: <001001bef55c$8eb7f750$3d94a8c0@hyperlynx.com> From: "Matthew Flora" To: References: <4575832C8E71D111AC4100A0C96B512704A798D6@fmsmsx36.fm.intel.com> Subject: Re: BIRD #61 Date: Thu, 2 Sep 1999 09:02:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Arpad, > If we go with functions to characterize input behavior, the model maker > will have to generate the coefficients, or even the function itself. In > this case the simulator may turn into a dumb number cruncher. Personally, I have no problem with turning the simulator into a dumb number cruncher. There would still be plenty of ways to differentiate tools (speed, price, usability, completeness, platform support, etc., etc.) I assume that the model maker is the most informed of anyone on the actual behavior of the component. Therefore, I would further assume that an equation generated by the model maker would be more accurate than a generic equation fitted by an EDA tool. I realize this increases the burden on the model maker, but hopefully the same equation would be applicable to a whole family of parts (with perhaps minor modifications for each part). If this were true then the "cost" of developing the base equation could be amortized across the whole part family. (I also realize that adding support for equations to IBIS could be a large undertaking.) I myself have no experience with equation based models, so I don't have a feel for their impact on simulation times relative to table driven simulation, nor do I have a feel for the odds of equations being incorrect or incomplete. However, I am optimistic that adding equations to IBIS might stem the growth of IBIS into an ever more complicated standard that only an "expert" can use. Regards, Matthew Flora IBIS Open Forum Postmaster (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA From owner-ibis Thu Sep 2 11:39:12 1999 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA22173 for ; Thu, 2 Sep 1999 11:39:10 -0700 (PDT) From: guy@camarillo.viewlogic.com Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id OAA02793 for ; Thu, 2 Sep 1999 14:32:06 -0400 (EDT) Received: from qdt.viewlogic.com (peterbilt [139.181.194.6]) by mailhost.viewlogic.com (8.8.6/8.8.7) with SMTP id OAA27389 for ; Thu, 2 Sep 1999 14:32:05 -0400 (EDT) Received: from camarillo.viewlogic.com (b1b) by qdt.viewlogic.com (4.1/SMI-4.1) id AA02447; Thu, 2 Sep 99 11:32:07 PDT Received: from f22.viewlogic.com by camarillo.viewlogic.com (SMI-8.6/SMI-SVR4) id LAA10133; Thu, 2 Sep 1999 11:32:06 -0700 Date: Thu, 2 Sep 1999 11:32:06 -0700 Message-Id: <199909021832.LAA10133@camarillo.viewlogic.com> To: ibis@eda.org Subject: IBIS Open Forum Meeting Agenda for 9/10/99 IBIS Open Forum Meeting Agenda for 9/10/99 Bridge Number Reservation # Passcode (916) 356-9200 8-40170 4844642 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 2.1) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - 93/67/NP IBIS and EMC Simulation Perrin - JEDEC JC-16.2 Modeling and Testing Sessions EIA-656-A and ANSI/EIA-656-A Update Ross/Fleming IBIS (East) Users Group Meetings Haller IBIS Summit October 14, 1999 Ross - Attendence, Sponsorship S2ibis3 Committee Activities Cohen Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 8:45 Technical Discussion Accuracy Specification Discussion Haller/Edlund IBISCHK3 Bug Status and Plan Ross/Flora/Rokusek - BUG34 - No Error Reported for Missing V/I Tables in Output Buffers - BUG36 - Reserve Words Error for Pin Mapping and Series Pin Mapping - BUG37 - Pin Mapping for Unique GND or POWER Pin Generates Error BIRD61 - Enhanced Characterization of Receivers Peters BIRD62 - Enhanced Chararcterization of Receiver Peters Thresholds Connector Proposal Status Flora Number of Points in VT table Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Thu Sep 2 16:54:30 1999 Received: from mail01-oak.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA23407 for ; Thu, 2 Sep 1999 16:54:29 -0700 (PDT) Received: from idt.com (unknown-5-20.idt.com [157.165.5.20] (may be forged)) by mail01-oak.pilot.net with ESMTP id QAA22152 for ; Thu, 2 Sep 1999 16:47:59 -0700 (PDT) Received: from Eng.idt.com (root@maxwell.Eng.idt.com [157.165.21.24]) by idt.com (8.8.5/8.7.5) with ESMTP id QAA06442 for ; Thu, 2 Sep 1999 16:47:55 -0700 (PDT) Received: from copernicus.Eng.idt.com (copernicus.Eng.idt.com [157.165.21.89]) by Eng.idt.com (8.8.5/8.6.12) with ESMTP id QAA21999 for ; Thu, 2 Sep 1999 16:47:54 -0700 (PDT) Received: from idt.com (localhost [127.0.0.1]) by copernicus.Eng.idt.com (8.6.12/8.6.12) with ESMTP id QAA20302 for ; Thu, 2 Sep 1999 16:48:03 -0700 Sender: yyang@idt.com Message-ID: <37CF0CB1.C1FB8B10@idt.com> Date: Thu, 02 Sep 1999 16:48:02 -0700 From: Yaochou Yang X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis@server.eda.org Subject: remove, thanks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please remove my name off the mailing list. Thanks. From owner-ibis Thu Sep 2 18:54:17 1999 Received: from omail30.unitel.co.kr (omail30.unitel.co.kr [203.241.135.155]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA24076; Thu, 2 Sep 1999 18:54:15 -0700 (PDT) From: lsk1101@samsung.co.kr Received: from gp_man.sdsosc.co.kr (root@[101.1.1.30]) by omail30.unitel.co.kr (8.8.8/8.8.8) with ESMTP id KAA21015; Fri, 3 Sep 1999 10:42:32 +0900 (KST) Received: from localhost (root@localhost) by gp_man.sdsosc.co.kr (8.8.8H1/8.8.8) with SMTP id KAA18752; Fri, 3 Sep 1999 10:41:02 +0900 (JST) X-OpenMail-Hops: 4 Priority: Urgent Date: Fri, 3 Sep 1999 10:48:03 +0900 Message-Id: Subject: Please add my name to the reflector's distribution list MIME-Version: 1.0 TO: ibis-info@eda.org, ibis-users@eda.org, ibis@eda.org, ibis-request@vhdl.org Content-Type: text/plain; charset=US-ASCII; name="mail.txt" Content-Disposition: inline; filename="mail.txt" Content-Transfer-Encoding: 8bit Hello, I'm Sung-Ki Lim of computer division in Samsung Electronics. I'd like to participate in IBIS group. Please add my email address to the reflector's distribution list. lsk1101@samsung.co.kr Thank you for your attention and have a nice day. Bye. From owner-ibis Fri Sep 3 13:24:56 1999 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA28406 for ; Fri, 3 Sep 1999 13:24:55 -0700 (PDT) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id QAA10274 for ; Fri, 3 Sep 1999 16:19:19 GMT Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Sep 1999 13:18:24 -0700 Message-ID: From: "Hobbs, Will" To: "'ibis@eda.org'" Subject: Food for thought Date: Fri, 3 Sep 1999 13:18:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" IBISers, Food for thought: For years, naysayers have said that IBIS was fine for some things, but with newer, higher speed and new buffer innovations, IBIS wasn't going to be sufficient. They made that claim when we went from 50 MHz to 66, and again from 66 to 100, and so on. For years, we've proven the naysayers wrong. One of the ways we've done so has been to improve IBIS over time, adding features to support emerging needs, addressing subtler effects, etc. I won't itemize the improvements here-- just look at the deltas from IBIS 1.1 to 2.1 to 3.2, and at the current work going on to get an idea of the progression. Nonetheless, IBIS still lags some of the leading edge needs, and, as with any living standard, will probably always lag in one area or another. In addition, there are some nagging problems we still haven't addressed satisfactorily, even though we've faced them for years-- SSO comes to mind. I would like to propose a way to satisfy emerging needs in a more timely way: Define an API that would allow structural models, compiled with execution engines (such as public domain Spice variants) to interface to behavioral simulators. The API would be a C-based procedural interface that would handle passing of data back and forth between the IBIS simulation and the self-contained compiled model. The resulting simulation would be slow and big, but the model developer could have the freedom to include support for power and ground routing, and whatever other details that (s)he deemed necessary for accurate simulation not available in the current IBIS version. Meanwhile, IBIS can continue to address these emerging needs, making each successive generation's structural models unnecessary, at least until the next problem not addressed by IBIS became critical. Then this "escape" mechanism would still be available, and customers wouldn't have to run separate simulations for their unique structural models and their behavioral models. IP concerns could be dealt with through the compilation process, which could easily be obfuscated or encrypted enough to hide structural and process details. I suspect such an API could be fairly simple. For example, it would have to support a pin list, some initialization information passing, voltage and time-step information. There is probably additional data that would have to cross the simulator/model boundary, which would go into the API definition-- not sure what all that would be. Should this be part of IBIS? I think so, but am open to other opinions. At the very least, I believe this body has the right constituency to take this on if anyone agrees with this suggestion. I realize that such an API could have a detrimental effect, in addition to its positive one. If the API were to exist, it might remove some of the incentive for enhancing IBIS. However, the speed of execution issue alone would probably keep IBIS moving forward. There would also be the problem that an executable model would have to be re-compiled and re-validated for each specific platform it had to run on-- not an insurmountable problem, but one which IBIS doesn't have. I think IBIS would continue to mature for these reasons. This API might even offer a way to allow IMIC and IBIS to inter- operate-- I haven't given that much thought yet. Comments? Will From owner-ibis Tue Sep 7 17:51:36 1999 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA22219 for ; Tue, 7 Sep 1999 17:51:35 -0700 (PDT) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id RAA27389; Tue, 7 Sep 1999 17:51:02 -0700 (PDT) Message-Id: <199909080051.RAA27389@jasper.cisco.com> Date: Tue, 7 Sep 1999 17:51:02 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: Re: Help To: ibis@vhdl.org, sunweifeng@huawei.com.cn MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cFZLSOjPd5XAdyD7quXDiw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Hello, I am not sure if you rcvd a response to your enquiry. Here are some tips to help you out: To search for IBIS models: -------------------------- http://www.eia.org/eig/ibis/ibis.htm Click on 'Models'. If you cannot find the one you are looking for, contact the manufacturer directly. Creating IBIS models: --------------------- 1) IF you have the SPICE model, you can translate that to IBIS. There are tools available to do that. Go to: http://www.eia.org/eig/ibis/ibis.htm Click on 'FREE Tools' and select the 'SPICE-to-IBIS conversion' software based on your OS type. 2) IF you wish to create an IBIS model based on meaurements, Download the 'IBIS cookbook for v2.1' from the same location as above(#1). or 3) Read up on some of the articles under: http://www.eia.org/eig/ibis/ibis.htm Click on 'Articles' Regards, Syed Cisco Systems, Inc > X-SMAP-Received-From: outside > Date: Thu, 02 Sep 1999 20:53:16 +0800 > From: sunweifeng > MIME-Version: 1.0 > To: ibis@vhdl.org > Subject: Help > Content-Transfer-Encoding: 7bit > > Hello Sir, > > I'm Sun Weifeng, a modeling engineer, working for Huawei Co., which is > a communication equipment company in P R C. Now we want to obtain the > IBIS model and to check the model data accuracy by physical measure, so > I hope you can offer me some advice about the physical measure of model > data. > In addition, because we can not obtain enough ibis model of device, and > many ibis model data that download from vendor web are not accuray, > the ibis model become a big problem in our SI. Would you please help me > how to get more IBIS model, or what is better method to create a ibis > model myself? > Thank you very much, > > Looking forwards your response, > > Best Regards > > Sun Weifeng > > From owner-ibis Wed Sep 8 09:51:47 1999 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA26347 for ; Wed, 8 Sep 1999 09:51:46 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA06274 for ; Wed, 8 Sep 1999 09:51:41 -0700 (PDT) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id JAA14757 for ; Wed, 8 Sep 1999 09:51:39 -0700 (PDT) Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id JAA02596 for ; Wed, 8 Sep 1999 09:51:38 -0700 (PDT) Message-Id: <199909081651.JAA02596@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org Subject: Bird 63 -- Documentation of Receiver Setup and Hold Timing Conditions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Sep 1999 09:51:37 -0700 From: Stephen Peters Hello fellow IBISans: Following is a bird that enables an IBIS file to document the conditions under which a devices setup and hold time are specified. This bird is a companion to BIRD #62, receiver spec. Comments appreciated. Regards, Stephen Peters Intel Corp. --------- cut here ------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 63 ISSUE TITLE: Documentation of Receiver Setup and Hold Timing Conditions REQUESTOR: D.C. Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp.) DATE SUBMITTED: Sept 8, 1999 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Currently, the edge rate and overdrive conditions under which a receiver's data book setup and hold timings are specified are not documented. This bird provides a way for the model creator to document those conditions in an IBIS file. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Receiver Spec] keyword. |============================================================================= | Keyword: [Tester Spec] | Required: No | Sub-Params: Tester_Vlow, Tester_Vhigh, Tester_Vth, Tester_Slew_Setup, | Tester_Slew_Hold | Description: The [Tester Spec] keyword documents the input overdrive | and tester slew rate conditions under which a device's | input setup and hold times are specified. The subparameters | are defined as follows: | | Tester_Vth is an arbitrary voltage reference point. It is | usually the input voltage at which the output of a digital | logic receiver changes state. Tester_Vth is used as the | reference voltage for the Tester_Vlow and Tester_Vhigh | parameters. | | Tester_Vlow represents the starting voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the ending voltage of a | high-to-low going waveform. Tester_Vlow is expressed as an | offset from Tester_Vth. | | Tester_Vhigh represents the ending voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the starting voltage of | a high-to-low going waveform. Tester_Vhigh is expressed as an | offset from Tester_Vth. | | Tester_Slew_Setup is the tester waveform's slew rate at | which a receiver's setup time is specified. For purposes of | this keyword, slew rate is defined as: | | Tester_Vhigh - |Tester_Vlow| | Slew Rate = ------------------------------------------- | Time it takes to swing the above voltage | | Tester_Slew_Setup must be expressed as a number, not as | a fraction. | | Tester_Slew_Hold is the tester waveform's slew rate at which | a receiver's hold time is specified. Slew rate is defined | as above. Tester_Slew_Hold must be expressed as a number, | not as a fraction. | | | Usage Rules: The [Tester Spec] keyword is valid if the model type | includes any reference to input or I/O. All subparameters | are required to be present. When entering a value the | subparameter argument and the subparameter itself must | be separated by an equals sign (=). | | Differential Receivers: | For a single ended receiver the numerical value of | Tester_Vth is specified with respect to 0v. However, if | the [Tester Spec] keyword is describing a differential receiver | (i.e. is part of a [Model] statement that describes a pin | listed in the [Diff Pin] keyword), then the numerical value of | Tester_Vth is given as 0v. Tester_Vlow and Tester_Vhigh | are assumed to represent the difference voltage between one | input and the other. | | | A basic 3.3v single ended receiver Tester_Vth = 1.5v Tester_Vlow = -1.0v Tester_Vhigh = 2.5v Tester_Skew_setup = 1v/1ns Tester_Skew_hold = 1v/1ns | | A differential reciever Tester_Vth = 0V Tester_Vlow = -200mV Tester_Vhigh = +200mV Tester_Skew_setup = 1v/1ns Tester_Skew_hold = 1v/1ns | | ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Like it's companion BIRD #62, this bird is an attempt to better specify and document a receiver's functionality. It follows the convention of the previous BIRDS in that most of the parameter values are specified as an offset from a reference voltage. This technique supports both single ended and differential receivers. Note that there are separate slew rate entries for setup and hold time. When formulating this bird the authors were not sure if receiver hold time was specified under different slew rate conditions than setup time. Thus, separate slew rate entries. These two parameters can be collapsed into one if further information indicates that this is not the case. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. ******************************************************************************* From owner-ibis Wed Sep 8 10:32:43 1999 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA26494 for ; Wed, 8 Sep 1999 10:32:42 -0700 (PDT) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA21051 for ; Wed, 8 Sep 1999 13:33:33 GMT Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 8 Sep 1999 10:32:40 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512704A7992B@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: BIRD #61 - Function or not to function, that is the question. .. Date: Wed, 8 Sep 1999 10:32:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Matt, Thanks for your comments. I tend to agree with you for the most part, but we can't ignore some other aspects either. This is what makes it so hard for me to decide what would be better. In an ideal world, your assumption about the model maker knowing his/her parts the best is correct. However, when I you look at some of the IBIS models that are released, I wonder whether the person who made it even knows what an IV curve is. This is very sad, but true, and unfortunately it is the result of companies putting IBIS model making on the lowest priority levels. Now, if we have such levels of difficulties just getting people to understand how to make Vcc relative IV curves, or how to avoid double counting of the clamp currents, etc., I have doubts that we will see a lot of good and/or usable models based on transfer functions. I don't know if you were sarcastic in your last sentence or not, but I see your point, if it is difficult enough, people may be forced to understand what they are doing, and as a consequence the job of IBIS model making may be assigned to "smarter" people. However, this may result in a backlash, i.e. fewer models, or more bad models. So, even though I believe that using (transfer) functions would allow better and more accurate models, I am afraid that it may not be the most beneficial change if all other factors are considered. Of course, the new method would not have to exclude the old method, so we could still introduce the functions in IBIS for the "pros", but at the same time we will have to go easy on it to keep (usable) models coming... Arpad Muranyi Intel Corporation ============================================================================ ========= -----Original Message----- From: Matthew Flora [mailto:mbflora@hyperlynx.com] Sent: Thursday, September 02, 1999 9:02 AM To: ibis@eda.org Subject: Re: BIRD #61 Arpad, > If we go with functions to characterize input behavior, the model maker > will have to generate the coefficients, or even the function itself. In > this case the simulator may turn into a dumb number cruncher. Personally, I have no problem with turning the simulator into a dumb number cruncher. There would still be plenty of ways to differentiate tools (speed, price, usability, completeness, platform support, etc., etc.) I assume that the model maker is the most informed of anyone on the actual behavior of the component. Therefore, I would further assume that an equation generated by the model maker would be more accurate than a generic equation fitted by an EDA tool. I realize this increases the burden on the model maker, but hopefully the same equation would be applicable to a whole family of parts (with perhaps minor modifications for each part). If this were true then the "cost" of developing the base equation could be amortized across the whole part family. (I also realize that adding support for equations to IBIS could be a large undertaking.) I myself have no experience with equation based models, so I don't have a feel for their impact on simulation times relative to table driven simulation, nor do I have a feel for the odds of equations being incorrect or incomplete. However, I am optimistic that adding equations to IBIS might stem the growth of IBIS into an ever more complicated standard that only an "expert" can use. Regards, Matthew Flora IBIS Open Forum Postmaster (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA From owner-ibis Thu Sep 9 19:53:10 1999 Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA05786 for ; Thu, 9 Sep 1999 19:53:09 -0700 (PDT) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id TAA08196 for ; Thu, 9 Sep 1999 19:52:37 -0700 (PDT) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0) id xma008192; Thu, 9 Sep 99 19:52:25 -0700 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SHMR0ZFV; Thu, 9 Sep 1999 19:52:23 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <37D87260.A9070E7B@vlsi.com> Date: Thu, 09 Sep 1999 19:52:16 -0700 From: "D. C. Sessions" Reply-To: ibis@eda.org Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: Bird 63 -- Documentation of Receiver Setup and Hold Timing Conditions References: <199909081651.JAA02596@xtg801.pdx.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Peters wrote: > > Hello fellow IBISans: > > Following is a bird that enables an IBIS file to document the conditions > under which a devices setup and hold time are specified. This bird is > a companion to BIRD #62, receiver spec. Comments appreciated. > > Regards, > Stephen Peters > Intel Corp. > > --------- cut here ------------------- I absolutely refuse. > Buffer Issue Resolution Document (BIRD) > > BIRD ID#: 63 > ISSUE TITLE: Documentation of Receiver Setup and Hold Timing Conditions > REQUESTOR: D.C. Sessions (Philips), Stephen Peters, Richard Melitz, > Arpad Muranyi (Intel Corp.) > > DATE SUBMITTED: Sept 8, 1999 > DATE ACCEPTED BY IBIS OPEN FORUM: > > ******************************************************************************* > ******************************************************************************* > > STATEMENT OF THE ISSUE: Currently, the edge rate and overdrive conditions > under which a receiver's data book setup and hold timings are specified are > not documented. This bird provides a way for the model creator to document > those conditions in an IBIS file. > > ******************************************************************************* > > STATEMENT OF THE RESOLVED SPECIFICATIONS: > > 1) The following new keyword is defined and placed in the specification > just below the [Receiver Spec] keyword. > > |============================================================================= > | Keyword: [Tester Spec] > | Required: No > | Sub-Params: Tester_Vlow, Tester_Vhigh, Tester_Vth, Tester_Slew_Setup, > | Tester_Slew_Hold > | Description: The [Tester Spec] keyword documents the input overdrive > | and tester slew rate conditions under which a device's > | input setup and hold times are specified. The subparameters > | are defined as follows: > | > | Tester_Vth is an arbitrary voltage reference point. It is > | usually the input voltage at which the output of a digital > | logic receiver changes state. Tester_Vth is used as the > | reference voltage for the Tester_Vlow and Tester_Vhigh > | parameters. Not exactly arbitrary. This is the point at which input events are characterized to happen. It's exactly equivalent to Vmeas on ouput. It doesn't matter whether the input changes state at this point or not, but it DOES matter that this is the point where setup and hold times are defined. > | > | Tester_Vlow represents the starting voltage of the low-to-high > | going waveform a tester uses when characterizing a receiver's > | setup or hold time. It also represents the ending voltage of a > | high-to-low going waveform. Tester_Vlow is expressed as an > | offset from Tester_Vth. > | > | Tester_Vhigh represents the ending voltage of the low-to-high > | going waveform a tester uses when characterizing a receiver's > | setup or hold time. It also represents the starting voltage of > | a high-to-low going waveform. Tester_Vhigh is expressed as an > | offset from Tester_Vth. > | > | Tester_Slew_Setup is the tester waveform's slew rate at > | which a receiver's setup time is specified. For purposes of > | this keyword, slew rate is defined as: > | > | Tester_Vhigh - |Tester_Vlow| > | Slew Rate = ------------------------------------------- > | Time it takes to swing the above voltage I don't think this expression works. If Tester_Vhigh is +200mv and Tester_Vlow is -200mv then this comes out to zero. Counterintuitive. Now if you replace the absolute-value brackets with parentheses, I'll go for it. > | Tester_Slew_Setup must be expressed as a number, not as > | a fraction. > | > | Tester_Slew_Hold is the tester waveform's slew rate at which > | a receiver's hold time is specified. Slew rate is defined > | as above. Tester_Slew_Hold must be expressed as a number, > | not as a fraction. > | > | > | Usage Rules: The [Tester Spec] keyword is valid if the model type > | includes any reference to input or I/O. All subparameters > | are required to be present. When entering a value the > | subparameter argument and the subparameter itself must > | be separated by an equals sign (=). > | > | Differential Receivers: > | For a single ended receiver the numerical value of > | Tester_Vth is specified with respect to 0v. However, if > | the [Tester Spec] keyword is describing a differential receiver > | (i.e. is part of a [Model] statement that describes a pin > | listed in the [Diff Pin] keyword), then the numerical value of > | Tester_Vth is given as 0v. Tester_Vlow and Tester_Vhigh > | are assumed to represent the difference voltage between one > | input and the other. I think we should keep it general. In most cases differential Tester_Vth will be zero, but if I try I can imagine a situation where that's not true. Perhaps we should just say that in differential receivers Tester_Vth is typically zero. > | > | > | A basic 3.3v single ended receiver > Tester_Vth = 1.5v > Tester_Vlow = -1.0v > Tester_Vhigh = 2.5v > Tester_Skew_setup = 1v/1ns > Tester_Skew_hold = 1v/1ns Ummmm... Stephen? Just above you wrote that these were to be pure numbers, not fractions. Also, shouldn't these be "Tester_Slew" and not "Tester_Skew" ? A skew spec seems a bit outside of scope... > | > | A differential reciever > Tester_Vth = 0V > Tester_Vlow = -200mV > Tester_Vhigh = +200mV > Tester_Skew_setup = 1v/1ns > Tester_Skew_hold = 1v/1ns > | > | > ******************************************************************************* > > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Like it's companion BIRD #62, > this bird is an attempt to better specify and document a receiver's > functionality. It follows the convention of the previous BIRDS in that > most of the parameter values are specified as an offset from a reference > voltage. This technique supports both single ended and differential > receivers. > > Note that there are separate slew rate entries for setup and hold time. When > formulating this bird the authors were not sure if receiver hold time was > specified under different slew rate conditions than setup time. Thus, > separate slew rate entries. These two parameters can be collapsed into one > if further information indicates that this is not the case. > > ******************************************************************************* > > ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a > request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better > specification of receivers. The basic form of this bird was discussed at > a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen > Peters, Richard Melitz and Aprad Muranyi of Intel Corp. > > ******************************************************************************* -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Thu Sep 9 20:39:01 1999 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by server.eda.org (8.8.5/8.8.3) with ESMTP id UAA06485 for ; Thu, 9 Sep 1999 20:39:00 -0700 (PDT) From: d04nms22@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA139986 for ; Thu, 9 Sep 1999 23:38:30 -0400 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.04) with SMTP id XAA79386 for ; Thu, 9 Sep 1999 23:38:57 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567E8.001407DF ; Thu, 9 Sep 1999 23:38:47 -0400 X-Lotus-FromDomain: IBMUS To: ibis@eda.org Message-ID: <852567E8.0014069D.00@d54mta04.raleigh.ibm.com> Date: Thu, 9 Sep 1999 23:38:42 -0400 Subject: Michael Cohen/Raleigh/IBM is out of the office until 09/23/99. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline I am out of the office from 09/08/99 returning 09/23/99. I will respond to your message when I return. If this is an emergency, please contact my manager, Duane Harper, (duaneh@us.ibm.com or Duane Harper/Raleigh/IBM). If this is related to Signal Integrity or IBIS Models, please contact my team lead, Brad Herrman (herrman@us.ibm.com or Brad Herrman/Raleigh/IBM). From owner-ibis Fri Sep 10 16:53:04 1999 Received: from hub1.issi.com (hub1.issi.com [204.118.80.10]) by server.eda.org (8.8.5/8.8.3) with SMTP id QAA14137 for ; Fri, 10 Sep 1999 16:52:57 -0700 (PDT) Received: by hub1.issi.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 882567E8.0082F5B6 ; Fri, 10 Sep 1999 16:50:25 -0700 X-Lotus-FromDomain: ISSI From: "John T Chiang" To: ibis@eda.org Message-ID: <882567E8.008351BB.00@hub1.issi.com> Date: Fri, 10 Sep 1999 16:57:17 -0700 Subject: How to determine when to invoke the Vcc and Gnd Reference points ... Mime-Version: 1.0 Content-type: text/plain; charset=big5 Content-Disposition: inline Can someone familiar with the IBIS modeling process explain when to invoke the Vcc and Gnd Reference potentials that are different than actual Supply and Gnd potentials? Best Regards, John Chiang ISSI Application Engineering From owner-ibis Tue Sep 14 10:56:28 1999 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA29943 for ; Tue, 14 Sep 1999 10:56:26 -0700 (PDT) From: guy@camarillo.viewlogic.com Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id NAA07586 for ; Tue, 14 Sep 1999 13:55:53 -0400 (EDT) Received: from qdt.viewlogic.com (peterbilt [139.181.194.6]) by mailhost.viewlogic.com (8.8.6/8.8.7) with SMTP id NAA01160 for ; Tue, 14 Sep 1999 13:55:50 -0400 (EDT) Received: from camarillo.viewlogic.com (b1b) by qdt.viewlogic.com (4.1/SMI-4.1) id AA04606; Tue, 14 Sep 99 10:56:05 PDT Received: from f22.viewlogic.com by camarillo.viewlogic.com (SMI-8.6/SMI-SVR4) id KAA09567; Tue, 14 Sep 1999 10:56:04 -0700 Date: Tue, 14 Sep 1999 10:56:04 -0700 Message-Id: <199909141756.KAA09567@camarillo.viewlogic.com> To: ibis@eda.org Subject: 9/10/99 EIA IBIS Open Forum Meeting Minutes DATE: 9/14/99 SUBJECT: 9/10/99 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: Applied Simulation Technology Raj Raghuram, Norio Matsui, Neven Orhanovic, Fred Ballesteri Avanti Nikolai Bannov Cadence Design Mike LaBonte* Cisco Systems Syed Huq* Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella Fairchild Semiconductor [Peter LaFlamme], Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu HyperLynx (& Pads Software) Matthew Flora*, Kellee Crisafulli, Lynne Green, John Angulo* IBM Greg Edlund, Michael Cohen, Praven Patel Incases Olaf Rethmeier*, Werner Rissiek, David Eagles, Wilhelm Arnoldi, Ulrich Losch Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson, Jeff Day, Richard Mellitz, Peter Liou, Will Hobbs, Henri Maramis LSI Logic (Symbios Logic) Scott King Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad, Jean Oudinot, Markku Kukkanen, Martin Groeber, Karine Loudet, Hisham Gamal, Evgeny Wasserman Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen, Peter Christiaans Quantic EMC (Mike Ventham) Siemens Bernhard Unger, Christian Mitschke, Manfred Maurer, Peter Kaiser, Wolfram Meyer, Gerald Bannert, Harmut Ibowski, Katja Zuleeg, Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo, Christian Sporrer SiQual Scott McMorrow Texas Instruments Jean-Claude Perrin, Shankar Balasubramaniah, Ramzi Ammar, Thomas Fisher Time Domain Analysis Systems Dima Smolyansky Viewlogic Systems Chris Rokusek, Guy de Burgh, Cary Mandel, (Jon Powell) VeriBest Ian Dodd VLSI Technology D.C. Sessions* OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel Analytical Edge Robert Easson Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf Celestica Danny Da Silva ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming*, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch FCI John Ellis High Design Technology Razvan Ene Hitachi ULSI Hideki Fukuda Infineon Thomas Latzel Intracon Design Mike Osmond Litton Systems Robert Bremer Matsushita Atsuji Itoh Molex Incorporated Gus Panella Nortel Networks Martin Hall (& at Viewlogic), Calvin Trowell Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Shindengen Tsuyoshi Horigome Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre StorageTek Nick Krull Sun Microsystems Victor Chang, Kevin Ko Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel Xilinx Susan Wu (Unaffiliated, Retired) Bruce Wenniger In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode October 1, 1999 (916) 356-9200 8-40171 4196281 October 14, 1999 IBIS Summit Meeting, No Teleconference All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM No new participants. MEMBERSHIP UPDATE AND TREASURER'S REPORT Cecilia Fleming noted that invoices have been sent to members that have been dropped. Bob Ross stated that we have 30 official members and also a potential new member pending payment. Bob also mentioned that Guy de Burgh has been updating the membership list with primary and secondary members as required by EIA. He still needs responses from about six member companies. REVIEW OF MINUTES AND AR'S The August 20, 1999 Minutes were approved without corrections. Bob Ross noted that work has been done on the following AR's, and they will be discussed at the next meeting: AR - Bob Ross and Cecilia Fleming research what is needed to align the IBIS bylaws with EP-20. AR - Bob Ross and Cecilia Fleming write position definitions for the new positions of Webmaster and Postmaster. Other AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Bob Ross stated that we will discuss the issue of IBIS dues and funding at the next meeting. We currently collect about $15,000 per year. Our direct expenditures are modest. However, we do need to provide funding to EIA for their staffing and services. Based on EIA budget allocations among various committees, we need to provide an estimated $22,000 for year 2000. Bob plans to provide more budget information on the IBIS reflector. Some possible proposals for discussion might include raising the membership fee to $750 or higher, have a split membership fee of $500 for small companies and $1000 for large companies, or have a higher membership fee (say $2000) to cover other expenses as well. PRESS AND WEB PAGE UPDATES Syed Huq indicated that he updated Specification page so that it describes Version 3.2 as the August 20, 1999 version of IBIS. Syed also updated the HyperLynx logo and added the Avanti logo to the IBIS Poster page. He removed the AMP logo. Syed has received a lot of Roster updates from members along with membership information from Guy de Burgh. Syed plans to have the Roster updated next week. Bob Ross uploaded a revised version timing101.ppt by Todd Westerhoff in the training directory as timing101b.zip: http://www.eda.org/pub/ibis/training/ NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross noted that the Samsung IBIS model link previously published no longer points to any IBIS models. OPENS FOR NEW ISSUES Stephen Peters on BIRD63 - Documentation of Receiver Setup and Hold Timing Conditions Bob Ross on comments on Will Hobb's API (Mentioned briefly in the BIRD61 discussion) Arpad Muranyi on list of IBIS Version 4.0 functions (also Connector Specification Status already scheduled) (Not discussed) Mike LaBonte on time spent on formal certification processes INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Cecilia Fleming reported no further news on the comments she forwarded to IEC in response to the letter ballot. Bob Ross stated again that the TC93 meeting is being held in Arlington, Virginia on September 22-23 and that IEC 62014-1 is on the agenda. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross had no further report. - IEC 93/67/NP IBIS and EMC Simulation - Bob Ross reported that Jean-Claude Perrin held a meeting at UTE in Paris on August 31, 1999 in preparation for the TC93 meeting. He is also continuing to do power supply HF current measurements on selected circuits. Test boards are under design. - JC-16.2 Subcommittee: Modeling and Test - D.C. Sessions reported that he will be in Vancouver, British Columbia at a JEDEC meeting and will report in a formal presentation on the progress on BIRD61, BIRD62, and BIRD63. These BIRDs are of great interest to JEDEC and are needed for specifying certain new technologies. D.C. noted that he will send copies of his presentation to anyone who request them directly from him. EIA-656-A AND ANSI/EIA-656-A UPDATE Cecilia Fleming reported that EIA-656-A has been sent to Global Engineering for publication. It has also been sent to ANSI, and she expects approval in two to three weeks. Stephen Peters asked about a possible press release. Bob Ross stated that he plans that EIA issue a press release announcing ANSI/EIA-656-A as soon as ANSI approval is achieved. IBIS (EAST) USERS GROUP MEETINGS Bob Haller reported that the IBIS Users Group is meeting on Wednesday, September 15, 1999 (3 PM to 5 PM Eastern time) at NESA in Stow, Massachusetts. The agenda is to prepare for the IBIS Summit Meeting. It will be possible to teleconference into this meeting. Bob noted that several people are working on some accuracy test cases. More help from others would be welcome. IBIS SUMMIT OCTOBER 14, 1999 Bob Ross noted that a second call for presentations, participation and sponsorship has been sent out for the IBIS Summit meeting scheduled on Thursday, October 14, 1999 at Marlborough, Massachusetts during the week of the PCB Conference East. Bob reported on recent information from Kathy Breda. About 10 people have signed up. Several people commented that they plan to attend and may not be included in Kathy's count. Bob stated that is about what is expected at this time. So far Praegitzer, Cadence and NESA (along with the IBIS Users Group) are expected to be co-sponsors. We still need to follow up on some other potential sponsors. One presentation has been submitted so far: Tables and Equations by Lynn Green, HyperLynx A few others are expected. However, Bob would like to have more time for group discussion topics. Topics will probably include Business (if needed) Accuracy Specification Connector Specification Input Modeling Spice to IBIS With about one hour each and a few presentations, we can easily take a full day. Stephen Peters mentioned that a few slides could be given in the Input Modeling presentation. Bob Haller noted that it would be good to have the discussions first, since longer than expected presentations might cut into some valuable discussion. S2IBIS3 COMMITTEE REPORT Arpad Muranyi reported that two meetings occurred on August 25, 1999 and on September 2, 1999. The group is continuing to go over the list of improvements from Michael Cohen's presentation at the June 18, 1999 IBIS Summit meeting. Arpad made available the IBIS Center program to the committee members. Syed Huq stated that he plans to draft a requirements document. Bob Ross noted that the next meeting is scheduled on Thursday, September 30, 1999. COOKBOOK STATUS Stephen Peters had no report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora sent out a model from Transmeta for review. The model did reveal a potential ibischk3 problem. Matthew also stated that he needs some new people (replacing some individuals no longer with the companies) to send models to. TIME SPENT ON FORMAL CERTIFICATION PROCESS (new topic) In proposing this topic, Mike LaBonte asked if the Committee had spent too much time on the final processing of comments in order to formally approve EIA-656-A. This detracted from other ongoing activities. Bob Ross listed a number of ongoing Committee activities including the Accuracy Specification, Connector Specification, ibischk3 bugs, Spice to IBIS conversion, and general IBIS Version 4.0 issues (such as Input Modeling). In introducing the discussion, Bob stated that the document had undergone a formal public review, and we needed to follow some rigorous processes to assure that all concerns were properly addressed. The process actually went smoothly since no really controversial issues emerged. We do not expect to undergo this type of process until we deal with formal EIA ratification of IBIS Version 4.X. However, a similar review process would be applied to any other document that would be considered for EIA and ANSI standardization (such as the Accuracy Specification). D.C. Sessions commented that we did produce a better document as a result of the review process. Stephen Peters was concerned by the amount of time spent on line-by-line review of comments. Bob suggested that some of this could have been handled off line by a committee. We would then just vote on the committee recommendation. Bob also noted that we did allow at least two weeks to consider any significant comment and response. Mike LaBonte suggested that during such an intensive period of review we could also schedule more IBIS meetings. Bob noted that during that time the IBIS meetings were at two-week intervals. We also could have conducted the voting off-line by e-mail. ACCURACY SPECIFICATION DISCUSSION Bob Haller introduced the discussion by stating that the purpose of the Accuracy Specification document is to provide a method for model creators to communicate to model users that the model has been tested for accuracy. Furthermore, it communicates how the model correlates with reference data. Bob mentioned that several individuals are attempting to do some correlation studies, but more help will be welcome. Bob Ross stated that the accuracy specification itself needs to be applied as a reality check and to uncover any issues, especially with correlation methods. Syed Huq asked whether the Accuracy Specification was to be used for complex devices. Bob Haller answered that it focused on all I/O pins of any device. Bob indicated that some of the tests could be done with Spice Models assuming that the Spice model correlation to measurement was known. D.C. Sessions added that a good test engineer can modify existing tests used in production to do some of the IBIS test extractions. In fact, the IBIS formatted data can be used as the parametric definition of I/Os. Syed commented that the V-T tables were more difficult to extract. D.C. argued that test engineers can also provide transient responses. Bob Haller stated that a keyword could be added to indicate that accuracy information exists for the model. Bob and Stephen Peters both stated that having such information provided confidence in the model. Stephen Peters wondered if the document should be referred to as a Validation Specification. Bob stated that this had been considered by the Accuracy Committee. In the introduction of the document a definition of Accuracy is given as a measure of the true value. Bob Ross commented that validation processes might also consider the values of other parameters such as input thresholds that are not measured. Mike LaBonte mentioned that some reference waveforms could be incorporated into the Spice to IBIS requirements. Bob Ross concluded that more discussion will be scheduled at IBIS Summit meeting. IBISCHK3 BUG REPORT STATUS Bob Ross introduced the issue regarding how we deal with ibischk3 bugs. Fixes to both BUG36 and BUG37 are known and are fairly simple. The question is who should implement the fixes. At this time we do not have funds for more parser work by Atul Agarwal. Even so, simple fixes could be done by Matthew Flora, Chris Rokusek or Atul. D.C. Sessions commented that the Linux model uses a method of source code control. Matthew stated that he, Chris and Atul use RCS and do share with each other any fixes to assure that the common code base is the same. In response to comments, Bob stated that thirteen companies have funded the ibischk3 parser development. After some discussion, Bob stated that he work with Atul, Chris and Matthew on suggestions to implement bug fixes. AR - Bob Ross ask Atul Agarwal, Chris Rokusek, and Matthew Flora their recommendations on fixing bugs. Also D.C. Sessions and Syed Huq may be consulted concerning source code control and Linux models. Matthew stated that he now has more time. He is working on BUG34 suggestions with respect to the existing AR: AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. Matthew introduced another issue where ibischk3 may operate in a compiler specific manner. Under Windows, the check for searching the director for .pkg files in the same directory may call some compiler-specific utilities. D.C. commented that compiler switches are often used. BIRD62 - ENHANCED CHARACTERIZATION OF RECEIVER THRESHOLDS Stephen Peters introduced BIRD62 first since BIRD61 has already been discussed at the August 20, 1999 IBIS Meeting. The intent of BIRD62 is to provide receiver threshold specification in a tighter manner than possible using Vinh and Vinl. BIRD62 adds the keyword [Receiver Thresholds] (or [Receiver Spec]) and new threshold subparameters. These subparameters are made relative to a designated receiver trip point subparameter Vth. The trip point can vary with supply voltage changes or external reference voltage changes in a designated manner. Stephen commented that the traditional typ-min-max format is not used because the typ-min-max meaning is tied to just the voltage changes and not the process corners. Stephen also mentioned that the [Receiver Threshold] subparameters, if defined, would supersede the Vinh and Vinl information. This needs to be stated. D.C. Sessions noted that new technologies such as STTL and HSTL cannot be handled by existing IBIS Version 3.2 subparameters. BIRD62 is important to JEDEC. Bob Ross asked for clarification of Vth_min and Vth_max. Stephen indicated that Vth tracks voltage reference changes in the designated manner. Vth_min and Vth_max may give deviations from the Vth based on other tolerances or process changes. So the min and max meaning may be different. Stephen commented that may need to look at other terminology, if this is confusing. BIRD63 - DOCUMENTATION OF RECEIVER SETUP AND HOLD TIMING CONDITIONS (new) Stephen Peters then introduced the recently issued BIRD63. BIRD63 defines the edge rate and overdrive conditions for defining the data book setup and hold test conditions. Stephen stated that the he has not yet reviewed the comments just issued by D.C. Sessions. Stephen expects some changes. BIRD63 introduces the [Tester Spec] keyword and subparameters for tester trip points. Similar to [Receiver Thresholds], the Tester_Vth defines the reference trip point. Tester_Vhigh and Tester_Vlow are offsets from Tester_Vth. Also similar to [Receiver Thresholds], the [Tester Spec] subparameters can be applied to single-ended or differential conditions. Tester slew rates are also defined. Stephen commented that BIRD63 supports different setup and hold slew rates. He did not know if different rates were used in practice. Often the value 1 V/ns is used. D.C. Sessions commented that the slew rate entry should be entered as one number, not as the ratio that is documented in BIRD63. Bob Ross commented that some of the subparameters for both BIRD62 and BIRD63 may fit into the [Model Spec] keyword. He was also concerned using the same subparameter for both single-ended or differential entries, where the where the definition is differentiated by a subparameter value. Bob felt that different subparameter names are needed for differential definitions. BIRD61 - ENHANCED CHARACTERIZATION OF RECEIVERS Stephen Peters introduced the discussion on BIRD61 by noting that BIRD61 was intended to provide sufficient information to produce an abstract model for describing an receiver and internal delays associated with arbitrary input waveforms. A model needs to be extracted from the information tables. It could be adjustment coefficients or an equation. The tables themselves were not intended to be used directly. Stephen stated that he received some comments indicating that more information in the form of a three-dimensional table might be needed. D.C. Sessions commented on the need for a logical receiver model. Perhaps a generic Spice Model could be developed as the basis of a receiver model. Bob Ross commented that the actual Spice model itself is the logical receiver model, but business constraints prevent it from being issued. So the technical challenge is to seek a alternative to an existing solution that is of the required accuracy. Bob also noted that he wanted to avoid different solutions that might support vendor differentiation. That would not serve the industry. Also, Bob mentioned that this issue could relate to the API issue raised by Will Hobbs. (We did not have time to discuss this issue directly.) The API would allow executing the actual Spice model without requiring it to be revealed. Bob stated that this discussion should be continued on the reflector and that he plans to issue some comments. CONNECTOR PROPOSAL STATUS Matthew Flora reported that Kellee Crisafulli has been doing more work on the Connector proposal and may send out some material next week. NUMBER OF POINTS IN VT TABLE Not discussed. NEXT MEETING: The next teleconference meeting will be on Friday, October 1, 1999 from 8:00 AM to 10:00 AM. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@viewlogic.com Senior Manager, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Signal Integrity Engineer, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Sep 14 17:27:21 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA01254 for ; Tue, 14 Sep 1999 17:27:21 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA05224; Tue, 14 Sep 1999 17:26:47 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA17137; Tue, 14 Sep 1999 17:26:46 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37DEE7C5.C5B3E73B@mentor.com> Date: Tue, 14 Sep 1999 17:26:45 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: BIRD61 - Input Model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: I have been following the BIRD61 discussions. At this time, we are still looking for a solution to simulate delay variations as a function of actual input waveforms Vin(t). The reference model that captures delay variations is the Spice model itself. However, for business reasons (versus technical reasons), this model may not be available. BIRD61 attempts to work around this limitation by providing delay data (that may be derived from Spice Model simulation). The simulator then is supposed to use this data to derive an equivalent model of delay changes that can be applied for an arbitary Vin(t). BIRD61 proposes to tabulate delays as a function of IDEAL input ramp parameters: Start_point, End_point, and Slope. Two general approaches can be taken to apply this data: (1) Develop a method to characterize an arbitrary Vin(t) into table parameters and use the delay tables directly. (2) Use the table data to develop model of the input from which Vin(t) can be transformed (through simulation or tranformation) and the resulting delay can be derived. The authors intended that this approach be taken. Approach (1) is attractive. It is possible to provide a table as a function of all three parameters that captures the changes over the ranges of interest. The table ranges of interest would need to include the min and max values of all of the parameters. Other intermediate values might be needed. However. the amount of data would depend upon how accurate the delays are when such data is extracted using interpolated values of Start_point, End_point, and Slope. The problem is to characterize an "arbitrary" input into the "effective" Start_point, End_point, and Slope. While there is no perfect process, some defendable approximation approach might stated such as: Start_point = Min point, End_point = Max point, Slope = Slope from Min to Max, but derated by some known manner. The problem is to find a good derating method. Some approaches might be to assume a fixed factor, use the (set of) test waveforms to derive a factor, or use some mathematically derived effective slope. The recommended derating method should be one that we agree upon. The model provider then has enough information to populate the table based on ideal ramp inputs (that do not need derating) and also to test the accuracy of applying the derating method on real waveforms. Approach (2) is attractive for its simplicity. However, in order for Approach (2) to be practical, we really do need use the same input model because: Simulators need to produce consistent results. Model providers need to know how the data is used in order to produce a sufficient amount of tabular data and to also check the validity of the calculated delay adjustment against the reference model delay simulation. So far, the proposers of BIRD61 have investigated, without success, some equation based input models. These models could be of the following forms: (a) Vin(t) transforms into a delta delay value directly, (b) Vin(t) transforms into a Vout(t) from which the delta delay value is calculated. While I can speculate on a number of approaches, I really do not know where to begin. Approach (a) may be to capture as part of the equation the delay as a function of voltage (under and overdrive effects extracted from the real Vin(t)) and also adjustments as a function of slope (derived in some manner from Vin(t)). Approach (b) is the mathematical equivalent of the complete Spice model itself (or a simplification). In the extreme case, a (large) set of mathematical non-linear equations could be provided that are the Spice equations with the given process parameters. These equations would relate Vin(t) and Iin(t) of the input node to Vout(t) and Iout(t) of the output node. No table data is needed. The given equations are applied directly through Spice simulation. If a simplified set of equations are presumed, table data is needed to fit the coefficients or parameters. However, for consistency, we all need to use the same set of equations. Also, the question arises whether a generic Spice input structure might be presumed (implying only one set of equations). One problem may be that the format of the set of equations will vary with different input structures. I think we should continue to pursue Approach (2) and may actually discover a solution. However, we need some break-through information such as a good starting point for an equation structure or a good input model (e.g., operational amplifier with feedback) to investigate this further. In the mean time, I think Approach (1) is more promising. Bob Ross Mentor Graphics From owner-ibis Thu Sep 16 10:44:54 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA12149 for ; Thu, 16 Sep 1999 10:44:53 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA08507; Thu, 16 Sep 1999 10:44:19 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA11452; Thu, 16 Sep 1999 10:44:18 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37E12C72.7BEF456B@mentor.com> Date: Thu, 16 Sep 1999 10:44:18 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Fred Balistreri , ibis@eda.org CC: Bob Ross Subject: Re: BIRD61 - Input Model References: <37DEE7C5.C5B3E73B@mentor.com> <37DFC90F.EDF@apsimtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fred: You raise some good points and have offered an alternative. Working directly with tables is the only approach I know so far. As you indicate, table lookup method has its potential problems for arbitrary inputs. While different input modeling approaches might be implemented (and defended) by different vendors, we are seeking at least one approach that is defendable. Without knowing any approach, we do not know what minimum set of data is necessary. You indicate that simulation model can be developed that would respond to arbitrary inputs. The set of data for this is the set of Vout(t) tables for a range of Input ramps with different slopes. Can you indicate the minimal set of data needed to implement this approach? How many Vout(t) tables do you need? Will minimum and maximum slope tables be sufficient? Do you need a range of Vout(t) tables with different Start_point and End_point values to capture overdrive/underdrive effects? What is this set? Also I have some general question on Input models: Do we need Vout(t) to be extracted under defined load conditions? Does a Vmeas need to be specified as the point at which the delay is measured? If Vmeas is internal, does it need to be given? Since the Input model transfer may be impacted by overdrive/underdrive conditions, does the input timing reference point for arbitrary input slopes or waveforms need to be specified as Vth defined elsewhere? Bob Fred Balistreri wrote: > ... > > Bob what the current Bird does is give information of delay versus > slope. However as you mentioned slope is a linear ramp. Left as it is > a vendor would have to determine slope, presumably during simulation > in order to choose the right delay. However as you know during SI > simulation the slope is anything but linear. You therefore are opening > a can of worms. No doubt each vendor's answer could be different since > the algorithm to determine slope (what ever that means) could be > different. Now for the killer. With non-linear slope you don't know who > is right, and with the data given there is no way to determine it. I > actually don't care that each vendor is different. Yeah after all that's > how we distingish ourselves, right? I don't know about you but one way > I win business is to prove my answer is better than yours. But this > Bird does not give me enough information to make a better model or > even a determination of. > > I've said this before but I'll repeat it again. More information could > be achieved by giving the devices voltage transfer curve(s). That's > Vout as a function of Vin. This would be tables for rising and falling > waveforms under different input slope test conditions. This type of > information gives the vendor precise information (much like I/V curves) > about the devices characteristics without revealing any structural > or equations at all. Since Vil, Vih are known the delay numbers can > be easily derived from simulation. Not only that the model can be made > more dynamic and would better measure delay as a function of non-linear > slope. In this way it's straight forward. The vendor does not need to > determine slope and no equations (guess work) is needed. > > Anyway my two cents (what the hell yeah!) as Canadians say. > > Best Regards, > -- > Fred Balistreri > fred@apsimtech.com > > http://www.apsimtech.com From owner-ibis Thu Sep 16 11:46:12 1999 Received: from oliver.al.dynip.com (root@209-63-189-80.sea.jps.net [209.63.189.80]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA12374 for ; Thu, 16 Sep 1999 11:46:10 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by oliver.al.dynip.com (8.9.3/8.8.7) id KAA21111; Thu, 16 Sep 1999 10:40:41 -0700 From: Al Davis To: Stephen Peters , ibis@eda.org Subject: Re: BIRD #62 -- Enhanced Specification of Receiver Thresholds Date: Thu, 16 Sep 1999 10:25:12 -0700 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <199908241548.IAA04078@xtg801.pdx.intel.com> MIME-Version: 1.0 Message-Id: <99091610404103.01093@oliver.al.dynip.com> Content-Transfer-Encoding: 8bit 1. How does this relate to existing receiver related info in ibis (Model Spec stuff, thresholds, etc.) ? Please be specific. If some keywords are the same, or have some fixed relationship, say so. I am not asking for a personal reply. This should be part of the spec. 2. Since we have some keywords, and the Model Spec group, this seems to add another group that is related in that it provides related info, yet blocked out separately, with a form of modularity that seems orthogonal to what it seems ought to be grouped. Shouldn't the existing thresholds and the new added info be in the same group, so a new user can understand it without following it historically? Why not just add the new keys under Model Spec? 3. Why do some parameters have typ/min/max syntax, while others have 3 separate parameters: Vth, Vth_min, and Vth_max? I have no problem with the new info provided about the circuit, just its presentation. From owner-ibis Thu Sep 16 13:03:14 1999 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA12575 for ; Thu, 16 Sep 1999 13:03:13 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA08519; Thu, 16 Sep 1999 13:03:05 -0700 (PDT) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id NAA16734; Thu, 16 Sep 1999 13:03:04 -0700 (PDT) Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA08499; Thu, 16 Sep 1999 13:03:03 -0700 (PDT) Message-Id: <199909162003.NAA08499@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: Al Davis cc: ibis@eda.org Subject: Re: BIRD #62 -- Enhanced Specification of Receiver Thresholds In-reply-to: Your message of "Thu, 16 Sep 1999 10:25:12 PDT." <99091610404103.01093@oliver.al.dynip.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Sep 1999 13:03:03 -0700 From: Stephen Peters Hello Al: I will answer your third question first as it has a direct bearing on your other two questions. The Vth parameter is speced as Vth, Vth_min and Vth_max so that variation in threshold voltage due to differing gate thresholds ratios between the P and N channel devices could be isolated from the change in threshold due to supply variations. To put it another way, Vth_min and Vth_max represent the variation in threshold voltage under typical operating (VCC and temp) conditions only. In IBIS, the min and max columns include effects from both operating point (VCC and temp) as well as process. This is not what the authors wanted, so there had to be three separate parameters. Note that one can calculate the traditional min and max value for Vth by factoring in the the variations in supply voltage (or reference voltage as the case may be) as shown in the BIRD. The above also explains why I choose to use a separate [Receiver Thresholds] keyword for these parameters. The parameters of the current [Model Spec] keyword use only the traditional three column typ/min/max format. I was not comfortable adding to this keyword parameters that use the parameter = value format, especially with the Vth_min and Vth_max parameters. No other keyword mixes these two formats for single valued (non-table) parameters. As far as the relationship between this keyword and other keywords go, the bird states that if the [Receiver Threshold] keyword is present the Vin*_ac and Vin*_dc parameters override any other input threshold parameters given elsewhere. However, I do agree that the bird should call out the affected parameters specifically. (Note that the [Receiver Threshold] keyword does not effect any of the overshoot limit parameters in [Model Spec]). I will clarify this the next time the bird is reissued. Thanks for the input. Regards, Stephen Peters Intel Corp. > 1. How does this relate to existing receiver related info in ibis (Model Spec > stuff, thresholds, etc.) ? > > Please be specific. If some keywords are the same, or have some fixed > relationship, say so. > > I am not asking for a personal reply. This should be part of the spec. > > 2. Since we have some keywords, and the Model Spec group, this seems to add > another group that is related in that it provides related info, yet blocked out > separately, with a form of modularity that seems orthogonal to what it seems > ought to be grouped. Shouldn't the existing thresholds and the new added info > be in the same group, so a new user can understand it without following it > historically? Why not just add the new keys under Model Spec? > > 3. Why do some parameters have typ/min/max syntax, while others have 3 separate > parameters: Vth, Vth_min, and Vth_max? > > > I have no problem with the new info provided about the circuit, just its > presentation. From owner-ibis Thu Sep 16 18:25:29 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA15184 for ; Thu, 16 Sep 1999 18:25:28 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id SAA15864; Thu, 16 Sep 1999 18:24:53 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA28650; Thu, 16 Sep 1999 18:24:52 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37E19864.1FCCFECC@mentor.com> Date: Thu, 16 Sep 1999 18:24:52 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD62 - Comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: I also have concerns about introducing new keywords and subparameters when exiting methods may work. However, after trying out a few examples, I now see the differences. These are at the end with comments. BIRD62 introduces a new keyword [Receiver Thresholds] and several new subparameters. Several key components are: Vth - ideal fixed threshold voltage Vth_min and Vth_max - deviations from the ideal threshold voltage Vth_sensitivity - relationship of Vth to some specified reference voltage [External Reference] if needed for external references. Vinl_ac, Vinh_ac - "AC" thresholds as deviations from Vth Vinl_dc, Vinh_dc = "DC" thresholds as deviations from Vth Definition of all parameters relative to Vth The notion that these parameters are for differential inputs if Vth = 0. Several major comments are: (1) While I cannot think of any current example where this would be a problem, I would still not mix Vth single-ended definition with differential definition, distinguished only by value. This would cause problems if there is a new single-ended technology that is connected to positive and negative supplies. Also, it may be possible to use the same buffer model for both single-ended and differential applications. With this format, I would prefer separate Diff_Vth subparameter. The offset subparameters for differential operation might also be different. (2) For single-ended operation, the existing [Model Spec] keyword already has much of the necessary information. With a few additions, it could be used. BIRD62 examples are illustrated. Assumptions: The Vinl_dc and Vinh_dc values function as the existing Vinl and Vinh thresholds The Vinl_ac and Vinh_ac values function as existing Vinl and Vinh thresholds, but with margins. Currently these may entered as part of the rules or design data and are not considered as a specification of the buffer. Assuming that they are now needed, I arbitrarily defining them by they new [Model Spec] subparameters also designated "Vinl_ac" and "Vinh_ac" The | Vth is entered as a [Model Spec] subparameter for information, but is not needed. Here are the BIRD62 examples and the corresponding [Model Spec] Syntax: --------------------------------------------------------------- | | A basic 3.3v single ended receiver using only the required | subparameters | [Receiver Thresholds] Vth = 1.5v Vinh_ac = +225mV Vinh_dc = +100mV Vinl_ac = -225mV Vinl_dc = -100mV | | --------------------------------------------------------------- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.725 NA NA Vinh 1.6 NA NA | Vth 1.5 NA NA Vinl 1.4 NA NA Vinl_ac 1.275 NA NA | No change --------------------------------------------------------------- | A single ended receiver using an external threshold reference. In this | case the input threshold is the external reference voltage so | Vth_sensitivity equals 1. | [Receiver Thresholds] Vth = 1.0v Vth_sensitivity = 1 Input_Ref_Supply = EXT Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | variable typ min max [External Reference] 1.0v 0.95v 1.05v | --------------------------------------------------------------- (1) Set up Model Spec with "shift opposite" tolerances, but keep Vinh, Vinl differences, but with the [External Reference] changes. [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.20 1.25 1.15 Vinh 1.10 1.15 1.05 | Vth 1.0 1.05 0.95 Vinl 0.90 0.95 0.85 Vinl_ac 1.80 0.85 0.75 | (2) Set up Model Spec with "shift with" tolerances, but keep Vinh, Vinl differences but with the [External Reference] changes. [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.20 1.15 1.25 Vinh 1.10 1.05 1.15 | Vth 1.0 0.95 1.05 Vinl 0.90 0.85 0.95 Vinl_ac 1.80 0.75 0.85 | (3) Set up Model Spec with worst case tolerances, but do not keep Vinh, Vinl differences. The [External Reference] variations are added to Vinh and subtracted from Vinl values. [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.25 NA NA Vinh 1.15 NA NA | Vth 1.0 NA NA Vinl 0.85 NA NA Vinl_ac 0.75 NA NA | --------------------------------------------------------------- | A fully specified single ended 3.3v CMOS receiver | Vth = 1.5v Vth_min = 1.45v Vth_max = 1.53v Vth_sensitivity = 0.45 Input_Ref_Supply = VOLTAGE_RANGE Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | --------------------------------------------------------------- (1) Set up Model Spec with "shift opposite" tolerances, of Vth_min and Vth_max. Vth_max of 0.03 added to min column values, Vth_min of 0.05 subtracted from max column values. Keep Vinh, Vinl differences. | variable typ min max [Voltage Range] 3.3V 3.0V 3.6V | [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.7 1.538 1.830 Vinh 1.6 1.468 1.730 | Vth 1.5 1.365 1.635 | without | Vth_min/max shift Vinl 1.4 1.268 1.530 Vinl_ac 1.3 1.168 1.430 | (2) Set up Model Spec with "shift with" tolerances, of Vth_min and Vth_max. Vth_max of 0.03 added to max column values, Vth_min of 0.05 subtracted from min column values. Keep Vinh, Vinl differences. [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.7 1.560 1.838 Vinh 1.6 1.460 1.738 | Vth 1.5 1.365 1.635 | without | Vth_min/max shift Vinl 1.4 1.260 1.538 Vinl_ac 1.3 1.160 1.438 | (3) Set up Model Spec with worst case Vinh and Vinl values without keeping Vinh, Vinl differences. [Model Spec] | Subparameter typ min max | | Thresholds | Vinh_ac 1.703 1.568 1.838 Vinh 1.603 1.468 1.738 | Vth 1.5 1.365 1.635 | without | Vth_min/max shift Vinl 1.395 1.260 1.530 Vinl_ac 1.295 1.160 1.430 | ------------------------------------------------------------------------- The [Model Spec] keyword could be used, but one of three interpretations might be needed. The (3) interpretation still retains the worst case conditions on both ends, but does not keep the specified Vinh to Vinl difference. The other shifts cases show some of the threshold shifts. Not all possible shifts are captured. The new Specification allows shifting based on INDEPENDENT Vth_min and Vth_max variations and also INDEPENDENT External Reference changes. While this may capture correctly all of the tolerence variations, it means that simulators would now have to program added tests. They might just go with (3) conditions anyway for conservative design, and look just at the failure cases in more detail. Bob Ross, Mentor Graphics From owner-ibis Wed Sep 22 08:37:17 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA19130; Wed, 22 Sep 1999 08:37:16 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA03586; Wed, 22 Sep 1999 08:36:39 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id IAA27768; Wed, 22 Sep 1999 08:36:37 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37E8F785.419987DC@mentor.com> Date: Wed, 22 Sep 1999 08:36:37 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org CC: bob_ross@mentorg.com Subject: IBIS Version 3.2 - ANSI/EIA-656-A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Cecilia Fleming of EIA has just informed me that ANSI has approved IBIS Version 3.2. The document now is designated: ANSI/EIA-656-A Congratulations to all who have worked hard over the years to initiate and consider the issues and to produce the document. Bob Ross Chair., EIA IBIS Open Forum Mentor Graphics From owner-ibis Wed Sep 22 08:59:20 1999 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA19207; Wed, 22 Sep 1999 08:59:20 -0700 (PDT) Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id IAA09585; Wed, 22 Sep 1999 08:59:13 -0700 (PDT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 22 Sep 1999 08:59:13 -0700 Message-ID: From: "Hobbs, Will" To: "'Bob Ross'" , ibis@eda.org, ibis-users@eda.org Subject: RE: IBIS Version 3.2 - ANSI/EIA-656-A Date: Wed, 22 Sep 1999 08:59:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Congratulations everyone, and thanks for all your hard work!! Will Hobbs Intel Corp. (and Former Chair-- that's an official position isn't it?) -----Original Message----- From: Bob Ross [mailto:bob_ross@mentorg.com] Sent: Wednesday, September 22, 1999 8:37 AM To: ibis@eda.org; ibis-users@eda.org Cc: bob_ross@mentorg.com Subject: IBIS Version 3.2 - ANSI/EIA-656-A To All: Cecilia Fleming of EIA has just informed me that ANSI has approved IBIS Version 3.2. The document now is designated: ANSI/EIA-656-A Congratulations to all who have worked hard over the years to initiate and consider the issues and to produce the document. Bob Ross Chair., EIA IBIS Open Forum Mentor Graphics From owner-ibis Wed Sep 22 17:02:43 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA20840 for ; Wed, 22 Sep 1999 17:02:43 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA19058; Wed, 22 Sep 1999 17:02:05 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA25466; Wed, 22 Sep 1999 17:02:03 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37E96DFC.5EE59223@mentor.com> Date: Wed, 22 Sep 1999 17:02:04 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: Unofficial IBIS tree for Version 3.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: An unofficial tree diagram for IBIS Version 3.2 has been uploaded as: http://www.eda.org/pub/ibis/ver3.2/tree3_2.txt Thanks to Michael Mirmak of Intel for extending and adding more detail to an older unofficial tree diagram for IBIS Version 3.0. Comments and corrections are welcome. This diagram may be updated. The older unofficial tree diagrams have been moved to the ver3.0 subdirectory. Bob Ross Mentor Graphics From owner-ibis Thu Sep 23 14:02:18 1999 Received: from ns2.us.dell.com (ns2.us.dell.com [143.166.82.252]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA27357; Thu, 23 Sep 1999 14:02:17 -0700 (PDT) From: Aubrey_Sparkman@Dell.com Received: from ausxc06.us.dell.com (ausxc06.us.dell.com [143.166.99.78]) by ns2.us.dell.com (8.8.5/DELL-INET-10-14-1997) with ESMTP id PAA19391; Thu, 23 Sep 1999 15:01:08 -0600 (GMT) Received: by ausxc06.us.dell.com with Internet Mail Service (5.5.2448.0) id ; Thu, 23 Sep 1999 15:59:13 -0500 Message-ID: <592744F5B558D21183E000A0C9C732C3024B1F07@ausxmbrh15.us.dell.com> To: kellee@hyperlynx.com, ibis-users@eda.org, mbflora@hyperlynx.com, bob_ross@mentorg.com, ibis@eda.org Subject: package and connector model questions Date: Thu, 23 Sep 1999 15:59:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF0606.7CA354B4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF0606.7CA354B4 Content-Type: text/plain; charset="iso-8859-1" Hello ibis-users. I am new to the discussion group -- joined the end of July. I have read through the Version 3.2 spec and the ibisConSpec documents and I have 2 questions. The first question has to do with Kellee's outstanding item below. I.E., why not use the RLC matrix description in section 7 on package modeling? I am not sure why Connector modeling isn't (or couldn't be) a subset of the package modeling spec. After all, a package is a connector that connects the silicon to a PCB....or socket, which is again another connector. And before someone comments "un-mated connector" I also wonder why I need the model for an unmated connector or a package out of the socket, etc. But there are some excellent modeling enhancements in the connector spec such as Begin/End_Cn_Swath. Great way to simplify what could be an unnecessarily large matrix. Can we put this in the package model section? At least where possible, let's keep (or copy) everything that is or could be the same. And I also like the ability to name and therefore have more than one RLC matrix. Which brings me to my second (and more important to me) question. As I read section 7 of Ver 3.2, I can have only one RLC matrix set. I can't put two RLC sets in series. Or, if I want to do distributed effects, I can do sections (a wire bond section, a trace section, a via section, another trace section, etc) but I can NOT have "trace to trace" coupling effects. And I can not connect several uncoupled sections to the single RLC matrix which would at least give me some coupling. Is this a correct statement of my options? I was hoping for the ability to connect more than one matrix in series. And since the point of having a matrix is the coupling, I was also looking for the typ, min, and max coupled matrix for L and C. Is this too much for one message? Thanks for your consideration and patience, Aubrey Sparkman Signal Integrity Aubrey_Sparkman@Dell.com (512) 723-3592 -----Original Message----- From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] Sent: Monday, August 23, 1999 12:56 PM To: ibis-users@eda.org; Matthew Flora Subject: Re: USB connector model Hi Ibisians, Matt, Matt thanks for giving the correct web address for the preliminary connector specification. FYI.. The only outstanding item in the connector specification is to agree on the wording of the RLC matrix description. I have asked several industry experts to write it and have not received one from anyone yet. If someone else out their would like to contribute a technically correct RLC matrix description that would allow someone "skilled in the art" to understand which type of RLC matrix is being used I am interested. If I end up with more than one I would be extremely happy. It must have a simple included example of both a physical cross section and the resulting matrices. Ideally it would explain things like what the diagonal is and why there are sometimes negative signs. When we receive this and the connector sub-group reviews it and accepts it I believe we are ready to give it to the IBIS group as a bird. At 10:28 AM 8/23/99 -0700, you wrote: >> Wilco Hamhuis writes: >> > I have two short questions: Is IBIS capable of describing a (coupled) >> > connector? Are there IBIS USB connector models available? I am currently >> > analysing a high speed board (app. 500 MHz) and I want to take the effect >of >> > connectors into account. >> >> There is an IBIS working group that has proposed an IBIS extension for >> connectors that supports coupling, but it has not yet become >> a part of the official standard. If you are interested, a copy of the >> proposal is on the Hyperlynx website at www.hyperlynx.com. As for your >> specific need, I am not aware of any IBIS USB connector models, but others >> may know of some. > >Actually, the proposed IBIS extension for connectors can best be found at: >ftp://ftp.eda.org/pub/ibis/connector/ > >Regards, >Matthew Flora >IBIS Open Forum Postmaster >(425) 869-2320 PH >(425) 881-1008 FAX >mbflora@hyperlynx.com >HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA > ------_=_NextPart_000_01BF0606.7CA354B4 Content-Type: application/octet-stream; name="Sparkman, Aubrey.vcf" Content-Disposition: attachment; filename="Sparkman, Aubrey.vcf" BEGIN:VCARD VERSION:2.1 N:Sparkman;Aubrey FN:Sparkman, Aubrey EMAIL;PREF;INTERNET:Aubrey_Sparkman@Dell.com REV:19990728T212924Z END:VCARD ------_=_NextPart_000_01BF0606.7CA354B4-- From owner-ibis Thu Sep 23 14:34:07 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA28431; Thu, 23 Sep 1999 14:34:07 -0700 (PDT) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id QAA01654; Thu, 23 Sep 1999 16:33:57 -0500 (CDT) Received: from unknown(150.150.15.100) by molexinc-bh.molex.com via smap (4.1) id xma001531; Thu, 23 Sep 99 16:33:32 -0500 Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 0004E6E0; Thu, 23 Sep 1999 16:34:30 -0500 Mime-Version: 1.0 Date: Thu, 23 Sep 1999 16:27:19 -0500 Message-ID: <0004E6E0.C21030@molex.com> Subject: RE: package and connector model questions To: Aubrey_Sparkman@dell.com, kellee@hyperlynx.com, ibis-users@eda.org, mbflora@hyperlynx.com, bob_ross@mentorg.com, ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Aubrey, There are rough drafts of this wording... created... They are now under review. These descriptions are really to describe the format of the values in the matrices (as related to the final simulation) I would suggest a review of the samples may assist in understanding the specification. Most (all?) of the points you bring up are covered in the specification... however... to implement this... a rather complex format was needed to be created. I think the examples may be helpful in clearing up the issues. As an off note.... the IBISCnn specification is not a part of the general IBIS v3.2 spec.... maaybe the next one??? I'll try to address your specific questions now... Re "unmated connector" Need these to represent connectors that are not mated but are still on the bus. For instance, an empty PCI slot in a PC. Re: "Part of Package Modeling Spec..." The package modeling spec does not have stubs, cascaded models, swath, other?? As such, instead, maybe packages could be represented by the connector spec. Re: "Trace to Trace Coupling Effects The off diagonals of the matrices take care of the coupling. The distributed effects are handled by the "cascaded sections". These cascaded sections also allow the series connection of SLMs and MLMs in series or as stubs in the same model. The "Sections" area of the specification allows the installation of as many matrices in a model as required.... These sections can then be hooked up in the "Begin_Connector" area. There are examples that contain multiple cascaded sections. Re: "Min / Max LC values" These values are typically very tightly controlled in the final assembled connector... More variability in LC is always in the process where the connector gets mounted to a board. (Solder hole fill, board warp, connector floating during a reflow, other..) Best Regards, Gus apanella@molex.com -----Original Message----- From: Aubrey_Sparkman@Dell.com Sent: Thursday, September 23, 1999 3:59 PM To: kellee@hyperlynx.com; ibis-users@eda.org; mbflora@hyperlynx.com; bob_ross@mentorg.com; ibis@eda.org Subject: package and connector model questions Hello ibis-users. I am new to the discussion group -- joined the end of July. I have read through the Version 3.2 spec and the ibisConSpec documents and I have 2 questions. The first question has to do with Kellee's outstanding item below. I.E., why not use the RLC matrix description in section 7 on package modeling? I am not sure why Connector modeling isn't (or couldn't be) a subset of the package modeling spec. After all, a package is a connector that connects the silicon to a PCB....or socket, which is again another connector. And before someone comments "un-mated connector" I also wonder why I need the model for an unmated connector or a package out of the socket, etc. But there are some excellent modeling enhancements in the connector spec such as Begin/End_Cn_Swath. Great way to simplify what could be an unnecessarily large matrix. Can we put this in the package model section? At least where possible, let's keep (or copy) everything that is or could be the same. And I also like the ability to name and therefore have more than one RLC matrix. Which brings me to my second (and more important to me) question. As I read section 7 of Ver 3.2, I can have only one RLC matrix set. I can't put two RLC sets in series. Or, if I want to do distributed effects, I can do sections (a wire bond section, a trace section, a via section, another trace section, etc) but I can NOT have "trace to trace" coupling effects. And I can not connect several uncoupled sections to the single RLC matrix which would at least give me some coupling. Is this a correct statement of my options? I was hoping for the ability to connect more than one matrix in series. And since the point of having a matrix is the coupling, I was also looking for the typ, min, and max coupled matrix for L and C. Is this too much for one message? Thanks for your consideration and patience, Aubrey Sparkman Signal Integrity Aubrey_Sparkman@Dell.com (512) 723-3592 -----Original Message----- From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] Sent: Monday, August 23, 1999 12:56 PM To: ibis-users@eda.org; Matthew Flora Subject: Re: USB connector model Hi Ibisians, Matt, Matt thanks for giving the correct web address for the preliminary connector specification. FYI.. The only outstanding item in the connector specification is to agree on the wording of the RLC matrix description. I have asked several industry experts to write it and have not received one from anyone yet. If someone else out their would like to contribute a technically correct RLC matrix description that would allow someone "skilled in the art" to understand which type of RLC matrix is being used I am interested. If I end up with more than one I would be extremely happy. It must have a simple included example of both a physical cross section and the resulting matrices. Ideally it would explain things like what the diagonal is and why there are sometimes negative signs. When we receive this and the connector sub-group reviews it and accepts it I believe we are ready to give it to the IBIS group as a bird. At 10:28 AM 8/23/99 -0700, you wrote: >> Wilco Hamhuis writes: >> > I have two short questions: Is IBIS capable of describing a (coupled) >> > connector? Are there IBIS USB connector models available? I am currently >> > analysing a high speed board (app. 500 MHz) and I want to take the effect >of >> > connectors into account. >> >> There is an IBIS working group that has proposed an IBIS extension for >> connectors that supports coupling, but it has not yet become >> a part of the official standard. If you are interested, a copy of the >> proposal is on the Hyperlynx website at www.hyperlynx.com. As for your >> specific need, I am not aware of any IBIS USB connector models, but others >> may know of some. > >Actually, the proposed IBIS extension for connectors can best be found at: >ftp://ftp.eda.org/pub/ibis/connector/ > >Regards, >Matthew Flora >IBIS Open Forum Postmaster >(425) 869-2320 PH >(425) 881-1008 FAX >mbflora@hyperlynx.com >HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA > From owner-ibis Fri Sep 24 00:15:07 1999 Received: from rgate.ricochet.net (rgate1.ricochet.net [204.179.143.6]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA01563; Fri, 24 Sep 1999 00:15:06 -0700 (PDT) Received: from hyperstar (mg-206253202-32.ricochet.net [206.253.202.32]) by rgate.ricochet.net (8.9.3/8.9.3) with SMTP id CAA07001; Fri, 24 Sep 1999 02:14:46 -0500 (CDT) Message-Id: <199909240714.CAA07001@rgate.ricochet.net> X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 23 Sep 1999 20:45:00 -0700 To: Aubrey_Sparkman@dell.com, kellee@hyperlynx.com, ibis-users@eda.org, mbflora@hyperlynx.com, bob_ross@mentorg.com, ibis@eda.org From: Kellee Crisafulli Subject: Re: package and connector model questions In-Reply-To: <592744F5B558D21183E000A0C9C732C3024B1F07@ausxmbrh15.us.del l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Aubrey all, At 03:59 PM 9/23/99 -0500, Aubrey_Sparkman@Dell.com wrote: >The first question has to do with Kellee's outstanding item below. I.E., >why not use the RLC matrix description in section 7 on package modeling? I >am not sure why Connector modeling isn't (or couldn't be) a subset of the >package modeling spec. After all, a package is a connector that connects >the silicon to a PCB....or socket, which is again another connector. And >before someone comments "un-mated connector" I also wonder why I need the >model for an unmated connector or a package out of the socket, etc. Wow good comments... here is some of our thinking but many more heads and ideas made these decisions than just mine. The connector group made several decisions up front: 1) The specification should be stand-alone to remove the overhead associated with the IBIS IC specification which is getting very complex. Several of the connector companies that were interested in using the connector specification expressed concern over the need to understand the full IBIS specification in order to make a connector model. 2) The matrix descriptions must be compatible with the IBIS .pkg specification. 3) The general syntax must be the same as the IBIS specification. 4) Some of the concepts needed for connectors were missing from the .pkg specification and were much easier to accomplish as a stand alone specification. You mentioned a few. The biggest concern I personally had is that since the specification was constrained to just connectors there was less disagreement over what and how to do it. We attempted this once before integrated in the main specification and the project failed. One of the reasons was difficulty getting agreement on how to proceed with various aspects. Another was different groups had different needs i.e. cables v.s. connectors. v.s. IC packages and that added another set of problems that caused disagreements. I do believe the connector specification concepts and keywords could be used to augment the .pkg model since the connector specification is mostly a super set and contains many improvements. The people in the connector group fully expected many of the features to migrate directly to the .pkg specification over time. We also have many other new features like support for .jpg images of the connector and web site and email paths that can be added directly into the file so a user can easily get the latest version model or contact the department that created the model. These features should probably migrated back into the IBIS IC specification. Can you image being able to access the correct web site by just clicking on your connector model picture. Or being able to email the correct department of the company that created the model by clicking on an email icon. way... cool. if the simulator folks pick up on it. I found it is often a mistake to try and make one size shoe fit everyone. If we can use the same shoe leather, laces and polish and manufacturing equipment we are doing very good. (i.e. the syntax is compatible and we could re-use the concepts and keywords directly). If the syntax is left compatible the simulators should have an easy time supporting either with the same code and parsers. >But there are some excellent modeling enhancements in the connector spec >such as Begin/End_Cn_Swath. Great way to simplify what could be an >unnecessarily large matrix. Can we put this in the package model section? >At least where possible, let's keep (or copy) everything that is or could be >the same. And I also like the ability to name and therefore have more than >one RLC matrix. Speaking for the connector sub group we appreciate the kind words . >Which brings me to my second (and more important to me) question. As I read >section 7 of Ver 3.2, I can have only one RLC matrix set. I can't put two >RLC sets in series. Or, if I want to do distributed effects, I can do >sections (a wire bond section, a trace section, a via section, another trace >section, etc) but I can NOT have "trace to trace" coupling effects. And I >can not connect several uncoupled sections to the single RLC matrix which >would at least give me some coupling. Is this a correct statement of my >options? >I was hoping for the ability to connect more than one matrix in series. >And since the point of having a matrix is the coupling, I was also looking >for the typ, min, and max coupled matrix for L and C. The connector specification allows for as many series matrices as you desire and the matrices may all be of different types. So the first matrix might be simple inductors to represent bond wires and then a series of diagonal matrices to represent transmission lines and then a series of full matrices to represent a coupled region. This method could be added to the .pkg file very easily if the IBIS group desired. I should be able to complete the final integration of feedback and release the connector specification to the full IBIS group very soon. We have received comments from the full group already at DesignCon 99 and we are hoping for rapid acceptance. I am only working 3 days a week so my schedule is limited and it is taking longer than I would like to complete. Hopefully within the next one to two weeks. best wishes... Kellee From owner-ibis Fri Sep 24 10:21:51 1999 Received: from mail.nesa.com (mail.nesa.com [204.240.29.34]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA07006; Fri, 24 Sep 1999 10:21:49 -0700 (PDT) Received: from porky (porky.nesa.com [204.240.29.45]) by mail.nesa.com (8.9.3/8.9.3) with SMTP id KAA23298; Fri, 24 Sep 1999 10:52:52 -0400 Message-Id: <3.0.5.32.19990924110012.0095b210@mail.nesa.com> X-Sender: breda@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Sep 1999 11:00:12 -0400 To: ibis-users@eda.org, ibis@eda.org From: Kathy Breda Subject: IBIS Summit - Thursday, 14-Oct-99 - AGENDA included Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS SUMMIT CALL FOR PARTICIPATION, PRESENTATIONS & SPONSORSHIP!!!! ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:30 AM - 5:00 PM, Thursday, October 14, 1999 Location: Marlboro Holiday Inn (NOT AT THE BOXBORO HOLIDAY INN THIS YEAR) 265 Lakeside Ave. Marlboro, MA Tel: (508) 481-3000 Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: North East Systems Associates, Inc. (NESA), Hyperlynx, Praegitzer Design we are looking for other sponsors! PCB Conference: October 11-15, 1999 East Royal Plaza Trade Center Marlborough, Massachusetts See http://www.pcbeast.com/ for more information. BACKGROUND The IBIS Users Group (IBIS East) has been formed under the leadership of Dr. Edward Sayre from North East Systems Associates (NESA) and has been meeting for a year to consider and forward IBIS model user concerns. As a result of regular East coast meetings, the group has developed an IBIS Accuracy Specification document and has helped move forward work on formatting Connector Models. These topics plus others of current interest to the EIA IBIS Open Forum will be discussed at this meeting. This meeting will be conducted as a formal IBIS Summit meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. If you are interested in attending, please send e-mail to Kathy Breda (breda@nesa.com) AGENDA Morning Sessions Focused on Round-Table, Open Discussions: Intro and Business Bob Ross / Ed Sayre Accuracy Specification Lead by Bob Haller Break Connector Specification Discussion leader TBD SPICE to IBIS Discussion Discussion leader TBD Lunch Afternoon Sessions Focused on Presentation Topics: Round Table Discussion: Input Modeling Discussion, Discussion leader TBD "Model Design: Tables and Equations" - Lynne Green, Hyperlynx Break (Sponsored by Praegitzer Design) "Model Extraction Based on Differential TDR" - Dima Smolyansky or Steven Cory, TDA Systems We have time for one more presentation! Contact Kathy Breda (breda@nesa.com) if you are interested Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by October 8, 1999. Otherwise the presenters will be expected to provide 50 copies for distribution. **************************************************************************** DIRECTIONS TO MEETING The Marlboro Holiday Inn is located at the junction of Route 20 and I-495 (exit 24A off I-495 North or South) Located 4 miles from the Massachusetts Turnpike and One Mile from I-290. Thirty miles from Boston and Logan International Airport **************************************************************************** LIST OF NEARBY HOTELS Marlboro Holiday Inn 265 Lakeside Ave. Marlboro, MA Tel: (508)481-3000 Boxboro Holiday Inn. One Adams Place Boxboro, MA Tel: (978) 263-8701 Fax: (978) 263-0518 Royal Plaza Hotel 181 Boston Post road West Marlborough, MA 01752 Tel: (508) 460-0700 Radisson Inn 75 Felton St. Marlboro, MA Tel: (508) 480-0015 Embassy Suites Hotels 123 Boston Post Rd. West Marlboro, MA (508) 485-5900 Amerscot House 61 West Acton Road Stow, MA 01775 email: doreen@amerscot.com, web site http://www.amerscot.com Tel: (508)897-0666, FAX (508)897-6914 Westford Regency Inn 219 Littleton Rd. (exit 32 off I-495) Westford, MA Tel: (978) 692-8200 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Kathy Breda e-mail: breda@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.978.897-8787 | | Stow, MA 01775 USA Fax +1.978.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Fri Sep 24 12:04:12 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA07600 for ; Fri, 24 Sep 1999 12:04:11 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA27885; Fri, 24 Sep 1999 12:03:34 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id MAA14629; Fri, 24 Sep 1999 12:03:32 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37EBCB05.2F0CB2D0@mentor.com> Date: Fri, 24 Sep 1999 12:03:33 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Hobbs, Will" , ibis@eda.org Subject: IBIS: Re: Food for thought References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Will: It has been a while since issued this email. We have been mentioning the possibility of an API (application program interface) for several years as a possible IBIS enhancement. Adopting an API for IBIS represents a fundamental shift in IBIS. However, it may be necessary, as you discuss, to provide: (a) accurate information in a timely manner, (b) with a standardized interface format (c) without requiring revealing proprietary details These are consistent with IBIS goals. Here are some questions I have that come from your initial discussion: (1) What is the scope of the compiled model? You mention that it might be the structural model compiled with a public domain Spice. Could that mean that a public domain Spice (such as a version of Berkeley Spice is included? Or an internal proprietary Spice engine set up for processing only that model? Or a commercial Spice (which I doubt you will be able to distribute)?. Or are only the structural model itself plus API? Or does the execution engine such as a Vendor-specific Spice neeed to be supplied separately? (2) How simple can the API be for it still to be useful? Upon investigation, it might have to return at each time step all of the voltages and currents at each node. I presume the API would connect at the buffer or differential buffer level to capture properly the buffer interaction. A number of such buffers could be connected for SSO analysis externally. The package model description would probably be outside such an API. (3) Some other details of the API might need to be considered. Would extra connection parameters be needed for additions such as external reference voltages, inputs for outputs, or test point nodes? You raise some good points about the advantages and disadvantages of an API. After more discussion I think we will be ready for some specific proposals. Bob Ross Mentor Graphics Hobbs, Will wrote: > > IBISers, > > Food for thought: > > For years, naysayers have said that IBIS was fine for some > things, but with newer, higher speed and new buffer innovations, > IBIS wasn't going to be sufficient. They made that claim when we > went from 50 MHz to 66, and again from 66 to 100, and so on. For > years, we've proven the naysayers wrong. One of the ways we've > done so has been to improve IBIS over time, adding features to > support emerging needs, addressing subtler effects, etc. I won't > itemize the improvements here-- just look at the deltas from IBIS > 1.1 to 2.1 to 3.2, and at the current work going on to get an > idea of the progression. > > Nonetheless, IBIS still lags some of the leading edge needs, and, > as with any living standard, will probably always lag in one area > or another. In addition, there are some nagging problems we still > haven't addressed satisfactorily, even though we've faced them > for years-- SSO comes to mind. > > I would like to propose a way to satisfy emerging needs in a more > timely way: Define an API that would allow structural models, > compiled with execution engines (such as public domain Spice > variants) to interface to behavioral simulators. The API would be > a C-based procedural interface that would handle passing of data > back and forth between the IBIS simulation and the self-contained > compiled model. > > The resulting simulation would be slow and big, but the model > developer could have the freedom to include support for power and > ground routing, and whatever other details that (s)he deemed > necessary for accurate simulation not available in the current > IBIS version. > > Meanwhile, IBIS can continue to address these emerging needs, > making each successive generation's structural models > unnecessary, at least until the next problem not addressed by > IBIS became critical. Then this "escape" mechanism would still be > available, and customers wouldn't have to run separate > simulations for their unique structural models and their > behavioral models. > > IP concerns could be dealt with through the compilation process, > which could easily be obfuscated or encrypted enough to hide > structural and process details. > > I suspect such an API could be fairly simple. For example, it > would have to support a pin list, some initialization information > passing, voltage and time-step information. There is probably > additional data that would have to cross the simulator/model > boundary, which would go into the API definition-- not sure what > all that would be. > > Should this be part of IBIS? I think so, but am open to other > opinions. At the very least, I believe this body has the right > constituency to take this on if anyone agrees with this > suggestion. > > I realize that such an API could have a detrimental effect, in > addition to its positive one. If the API were to exist, it might > remove some of the incentive for enhancing IBIS. However, the > speed of execution issue alone would probably keep IBIS moving > forward. There would also be the problem that an executable model > would have to be re-compiled and re-validated for each specific > platform it had to run on-- not an insurmountable problem, but > one which IBIS doesn't have. I think IBIS would continue to > mature for these reasons. > > This API might even offer a way to allow IMIC and IBIS to inter- > operate-- I haven't given that much thought yet. > > Comments? > > Will From owner-ibis Fri Sep 24 13:22:03 1999 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA07785; Fri, 24 Sep 1999 13:22:03 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA07374; Fri, 24 Sep 1999 13:21:54 -0700 (PDT) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id NAA13181; Fri, 24 Sep 1999 13:21:54 -0700 (PDT) Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA09225; Fri, 24 Sep 1999 13:21:53 -0700 (PDT) Message-Id: <199909242021.NAA09225@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: Aubrey_Sparkman@dell.com, ibis-users@eda.org, ibis@eda.org Subject: Re: package and connector model questions In-reply-to: Your message of "Thu, 23 Sep 1999 20:45:00 PDT." <199909240714.CAA07001@rgate.ricochet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Sep 1999 13:21:52 -0700 From: Stephen Peters Hello Kellie, Aurbey, all: > At 03:59 PM 9/23/99 -0500, Aubrey_Sparkman@Dell.com wrote: > >The first question has to do with Kellee's outstanding item below. I.E., > >why not use the RLC matrix description in section 7 on package modeling? I > >am not sure why Connector modeling isn't (or couldn't be) a subset of the > >package modeling spec. After all, a package is a connector that connects > >the silicon to a PCB....or socket, which is again another connector. And > >before someone comments "un-mated connector" I also wonder why I need the > >model for an unmated connector or a package out of the socket, etc. > As one of the authors of the .pkg extensions, I'd like to add a comment. It is tempting to think of an IC package as 'just another type of connector', but in reality an IC package is much closer to a circuit board than a connector. In fact, for many of the high performance products I've seen, the package IS a circuit board, complete with edge fingers or pins to connect it to a mother board. The problem is that when trying to create an electrical description of this type of package you're not dealing with a group of parallel pins of equal length. You've got *traces* that have different lengths, diverge, switch layers, who knows what else. To model the coupling requires having many small matrixes that are named or somehow interrelated. After we played with it for a while we realized that 1) Even if we could agree on a description no one is going to create such a data base by hand and 2) it's a problem the CAE companies have already solved by integrating PCB extraction with! ! their SI tools. Thus, we settled on what we could achieve -- a simpler uncoupled description. As Kellie mentioned, I do expect that some of the extensions the connector group has come up with will find there way into the .pkg section. But I suspect other approach will be needed before IBIS will support full coupled package models. Regards, Stephen Peters Intel Corp. From owner-ibis Fri Sep 24 14:51:48 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA08117 for ; Fri, 24 Sep 1999 14:51:48 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA12156; Fri, 24 Sep 1999 14:51:10 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA11784; Fri, 24 Sep 1999 14:51:10 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37EBF24E.24D3453F@mentor.com> Date: Fri, 24 Sep 1999 14:51:10 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Agenda for 10/1/99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 10/1/99 Bridge Number Reservation # Passcode (916) 356-9200 8-40171 4196281 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 2.1) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - 93/67/NP IBIS and EMC Simulation Perrin - JEDEC JC-16.2 Modeling and Testing Sessions ANSI/EIA-656-A Update Ross/Fleming - Press Release - Forward to IEC IBIS (East) Users Group Meetings Haller IBIS Summit October 14, 1999 Ross - Attendence, Sponsorship S2ibis3 Committee Activities Cohen IBIS Dues and Funding Ross Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:00 Technical Discussion IBISCHK3 Bug Status and Plan Ross/Flora/Rokusek - BUG34 - No Error Reported for Missing V/I Tables in Output Buffers - BUG36 - Reserve Words Error for Pin Mapping and Series Pin Mapping - BUG37 - Pin Mapping for Unique GND or POWER Pin Generates Error BIRD61 - Enhanced Characterization of Receivers Peters BIRD62 - Enhanced Chararcterization of Receiver Peters Thresholds BIRD63 - Documentation of Receiver Setup and Hold Peters Timing Conditions API Discussion Peters Connector Proposal Status Flora New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Sun Sep 26 12:49:59 1999 Received: from hotmail.com (law-f214.hotmail.com [209.185.130.124]) by server.eda.org (8.8.5/8.8.3) with SMTP id MAA16469 for ; Sun, 26 Sep 1999 12:49:58 -0700 (PDT) Received: (qmail 46894 invoked by uid 0); 26 Sep 1999 19:49:20 -0000 Message-ID: <19990926194920.46893.qmail@hotmail.com> Received: from 210.56.13.16 by www.hotmail.com with HTTP; Sun, 26 Sep 1999 12:49:20 PDT X-Originating-IP: [210.56.13.16] From: "wamiq ahmed" To: ibis@eda.org Subject: simulation of mc13175, mc2833 and mc3356 Date: Sun, 26 Sep 1999 12:49:20 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed I am an ee senior student working on my ee senior project. I need some software tool for the simulations of the mc 13176, mc2833 and mc3356 ic's. I would be pleased and highly obliged if some one could help me regarding that. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Wed Sep 29 08:39:17 1999 Received: from mud.ssec.honeywell.com (mud.ssec.honeywell.com [129.30.62.69]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05163 for ; Wed, 29 Sep 1999 08:39:17 -0700 (PDT) Received: (from brand@localhost) by mud.ssec.honeywell.com (8.8.6 (PHNE_14041)/8.7.1) id KAA29823 for ibis@eda.org; Wed, 29 Sep 1999 10:38:36 -0500 (CDT) Date: Wed, 29 Sep 1999 10:38:36 -0500 (CDT) From: Dave Brand Message-Id: <199909291538.KAA29823@mud.ssec.honeywell.com> To: ibis@eda.org Subject: Can I change the | variable typ min max line to: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-MD5: XsMTdcfUIR3RSEChhVlfkw== [Package] | variable typ max min ??? Evidently when we first started creating MOSFET IBIS models, they were done "incorrectly" as the min column got the fastest model, highest voltage, lowest temp, lightest load, etc. and the max got the opposite. I think I will redo several scripts to fix the problem, but I was wondering if the top syntax is allowed, maybe I could just swap the min and max entries on the line above. Is this OK to do or am I just creating more problems? Thanks in advance, please reply to the group or to: brand@ssec.honeywell.com Dave Brand From owner-ibis Wed Sep 29 09:28:38 1999 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA05370 for ; Wed, 29 Sep 1999 09:28:38 -0700 (PDT) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id JAA08723; Wed, 29 Sep 1999 09:27:58 -0700 (PDT) Message-Id: <199909291627.JAA08723@jasper.cisco.com> Date: Wed, 29 Sep 1999 09:27:58 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: Re: Can I change the | variable typ min max line to: To: ibis@eda.org, brand@ssec.honeywell.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Vtrdpc/l5XCypk/gUGekiQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Dave, I think your best bet would be to swap the columns such that it follows the 'typ min max' format. Regards, Syed Cisco Systems, Inc > > [Package] > | variable typ max min ??? > > Evidently when we first started creating MOSFET > IBIS models, they were done "incorrectly" as the > min column got the fastest model, highest voltage, > lowest temp, lightest load, etc. and the max > got the opposite. > > I think I will redo several scripts to fix > the problem, but I was wondering if the top > syntax is allowed, maybe I could just swap > the min and max entries on the line above. > > Is this OK to do or am I just creating more problems? > > Thanks in advance, please reply to the group or to: > > brand@ssec.honeywell.com > > Dave Brand From owner-ibis Thu Sep 30 10:32:30 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA15078 for ; Thu, 30 Sep 1999 10:32:30 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA08041; Thu, 30 Sep 1999 10:31:50 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA03090; Thu, 30 Sep 1999 10:31:48 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37F39E86.F1B15420@mentor.com> Date: Thu, 30 Sep 1999 10:31:50 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Dues Discussion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee Members: In preparation for the IBIS Budget Discussion at the October 1, 1999 IBIS Meeting, here is some raw data. Some of the numbers have been adjusted. The table shows that based on the current membership dues structure, we should be collecting about $15,000 per year, but need to pay EIA about $22,000 for the services provided. We need to make and discuss some proposals. Bob Ross Mentor Graphics EIA Electronic Industries Alliance EIG Electrical Information Group DAD Design Automation Division IBIS EIA IBIS Open Forum INCOME IBIS Membership Dues $15,000 Fees & Assessments Used only for Direct Expenses EXPENSES Basis: ------------------------------ IBIS EIG DAD EIA Direct Budget Budget Budget Alloc. Expense Salaries and Benefits $9,000 5% Interest Expense Not Allocated Occupancy 610 5% Bad debts Not Allocated Depreciation 250 5% Printing 200 20% Postage 300 20% Freight & Delivery 100 20% Travel & Entertainment 1,400 20% Telephone 200 20% Meetings and Conference Exp. 2,400 20% Professional Services X Memberships & Subscriptions Not Allocated Web Site Services Not Allocated Advertising & Promotions 1,000 20% Show Expenses (Deleted) Office Supplies & Misc. 100 20% ------- Total Exp. Before Corp. Alloc. 15,560 Corporate EIA 6,200 X ------- Total IBIS Budget $21,760