From owner-ibis Mon Apr 1 07:59:07 1996 Received: from emout10.mail.aol.com (emout10.mx.aol.com [198.81.11.25]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA27490 for ; Mon, 1 Apr 1996 07:59:06 -0800 (PST) From: Powelljon@aol.com Received: by emout10.mail.aol.com (8.6.12/8.6.12) id KAA06503 for ibis@vhdl.org; Mon, 1 Apr 1996 10:49:44 -0500 Date: Mon, 1 Apr 1996 10:49:44 -0500 Message-ID: <960401104937_182446971@emout10.mail.aol.com> To: ibis@vhdl.org Subject: Deadline for DAC logos I will be doing all of the work for the DAC logos the first week in May. I must have usefull art by that time. The best format to transmit if GIF BMP or TIF. Send it high resolution so I can make it the right size for the poster etc. take care, jon From owner-ibis Mon Apr 1 09:14:30 1996 Received: from gatekeeper.nsc.com (gatekeeper.nsc.com [139.187.71.2]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA28314 for ; Mon, 1 Apr 1996 09:14:29 -0800 (PST) Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA01401 for ibis@vhdl.org; Mon, 1 Apr 96 09:05:39 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA17726 for ibis@vhdl.org; Mon, 1 Apr 96 09:05:35 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA20693; Mon, 1 Apr 96 09:07:55 PST Date: Mon, 1 Apr 96 09:07:55 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9604011707.AA20693@rockie.nsc.com> To: ibis@vhdl.org Subject: National releases LAN IBIS model Cc: huq@rockie.nsc.com IBIS fans, National Semiconductor has released the following LAN IBIS model today. This is available from our web site at: http://www.national.com dp83840.ibs 10/100 Mb/s Ethernet Physical Layer National Semiconductor provides IBISv1.1 and IBISv2.1 models from selected product lines. Refer to www.national.com for the lastest available models. National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. Regards, Syed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Syed B. Huq huq@rockie.nsc.com ~ ~ National Semiconductor Corp. ~ ~ Tel:(408)721-4874; Fax:(408)721-4785 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ibis Tue Apr 2 13:04:35 1996 Received: from mail06.mail.aol.com (mail06.mail.aol.com [152.163.172.108]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA19008 for ; Tue, 2 Apr 1996 13:04:34 -0800 (PST) From: Powelljon@aol.com Received: by mail06.mail.aol.com (8.6.12/8.6.12) id PAA11374 for ibis@vhdl.org; Tue, 2 Apr 1996 15:55:15 -0500 Date: Tue, 2 Apr 1996 15:55:15 -0500 Message-ID: <960402155515_460765291@mail06> To: ibis@vhdl.org Subject: DAC logo confusion My message the other day seems to have been more confusing than helpful. Let me clarify some: There are actually two projects that I am working on. One is representation of IBIS in the EIA booth. This was what the 8.5X11 logos with velcro backing were for (though this may change, I am working with patty). The other is a general purpose poster that I was going to make that we would post around to advertize our birds of a feather or whatever. For this I need computer art (which I already have from most people). I will post more info on these requirements as I know them. The eia situation is still developing. take care, jon From owner-ibis Tue Apr 2 16:18:07 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA20317 for ; Tue, 2 Apr 1996 16:17:54 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 2 Apr 96 16:08 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 2 Apr 96 16:11 PST Message-Id: Date: Tue, 2 Apr 96 16:11 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 3/29/96 DATE: April 2, 1996 SUBJECT: 3/29/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann* Cadence Design C. Kumar* Contec CAE, Ltd. Dileep Divekar, Norio Matsui Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, Donald Telian, Jim Kruchowski Interconnectix, Inc. Bob Ross* Meta-Software (Les Spruiell) Mitsubushi Tam Cao Motorola Ahmed Omer* National Semiconductor Syed Huq*, Donald Snyder, Chune-Sin Yeh NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell, Chris Rokusek* Quantic Labs (Mike Ventham) Tanner Research, Inc. (Scott Wedge) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia* VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu* EIA Patti Rusher* IC Works Eric Chen Micron Technology Brian Johnson MicroSim Ralph Perez North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Rockwell Collins Thomas Thurman* S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison Veribest/Integraph Ian Dodd*, David Wiens Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 4/19/96 (916) 356-9200 2-66106 5576848 5/10/96 (916) 356-9200 2-66109 4323275 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 Ahmed Omer of Motorola in Austin, Texas joined primarily as "customer" of IBIS models. He is in a technology group within a semiconductor division and is involved in interconnect software issues as related to packages and boards. He is also interested in more Motorola internal visibility and involvement with IBIS. Tom Thurman from Rockwell Collins Avionics and Communications Division joined us at 9:00 AM. He introduced himself as the author of the ISO STEP AP210 (Electrical System Modeling) standard and a participant in the board layout/ standardization field for many years. He then presented an overview on Express. This discussion is captured in the technical section below. EIA MEMBERSHIP AND TREASURER'S REPORT Patti Rusher reported that Cypress Semiconductor is now a full EIA/IBIS Member. IBM (Austin) has decided not to renew the EIA membership. Patti reaffirmed that AMP is a full IBIS member. Jeff Chu of Digital Equipment and Ian Dodd of Veribest both indicated that they need the membership information for joining. No treasurer's report was given. MINUTES REPORT, MISC. Bob Ross reported that all AR's have been done, including inviting Tom Thurman for later discussions. MISCELLANY/ANNOUNCEMENTS Patti Rusher reported that EDIF 3 9 9 is undergoing formal letter ballot review prior to adoption as EDIF 4 0 0. She also mentioned that she was pleased to see the IBIS Spoken Here signs at the PCB Design Conference. PRESS AND WEB PAGE UPDATES In EDN, March 14, 1996, pg. 22 and EDN, March 28, 1996, pg. 87. both have new EDA tools introduction articles with abundant references to IBIS. AR - Patti Rusher on behalf of EIA write EDN that contrary to the March 28, 1996 article, IBIS has been formally ratified as an ANSI and EIA standard. NEW MODELS Bob Ross reports that VLSI has submitted a directory Michael Steer, although it has not been posted on vhdl.org yet. As reported last time, the models will still be available by sending a request to ibismodel@tempe.vlsi.com OPENS FOR NEW ISSUES Proposal for Encouraging more Semiconductor Model development from Syed Huq. EIA/IBIS 1996 MEMBERSHIP Bob Ross has sent reminders to members for paying fees. All have responded including some stating that fees have been paid. AR - Bob Ross continue working with Patti Rusher to monitor the payment for official EIA/IBIS Committee Membership. DAC STANDARDS BOOTH Patti Rusher stated that six committees will participate the DAC standards booth including EDIF and IBIS. The IBIS Committee cost will be $2500. There will be a back lit logo for EIA/IBIS. Because of uniformity in the booth the Velcro backed Company Logo board may have to be revised. She will work with Jon Powell concerning details. She can work with the logos in .gif format. Literature can be made available at the booth. Patti requested a poster briefly describing IBIS with about 10 bullet items. AR - Bob Ross work with Will Hobbs to prepare the list and give to Patti by Friday, April 5. Will Hobbs stated that "I Speak IBIS" badges will be provided by Jon Powell for DAC. One suggestion was "I Like IBIS" which brought memories of an old presidential campaign. ANSI/EIA-656 PUBLICATION Published version of the EIA/IBIS-656 have been mailed to members. The standard will also available through Global Engineering Documents. EIA WEB UPDATE Syed Huq reported that the EIA/IBIS home page has been updated with logo additions/changes including some new home page links with NCR (from AT&T), INCASES, Cadence, and Texas Instruments. Information from VLSI has not been received yet. Again Syed thanks EIA for their support. GOLDEN PARSER UPDATE Arpad Muranyi stated that Paul Munsey will drop off the updated IBISCHK2 parser disks which have 4 corrections documented under /pub/ibis/bugs on vhdl.org. Paul Munsey is to send the bill to EIA which we assume will be nominal. While the changes involved corrections and one very minor enhancement, ample review time has passed that we feel appropriate to provide reasonable compensation for such updates which involve enhancements since expenses are involved even for minor changes. This will be Version 2.1.11. AR - Bob Ross provide Will Hobbs a list of Version 2 Parser owners to check his list. - [Done] Will Hobbs will distribute the Parser. Jon Powell will need to create new executables, and Bob Ross will then put them on vhdl.org. SPICE TO IBIS VERSION 1.3 Bob Ross indicates that Steve Lipa has prepared a correction s2ibis Version 1.3 to be put on vhdl.org. Either Michael Steer will post it, or Bob Ross will post it if Michael is unavailable. The correction fixes a double counting problem in the [Pullup] table clamping region. SPICE TO IBIS VERSION 2.1 Bob Ross reported that the author at North Carolina State University Alan Glaser is studying for Ph.D. qualification exams and will be available for work after that in say a month. While problems have been reported directly, a list needs to be generated for visibility of what problems exist. Bob indicated that some "crashes" have been sent directly. Also there are some enhancements required consistent with the s2ibis version 1.3 coded that would differentiate an input voltage signal values and input threshold values. Currently [Vinl] and [Vinh] commands set both in s2ibis Beta Version 2.091, and this is wrong. AR - Bob Ross will prepare a list as soon as possible of s2ibis version 2.091 bugs. PLAN TO ENCOURAGE SEMICONDUCTOR MODELS Syed proposed a Most Models for the Year Reward to encourage publicly available IBIS Models to be given at DAC. Questions concerned whether those under NDA and those available through e-mail to the corporations that are free could be included. The award would be given at DAC where the participants would be available for presentation of the award. An awards committee might opt at this time anyone who is putting models on vhdl.org or in a publicly accessible Web site. Arpad Muranyi was concerned that small glue logic models might inflate the numbers versus larger pin count processor models. Bob Ross suggested that perhaps the focus of the award would be to the company rather than the individual to encourage and acknowledge company commitment. AR - Bob Ross put this as an agenda item for the April, 1996 meeting, and also plan that the award should be resolved by the May, 1996 meeting. Patti Rusher can help prepare the rewards. PRIORITIES FOR 1996 Will Hobbs reported the priorities that were established by a committee within Intel that relate to IBIS changes. They consist of Diode Kickback Feedback Sequential Drivers Voltage and Temperature parameterization Cookbook Update, particularly on DC versus AC impedance Improved Packaging Package Parasitics IBIS Models production (Intel has many IBIS model as a result of making it a procurement requirement) Ground Bounce/SSO/Scaling of Drivers/Multiple Outputs related Issues Will indicated that this list initiated by the Platform Architecture Lab closely resembled the IBIS committee priorities. TUTORIAL Patti Rusher stated that EDIF World was planning a tutorial in Monterey, California later this year and wondered if IBIS would also be interested in presenting a tutorial. EXPRESS Tom Thurman, from a Rockwell Collins Division in Cedar Rapids, Iowa has been involved with standards activities including information and data modeling. One piece of this work is Express. The Express format has been adopted internationally and nationally by EIA, EDIF and CFI. It is a more precise representation than English. Tom's feedback on fast tracking the IBIS proposal is that it should have an Express representation for better, more thorough review. The goals of the Express representation are 1) to make the language easy to understand, and 2) to design a language that can be interpreted and processed by a computer. There exists a graphical form called Express-G which helps newcomers become familiar with a new specification more easily. It is easy to create a lexical form from a graphical form and visa-versa. Once the Express representation is in place, it is easy to expand the scope of the specification and to show its interaction with other specifications. This helps attain the goal of cohesive standards. Express has the concept of base types (reals, integers, logicals), but is not concerned with specific computer implementations such as 32 bits, 64 bits, etc. It is similar to object orientated languages. In EDIF, there is a separate section for syntax guidance. The Express entity is similar to a C++ class, e.g., each having analogous attributes. Express-G shows relationships with boxes and lines. It provides a conceptual data model. It is a static data modeling language. Process and evens are not currently included. The relationships are object to object. Express lends itself to modular decomposition. In response to questions by Stephen Peters, Will Hobbs, Ian Dodd, C. Kumar, and others, Tom described Express as not a BNF or syntax description, but one that describes relationships. It was initially aimed at describing industrial data. He estimates 400-500 users in industry and academia including being taught at Clemson and UCLA. It has been adopted as the representation of EDIF 4 0 0. Express is still suitable for the non-syntactical aspects of IBIS and would not undermine the widespread acceptance of the current IBIS syntax. It provides the structure of the model and the rules and behavior of the data. Some constraints could also be included. The golden parser itself could be described using Express. Express provides an unambiguous description and also provides a method of communicating with parallel standards. Since Express is used as a representation in EDIF 4 0 0, Patti Rusher was asked to provide a simple illustrative example. AR - Patti Rusher post a simple example of Express representation. Tom concluded that Express can be used to describe physical files and that IBIS did not appear to require a large data model. BIRD33 (EGG8) - PHYSICAL PACKAGE DISCUSSION Stephen Peters recounted the separate committee meetings. The members consist of Stephen, C. Kumar, Ian Dodd, David Wiens, Jon Powell, Kellee Crisafulli, Olaf Rethmeier, and Werner Rissiek. The 19 March meeting established the goals that the proposal be human readable, easily parseable, handle SIMMs, resistors and capacitors, and polygons. They converged on the conclusion that the specification should be an existing standard, if possible, and may be a subset. The proposed EDIF 4 0 0 appears to be a good candidate. They are looking into CAD vendors to see who is supporting EDIF 4 0 0. The physical specification would be most useful for SIMMs and MCMs. The electrical side has similar goals. They considered Kumar's Spice-like description, an extension to BIRD28.3 which considers named matrices and eliminates [Number of Sections], and another description presented by Jon Powell based on Quad Design's experiences. The electrical specification would be most useful for PGAs. The next meeting is scheduled on April 4, 1996. Hank Herrmann wants to join the subcommittee. BIRD31.1 - MATED MODELS Bob Ross discussed the key points of BIRD31.1. The mated model (a generic term covering connectors, cables and sockets having two terminals) is blended into the package model with BIRD28.3 extensions and will track any changes resulting from future package proposals. It differs in that it introduces optional Cpad_1 and Cpad_2 default capacitor subparameters since most connector model information does not assume a pad capacitance. It will have two columns of pin numbers instead of one in the package model to allow different naming conventions on each side and to allow simple cable crossover. Finally, it is always in a separate .mmf and would not be in a .ibs file since it would be difficult to track having the same model in several .ibs files. BIRD34.1 (EGG9) - HANDLING STORED CHARGE Not covered. EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING Not covered. NEXT MEETING: The next telephone meeting is set for Friday, April 19, 1996. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Server Chipset System Validation Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Wed Apr 3 07:34:56 1996 Received: from crimp.amp.com (crimp.amp.com [198.80.3.102]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA02993 for ; Wed, 3 Apr 1996 07:34:53 -0800 (PST) Message-Id: <199604031534.HAA02993@vhdl.vhdl.org> Received: by crimp.amp.com id AA11683 (InterLock SMTP Gateway 3.0 for ibis@vhdl.org); Wed, 3 Apr 1996 10:26:01 -0500 Received: by crimp.amp.com (Internal Mail Agent-1); Wed, 3 Apr 1996 10:26:01 -0500 From: Herrmann Hank To: IBIS Reflector Cc: Millard Steve , Schroeder Jim Subject: BIRD 31.1 Date: Wed, 03 Apr 96 10:21:00 E Encoding: 24 TEXT, 975 TEXT X-Mailer: Microsoft Mail V3.0 X-Ms-Attachment: Cmts_02_.00t 48752 04-03-1996 14:04 Bob Ross has done an excellent job of providing a connector/cable model structure proposal in BIRD31.1. I have greatly appreciated discussions with him on this subject and he has helped me gain a better understanding of the EDA world's problems. Having completed that first level of exchange with Bob, I think it is now appropriate to share what is left of my questions and comments with the full group. I hope that they spark further discussion that will help to bring significant advances to this IBIS modeling effort. I have attached the full text of BIRD 31.1 with my comments and questions inserted and marked off with ">>>" symbols so they are easy to find. Hank Herrmann Technical Staff Member AMP Incorporated, Electromagnetic Technology M.S. 106-14 P.O. Box 3608 Harrisburg, PA 17105-3608 Phone: 717-986-5534 FAX: 717-986-5643 INTERNET: hank.herrmann@amp.com [[ Cmts_02_00.txt : 2654 in Cmts_02_.00t ]] 3/28/96 Comments & Questions to BIRD 31.1 They are inserted in the text of the BIRD and are set off with ">>>>>>>>>>" symbols. ****************************************************************************** ****************************************************************************** BIRD ID#: 31.1 ISSUE TITLE: Mated Models REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 11/22/95, 3/18/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: No guidance is given within IBIS with respect to modeling connectors, cables and sockets used to connect boards to boards and boards to components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: "Mated model" text is blended within the original PACKAGE MODELING section, and the section is renamed as PACKAGE, CONNECTOR, CABLE AND SOCKET MODELS. The whole section is presented with BIRD28.3 extensions and additional changes noted by "|*" lines. (References to the "PACKAGE MODELING" section elsewhere would be changed to the new title. These are not shown.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > General Questions & Comments: > 1. The Minimum Edge Rate for a package, connector or cable model should be > specified as a required parameter. A required Keyword, such as > [Minimum Edge Rate], should be added. Eventually, simulators should > generate a warning message if faster signals are impinging on the model. > 2. The word "STUB" is used to mean a conductive or transmission path > through a model. Is that normal EDA / IC / IBIS terminology? It > is confusing to connector modelers because a "STUB" to us is a passive > tap off of a transmission path. The word "PATH" would be preferred. > 3. How can connections be established between pins and internal matrix > tie points? Transmission and shielded type connectors require them. > Shielded cables, and transmission paths over ground planes can also > require them. > 4. Un-mated connector models are not the same as a mated model that is > not connected to something. Empty sockets and un-used bus slots > present a reduced capacitance and there may be no significant > inductance. There are also backplane connectors that have pin fields > that penetrate through the PCB and provide a 'back panel connection > point'. They too, are often not connected. A much more simple single > sided model would be the preferred structure for such device models. > 5. This appears to describe an entire connector without the use of > reusable sub-matrixes. Is that correct? If so, is that really an > acceptable general solution? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |============================================================================= | |* PACKAGE, CONNECTOR, CABLE, AND SOCKET MODELING |* |* This section describes the [Define Package Model] syntax and its matrix, |* transmission line, and discrete element extension formats. This section |* also describes [Define Mated Model] as a generic class of I/O terminal |* extensions which can be used to describe the electrical characteristics |* of connectors, sockets, and cables. These can be referred to as "mated >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Where are the boundaries for a Package model? Do they extend to the end of > the pins or SMT legs or do they stop short somewhere? > A standard boundary should be established. We use the plane at the top of > the socket. We find that necessary because of the interaction of the IC > pin with the Socket Contacts when C & L parameters are extracted. It is > also a reasonable boundary, from the IC perspective, since it coincides > with the plane of a PCB surface. The IC pins always go into a PCB or into > a socket below that boundary. > It is also important to define boundaries for the .mmf models. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |* models" because the are used to provide the interconnection between circuit |* boards through connectors or cables, and also between boards and components |* through sockets. |* |* The electrical format for data is identical. Some operational details |* and syntax are noted. |* | The [Package Model] keyword is optional. If more than the default RLC |* package model is desired, use the [Define Package Model] keyword. There |* is no reference within the [Component] keyword to any connector model. |* The information within the [Define Mated Model] is available to |* simulators to define the interconnections using the simulator-specific |* syntax and interfaces. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... |* [End Package Model] keywords for each package model that is defined. |* However, the mated model keywords can exist only in a separate |* .mmf, and not in a .ibs or .pkg file. It exits |* between the [Define Mated Model] ... [End Mated Model] keywords for each |* connector that is defined. For reference, the keywords are listed |* below. Full descriptions follow. |* Simulators that do not support these keywords will ignore all entries between |* the [Define Package Model] and [End Package Model] keywords or between the |* [Define Mated Model] and [End Connector Model] keywords. |* | |* [Define Package Model] Required if the [Package Model] keyword is used |* [Define Mated Model] (note 3) | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) |** BIRD28.3 ADDITION BELOW |** [Number of Sections] (optional) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) |* [Model Data] (note 4) |* [Resistance Matrix] (note 4, optional) |* [Inductance Matrix] (note 4) |* [Capacitance Matrix] (note 4) |* [Bandwidth] (note 4, required for Banded_matrix matrices only) |* [Row] (note 4) |* [End Model Data] (note 4) |* [End Package Model] (note 2) |* [End Mated Model] (note 3) | |* (note 1) Required when the [Define Package Model] or [Define Mated Model] |* keyword is used |* (note 2) Required for ending a package model definition |* (note 3) Required for beginning and ending a mated model definition |* (note 4) Used only when the [Model Data] ... [End Model Data] is used |* | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | |* USAGE RULES FOR THE .PKG AND .MMF FILES | | Package models are stored in a file whose name looks like: | .pkg. |* |* Mated models are stored in a file whose name looks like: | .mmf. | | The provided must adhere to the General Syntax Rules. Use the |* ".pkg" extension to identify files containing package models. Use the |* ".mmf" extension to identify files containing mated models. The .pkg and |* .mmf files | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment Char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg |* or .mmf files. The .pkg file is for package models only. The .mmf file |* is used for mated models only. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > There could be several reasons not to exclude these sections. How can we > add additional connections (See comments under Keyword: [Pin Numbers]) or > additional components like capacitor filters, ESD clamps and even active > devices, to our connector models? We do manufacture connectors that > contain such devices. Maybe this makes this .mmf a .ibs for those kinds > of devices but since you separated active device models (.ibs) and passive > device models (.pkg & .mmf) I need to understand the reasons and consider > all of the implications. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > It should be clarified that there is also an [End Define Package Model] > keyword. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |*============================================================================= |* Keyword: [Define Mated Model] |* Required: Yes |* Sub-params: Cpad_1, Cpad_2 |* Description: Marks the beginning of a mated model description. |* Usage Rules: If the .mmf file contains data for more than one mated model, |* each section must begin with a new [Define Mated Model] |* keyword. The length of the mated model name must not |* exceed 40 characters in length. Blank characters are |* allowed. |* |* The Cpad_1 and Cpad_2 subparameters are optional and define |* default pad capacitances at sides 1 and 2 of the mated model. |* The values default to 0 pF if omitted. However, in all case |* the simulator may override the default values based on |* actual geometrical pad dimensions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > It should be clarified that there is also an [End Define Mated Model] > keyword. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |*----------------------------------------------------------------------------- [Define Mated Model] CONN4X40 Cpad_1 = .5pF Cpad_2 = 1.0pF |* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Perhaps some clarification would be helpful here. This is understood to be > a manufacturers suggested default value. A value of zero (0) is allowed. > This is a parameter that falls outside of the boundaries of the model and > is provided as a first level estimate only. Simulators can replace > this value as needed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package |* or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs and .pkg files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes |* Description: Declares the manufacturer of the package or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs and .pkg | files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of |* what kind of package the [Package Model] or mated model is |* representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package |* stub' or mated model. | A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |* This keyword also defines the number of sections that make up |* a mated model. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |****************************************************************************** |****************************************************************************** |* BIRD28.3 REPLACEMENT BELOW |****************************************************************************** |****************************************************************************** |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package |* or mated model | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section |* of a pin's die to pin connection or mated model connection. | Sub-Params: Len, L, R, C, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. |* |* For package models, the first column is used for listing each |* pin. For mated models, the first and second columns are used |* to list the side 1 pins and the corresponding side 2 pins. |* Normally the side 2 listing is the same as the side 1 listing. |* However, for cables and connectors that crossover or have |* different pin names or groupings at either end, the two columns |* will have different entries. All Matrix references will be |* based on the first column notation and order. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > I think this Pin Numbering can become very complicated for connectors and > cables. e.g., A cable wire can go from pin 2 to pin 3 and possibly to > pin 4 also. A connector can have a different footprint on each side with > some pins being on one side only and not on the other. e.g., A ground > blade could be connected to several pins in a column on one side and a > different number of pins in a row on the other side. Or the pins could > be in a row on both sides but numbered differently. > I am not sure how these complications can be handled. We will need a very > generalized interconnection capability within the model. We need to be > careful that we do not accept something that will make backward > compatibility difficult in the future when more advanced interconnection > structures need to be accommodated. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | | Subparameters: | The subparameters specify the length, inductance, capacitance |* and resistance of each section of each stub on a package or | mated model. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. The subparameters are defined as | follows: |* Len The length of a package or mated model stub section. |* Lengths are given | in terms of arbitrary 'units'. |* L The inductance of a package stub or mated model section, |* in terms of | 'inductance/unit length'. For example, if the total | inductance of a package stub section is 3.0nH and the | length of this section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). |* C The capacitance of a package stub or mated model section, |* in terms of | capacitance per unit length. |* R The DC (ohmic) resistance of a package stub or mated |* model section,in | terms of ohms per unit length. | Matrix Use of this subparameter means that this package stub |* or mated model | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | | Specifying a length or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. | |* Using the Subparameters to Describe Package or Mated Model |* Sections: | Each section description must begin with the Len subparameter and | ends with the slash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. All | package stub descriptions must contain the same number of | sections however, a particular section description can contain | no data (i.e. the description is given as 'Len = 0 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | slash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the slash. |----------------------------------------------------------------------------- [Pin Numbers] A1 Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 / A2 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.1 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01/ A5 Len = 0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | | Note that the actual length for each section is reported, even for | those sections that use the Matrix subparameter. | |* Note that there are two columns of pin numbers if this is for a |* mated model definition. |============================================================================= | Keyword: [Model Data] |* Required: Yes, if any of the sections in a package stub or mated model |* description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |*Description: Indicates the beginning of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub |* or mated model | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub |* or mated model | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 REPLACEMENT OF EXITING VERSION 2.1 TEXT |****************************************************************************** |****************************************************************************** |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The subparameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the subparameters. | After each of these subparameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are |* defined as ENTERING the pins of the package or mated model |* from the board | (General Syntax Rule #11). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > I think I understand, and agree with, the current conventions but I am > confused by the voltage references. Can you elaborate? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | There are two different ways to extract the coefficients that are reported | in the the capacitance and inductance matrices. For the purposes of this | specification, the coefficients reported in the capacitance matrices shall | be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. | The Maxwell capacitance Kij is defined as the charge induced on conductor "j" | when conductor "i" is held at 1 volt and all other conductors are held at | zero volts. Note that Kij ( when i /= j) will be a negative number and | should be entered as such. Likewise, for the inductance matrix the | coefficients for Lij are defined as the voltage induced on conductor "j" | when conductor "i"'s current is changed by 1amp/sec and all other | conductors have no current change. | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 1. Why is "K" used for capacitance instead of "C"? This causes confusion > with the inductive coupling coefficient in SPICE which is "K". > 2. Why do we care HOW these Matrixes are CREATED if they give valid model > performance? After all, these matrixes just represent a set of > capacitance and inductance values. As long as the matrix values > provided, do not require a simulator to handle them any differently, > does it matter? If that is what is really important, how can we say > that clearly? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | |* For even a modest-sized package or mated model, |* this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N x M, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The Banded_matrix is used to specify the coupling effects up to B pins | on either side. Two variations are supported. One allows for the coupling | to circle back on itself. This is technically a simple form of a bordered | block diagonal matrix. However, its data can be completely specified | in terms of a Banded_matrix for an N x M matrix consisting of N rows | and M = N + B columns. The second variation is just in terms of an N x N | matrix where no circle back coupling needs to be specified. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | For case where coupling can circle back on itself, consider a matrix of | N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | The first row only needs to specify the entries [1,1] through [1,1+B] since | all other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2,2+B], and so on. For row K | the entries [K,K] through [K,K+B] are given when K + B is less than or | equal to the size of the matrix N. When K + B exceeds N, the entries in the | last columns 1 ... B specify the coupling to the first rows. For row K, the | entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = | mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. To avoid | redundant entries, the bandwidth is limited to B <= int((N - 1) / 2). | | For the case where coupling does not circle back on itself, the process is | modified. Only N columns need to be considered. When K + B finally exceeds | the size of the matrix N, the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. This construction | constrains the bandwidth to B < N. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs). | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | With this convention, please note that the N'th row of an | N x N matrix has just a single entry (the diagonal entry). | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |*============================================================================= |* Keyword: [End Mated Model] |* Required: Yes |* Description: Marks the end of a mated model description. |* Usage Rules: This keyword must come at the end of each complete mated |* model description. |* |* Optionally, add a comment after the [End Package Model] keyword |* to clarify which package model has just ended. For example, |* |* [Define Mated Model] My_Model |* | |* | ... content of model ... |* | |* [End Mated Model] | end of My_Model |* |*---------------------------------------------------------------------------- [End Mated Model] |* |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] December 13, 1995 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRD31.1 is a total rewrite of BIRD31 which proposed connector models split and attached directly on [Component] models. It was impractical, limiting, and burdensome to provide split models. "Mated models" is introduced as a general term to describe connectors, cables and socket. Its electrical format is the same as the package model format. The final form will track any further developments in package model syntax. Thus the mated model text was merged with the existing package model text to form a combined section. The interconnection is based on simulator dependent interfaces. The [Component] pins for the connector footprint must contain reference to Model_names or NC, POWER, or GND. The package model elements can be used to approximate the termination effects if the connector is NOT mated. The mated model elements override these package parameters when the interconnection is made. The electrical model of cables contain the effects of the connectors at both ends along with the cable wire descriptions. For [Components] modeled on sockets, the package model of the [Component] model will be used. Here the simulator interface could distinguish between a connection made to another board, and a connection made to just a component. (3) The mated model introduces the [Define Mated Model] and [End Mated Model] keywords because it differs from the package model in the following ways: (a) It adds optional Cpad_1 and Cpad_2 subparameters for pad capacitance. Most connector model do not include these effects. (b) The mated model is NOT referenced by any [Component] directly. The simulator interface determines how a mated model is connected (or not connected as in the case of an empty socket for optional memory. (c) The mated model must exist only in a separate file since it cannot be determined which mated model file to use if it also exists within a .ibs file. (In contrast, the [Package Model] keyword provides the direct reference, and its model is searched first in the .ibs file and then in any .pkg file.) (d) The mated model contains two columns of pins so that the pins on one side can be defined differently than the pins on the other side. Thus cables which have cross-over connections, or which can be split and feed several different connectors can be described. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Wed Apr 3 14:36:30 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA00245 for ; Wed, 3 Apr 1996 14:36:14 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 3 Apr 96 14:27 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 3 Apr 96 14:30 PST Message-Id: Date: Wed, 3 Apr 96 14:30 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: S2IBIS VER 2.091 PROBLEMS To IBIS Members: Per the last meeting request, here is a list of problems that I sent to NCSU last November for the Beta s2ibis Version 2.091. This is to start documenting the problems. These comments also include some comments on the documentation. Others may have sent some crash cases directly. (1) As previously noted, there seems to be a minor glitch in that the first line of the newtryme.s2i must either be a blank line or a commented line. It cannot start with [IBIS Ver] as documented. (2) Compared with s2ibis_1.2, there is some missing functionality which is needed. The first problem is that [vinl] and [vinh] have dual meanings: first to set the Spice input Pulse levels for simulation, and secondly to enter Vinl = xx and Vinh = xx. In Version 1.2, the specification thresholds were independent options set by **Vinh = xxx ,etc. Furthermore Version 1.2 had some additional optional min and max input voltage settings using **Input_ramp_xxx vil vih tr tf where xxx is typ, min or max. What I propose is still using [Vinl] and [Vinh] ONLY for actual threshold entries if given (put nothing otherwise). Use new keywords for Input voltage levels and input rise times: [Vil] xx xx xx [Vih] xx xx xx [Tr] xx xx xx [Tf] xx xx xx For example for CMOS input with [Voltage Range] 5 4.5 5.5 you might set [Vih] 5 4.5 5.5 |reqd [Vil] 0 0 0 |reqd [Tr] 1n 2n .5n |optional [Tf] 1n 2n .5n |optional [Vinh] 3.5 [Vinl] 1.5 If a control entry is NA, then use the "typ" entry as the default. The Typ numerical entry is required if the control keyword is used. (3) There is no provision similar to **NoModel, **NoPolarity, **NoEnable and Overiding the Polarities and Enable as in Version 1.2 The NoModel is important because the Input Pin may really be an internal input (e.g., without clamps) and not really represent a real input that is provided by as separate model. The others are conveneniences to standardize on models or to configure generic Spice model for a specific part. My example in this case is that often the F244 model is given to represent F241, F242, etc., and the only difference is the polarity of the enable and inputs. (4) I do not have a test case yet for this, but under some conditions from customers where they did something wrong - there can be out of range entries 0000000000000000000000000000A ... ... This might be a clamping table where the prior, normally formatted entries may be go to GA and TA etc. Some sort of exponential conversion needs to be provided for larger than T and smaller than f units prefixes. (5) In you newtryme.s2i test case, I used for the maximum entry of [C_comp] the scientific notation entry of 4e-12 and got a Segmentation fault error along with error text. I get Segmentation fault for other errors as well - e.g. putting xxx or omitting the parameter. So two issues exist: "Segmentation fault" is really a crash; so a more graceful memory cleanup is needed. Also, Scientific Notation of numerical entries (and/or units prefixes) should be allowed. So I should be able to enter 1e-12 or 1e-9mF for 1pF. (6) Another parameter that is missing is something similar to *[Clamp_Tolerance] amps that exists in Version 1.2. One Customer has clamp currents in both tables > about 5e-6 which do not need to be presented. (7) Regarding the documentation, it is very good (at least to me). Here are some minor typo's or questions: (a) I have not checked, nor is it clear that for spicetype, are they case sensitive. Do you support other abbreviations such as P, H, 2, 3? (b) Temperature Range defaults might be for CMOS - T_min = 100C and T_max = 0C. For whatever is chosen, a comment should be made that the set of defaults apply for CMOS technology (or for Bipolar TTL and ECL). (c) For [Rload]: "Describes the load resistance to use when performing the simulations for the VT tables". (Change VI curves to VT tables) (d) [Manufacturer] name is required by IBIS. You indicate that it is optional. Therefore the default when the [Manufacture] control command is not provided is to always insert [Manufacturer] Manufacturer Name (e) One of the most confusing aspects which customers who are not very familiar with IBIS is the [Package Model] example in the newtryme.s2i. It should be proceeded with some comment line that this is used only if a .pkg file exists or if the [Define Package Model] keyword (which s2ibis2 does not support) is used. One customer used [Package Model] name and then added [Package] name to the [Package] keyword. Similar to [Pin Mapping], you should document that is there just for illustration purposes. (g) Under [Model Type] 3-State should be changed to 3-state. Bob Ross Interconnectix, Inc. From owner-ibis Wed Apr 3 16:42:06 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA01175 for ; Wed, 3 Apr 1996 16:42:05 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 3 Apr 96 16:33 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 3 Apr 96 16:36 PST Message-Id: Date: Wed, 3 Apr 96 16:36 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: S2IBIS VERSION 1.3 To All: s2ibis Version 1.3 is now available on vhdl.org under /pub/ibis/s2ibis/s2ibis/s2ibis_v1.3 This contains a correction of [Pullup] table currents in the power clamp region. Before, the power clamp currents appeared both in the [Power Clamp] table and in the [Pullup] table due to a subtraction indexing error. Bob Ross, Interconnectix, Inc. From owner-ibis Thu Apr 4 07:15:09 1996 Received: from crimp.amp.com (crimp.amp.com [198.80.3.102]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA13602 for ; Thu, 4 Apr 1996 07:15:06 -0800 (PST) Message-Id: <199604041515.HAA13602@vhdl.vhdl.org> Received: by crimp.amp.com id AA19455 (InterLock SMTP Gateway 3.0 for ibis@vhdl.org); Thu, 4 Apr 1996 10:05:09 -0500 Received: by crimp.amp.com (Internal Mail Agent-1); Thu, 4 Apr 1996 10:05:09 -0500 From: Herrmann Hank To: IBIS Reflector , "John.Fitzpatrick" Cc: Millard Steve , Schroeder Jim Subject: Re: BIRD 31.1 Date: Thu, 04 Apr 96 10:01:00 E Encoding: 135 TEXT X-Mailer: Microsoft Mail V3.0 Hello John, Thank you for your review of my comments to BIRD 31.1 and your question (Included below). 'Minimum edge rate' is an often ignored and misunderstood point. That is why I am also sending this answer to the IBIS Reflector. There really seems to be two parts to your question. One is what 'Minimum edge rate' means to a connector, and the other is how does it relate to the model? I will answer the second question first. Connector models are built up from sets of R, L & C matrixes. The models currently available, represent those matrixes in SPICE Format. Once we define a means of modeling connectors in IBIS format, they will be represented by numeric matrixes. These matrixes actually represent pieces of transmission lines. To understand why there is a minimum edge rate associated with these RLC structures, we need to look at some Transmission Line (TL) theory. A lossless TL can be represented by a characteristic impedance and a time delay, or by an LC pair. The first is called the distributed model and the second, the lumped model. Distributed models are like real TL's. Lumped models are an approximation that is useful in circuit modeling. These two types of representations are equivalent only if the time delay through the lumped model section is less than a small part of the rise length of the signal going through it. What's that mean? For digital signals, there is a distance that the signal travels during the time it changes. That distance depends on the medium through which the signal travels. It is called the rise length. It is significant because there is a transition taking place all along that path. The signal, on a circuit that is one rise length long, can not be considered a constant. value. It you take a small enough part of the rise length, you can make that simplifying assumption. Now for an example. Lets look at a lossless, matched TL in a digital system. Values of 10nH and 4pF represent a 50 ohm TL that is 200ps long. [Z=sqrt(L/C) & T=sqrt(LC)] If a 200ps edge rate signal is placed on a real TL like that, the signal will be fully switched at the beginning before any of it gets to the end. In the real TL, it will come out looking the same as it did when it started (in the matched condition: ie, 50 ohm source & load). If the TL is represented with one 10nH inductor and one 4pF capacitor, it will look very different. There will be a large amount of overshoot and undershoot. If those values are divided into small equal sections, the simulated signal will be much more realistic. Depending on the specific situation, values from one fifth (1/5) to one twentieth (1/20) of the rise length are used for the subdivision. This example could be modeled with reasonable accuracy using 10 LC sections in series with each L & C being 1nH and 0.4pF respectively. That is a very brief explanation of the first factor that is significant in determining a model's Minimum Edge Rate. Simplistically, if you put too fast an edge rate signal through a model, it will ring like a church bell and give inaccurate answers. There is another factor that comes into play in connector models. It has to do with the 'resolution' to which the connector structure is represented in the model. More of the structure becomes visible to the signal at faster edge rates. It is therefor necessary to include an increased level of detail in 'faster' models. Why not just provide all the detail? Computer resources and execution time go up drastically as detail is increased. Also, it is not at all obvious (it is a connector modelers engineering task) how to reduce the detailed model to the slower version. That is why we provide a family of models for each connector. You see now, that there is a danger of obtaining unrealistic simulation data if adequate models are not used. (This also applies to package models.) That is why I feel it is important to provide a way that the simulator can determine the validity of the model for the simulation. The 'Minimum Edge Rate' keyword would define the upper limits for applying the model. It could also allow the simulator to pick the simplest model for the job. Including it would be the fist step toward those capabilities. After that, the simulator writers have to figure out how to use it. The other part of your question relates to what distinguishes high speed connectors from ordinary ones. It does not relate directly to IBIS, so I will be brief on this part. Again it is a transmission line problem. A good high speed connector causes the least amount of distortion to the signals. This is accomplished through management of the EM fields, minimizing line to line couplings, and minimizing common mode impedance, to name just some major factors. There is no one perfect design and it costs more to make connectors that do those things well. That is why we have so many different types and why they cost more. I hope this answers your questions adequately. Hank Herrmann Technical Staff Member AMP Incorporated, Electromagnetic Technology M.S. 106-14 P.O. Box 3608 Harrisburg, PA 17105-3608 Phone: 717-986-5534 FAX: 717-986-5643 INTERNET: hank.herrmann@amp.com ---------- From: John.Fitzpatrick To: Herrmann Hank Subject: Re: BIRD 31.1 Date: Thursday, April 04, 1996 9:50AM > 1. The Minimum Edge Rate for a package, connector or cable model should be > specified as a required parameter. A required Keyword, such as > [Minimum Edge Rate], should be added. Eventually, simulators should > generate a warning message if faster signals are impinging on the model. Hank, I have often wondered how a "minimum edge rate" for a connector is defined, and how it should be used. Often it seems to be just a sales argument to encourage us to buy more expensive connectors :-) Can you explain what a [Minimum Edge Rate] keyword will mean exactly? Why should faster signals not be allowed to impinge on a model? A simulator should base its warnings upon the result of simulations. I agree that this keyword might be useful in helping a designer choose a connector. Regards, John -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From owner-ibis Thu Apr 4 09:12:03 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA14291 for ; Thu, 4 Apr 1996 09:11:57 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 4 Apr 96 09:03 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 4 Apr 96 09:05 PST Message-Id: Date: Thu, 4 Apr 96 09:05 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Forwarded: Re: BIRD 31.1 I forgot to forward this to the ibis reflector. Bob Date: Wed, 3 Apr 96 19:18 PST From: bob@icx.com ( Bob Ross) To: hank.herrmann@amp.com Subject: Re: BIRD 31.1 Hank and IBIS Committee: Thank you for your thorough and thoughtful review. At some risk of confusing the context, I have pulled out your concerns and deleted most of the surrounding text. My responses are on lines without ">>". More discussion is most welcome. Bob Ross Interconnectix, Inc. > Wed, 3 Apr 1996 10:26:01 -0500 > From: Herrmann Hank > To: IBIS Reflector > Cc: Millard Steve , > Schroeder Jim > Subject: BIRD 31.1 > Date: Wed, 03 Apr 96 10:21:00 E > I have attached the full text of BIRD 31.1 with my comments and questions > inserted and marked off with ">>>" symbols so they are easy to find. > Hank Herrmann > Technical Staff Member > AMP Incorporated, Electromagnetic Technology > M.S. 106-14 > P.O. Box 3608 > Harrisburg, PA 17105-3608 > Phone: 717-986-5534 > FAX: 717-986-5643 > INTERNET: hank.herrmann@amp.com > [[ Cmts_02_00.txt : 2654 in Cmts_02_.00t ]] > 3/28/96 > Comments & Questions to BIRD 31.1 They are inserted in the text of the BIRD > and are set off with ">>>>>>>>>>" symbols. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > General Questions & Comments: > > 1. The Minimum Edge Rate for a package, connector or cable model should be > > specified as a required parameter. A required Keyword, such as > > [Minimum Edge Rate], should be added. Eventually, simulators should > > generate a warning message if faster signals are impinging on the model. 1. If it is to be included, I would prefer it to be a required subparameter for Mated Models only. It would be a "specification" type subparameter such as Vinl and Vinh rather than a model element. In Spice models, such information exists only as a comment line. Since the [Description] keyword is required, I would prefer it to be captured there. However, the IBIS Committee can decide this. > > 2. The word "STUB" is used to mean a conductive or transmission path > > through a model. Is that normal EDA / IC / IBIS terminology? It > > is confusing to connector modelers because a "STUB" to us is a passive > > tap off of a transmission path. The word "PATH" would be preferred. 2. The STUB term is used in BIRD28.3. I believe it is correct in the context that it is used, but can understand the terminology confusion. Comments??? > > 3. How can connections be established between pins and internal matrix > > tie points? Transmission and shielded type connectors require them. > > Shielded cables, and transmission paths over ground planes can also > > require them. 3. An extension can be a possible [Conductance] matrix or conductance element to complete the coupled RL/GC incremental model - within this proposal. The package subcommittee may propose some extensions. Otherwise such tie points would not be possible. > > 4. Un-mated connector models are not the same as a mated model that is > > not connected to something. Empty sockets and un-used bus slots > > present a reduced capacitance and there may be no significant > > inductance. There are also backplane connectors that have pin fields > > that penetrate through the PCB and provide a 'back panel connection > > point'. They too, are often not connected. A much more simple single > > sided model would be the preferred structure for such device models. 4. This proposal does not cover un-mated models. However, it may be possible to use the existing [Component] description for the connector pins and populate them with NC, POWER, and GND pins as appropriate, and include with the [Package] or [Pin] models the un-mated description. So, when the connector is not connected, these parasitics would be used. > > 5. This appears to describe an entire connector without the use of > > reusable sub-matrixes. Is that correct? If so, is that really an > > acceptable general solution? 5. This proposal will track any extension that is proposed by the package subcommittee with respect to reusable sub-matrices. So far, there is no approved format for this. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Where are the boundaries for a Package model? Do they extend to the end of > > the pins or SMT legs or do they stop short somewhere? > > A standard boundary should be established. We use the plane at the top of > > the socket. We find that necessary because of the interaction of the IC > > pin with the Socket Contacts when C & L parameters are extracted. It is > > also a reasonable boundary, from the IC perspective, since it coincides > > with the plane of a PCB surface. The IC pins always go into a PCB or into > > a socket below that boundary. > > It is also important to define boundaries for the .mmf models. My understanding is that the Package model includes the printed circuit board pad (C_pad or C_pin). Since the Mated Model would not exist within a .ibs file, its boundaries stop at the plane at the top of the socket/ board. Thus an Optional Cpad_1 and Cpad_2 are provided to give default pad capacitance values with the assumption that they are not in the mated model. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > There could be several reasons not to exclude these sections. How can we > > add additional connections (See comments under Keyword: [Pin Numbers]) or > > additional components like capacitor filters, ESD clamps and even active > > devices, to our connector models? We do manufacture connectors that > > contain such devices. Maybe this makes this .mmf a .ibs for those kinds > > of devices but since you separated active device models (.ibs) and passive > > device models (.pkg & .mmf) I need to understand the reasons and consider > > all of the implications. This proposal does not support allowing general networks with a mated model file other than composed of the allowable L/R/C networks. Non linear devices such as ESD clamps are not included. This could make the proposal and the processing of mated models much more complicated for the small percentage of connectors with such extensions. Also some simulator vendors have other solutions which may handle these complications. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > It should be clarified that there is also an [End Define Package Model] > > keyword. Good suggestion for extending the descripton of [Define Package Model]. The [End Package Model] is defined much further down in the specification. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > It should be clarified that there is also an [End Define Mated Model] > > keyword. Good suggestion for extending the descripton of [Define Mated Model]. The [End Mated Model] is defined much further down in the specification. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > |*----------------------------------------------------------------------------- > [Define Mated Model] CONN4X40 > Cpad_1 = .5pF > Cpad_2 = 1.0pF > |* > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Perhaps some clarification would be helpful here. This is understood to be > > a manufacturers suggested default value. A value of zero (0) is allowed. > > This is a parameter that falls outside of the boundaries of the model and > > is provided as a first level estimate only. Simulators can replace > > this value as needed. Good suggestion for clarification. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I think this Pin Numbering can become very complicated for connectors and > > cables. e.g., A cable wire can go from pin 2 to pin 3 and possibly to > > pin 4 also. A connector can have a different footprint on each side with > > some pins being on one side only and not on the other. e.g., A ground > > blade could be connected to several pins in a column on one side and a > > different number of pins in a row on the other side. Or the pins could > > be in a row on both sides but numbered differently. > > I am not sure how these complications can be handled. We will need a very > > generalized interconnection capability within the model. We need to be > > careful that we do not accept something that will make backward > > compatibility difficult in the future when more advanced interconnection > > structures need to be accommodated. Because two columns exist, completely different numbering conventions may be used on each sides. Also cross connections such as pin 2 on side 1 to pin 3 on side 2 can be supported. There may be a practical limit to the generality provided. The mated model just describes the connector, socket or cable ends of that component only. Its numbering convention may be different than the footprint that it is attached. It becomes a simulator specific problem to provide the connections to each side of the mated model. Thus, the proposal supports vendors generating mated models with a reasonable numbering convention, but not constraining the board to use the same numbering convention. Thus each simulator needs some mapping interface. Also, the connection of the board to the mated model must distinguish whether it is connecting to side 1 or side 2 since the mated model is not presumed to be symmetrical. This also provides another argument that the mated model needs to be in a separate file and not in a .ibs file. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > | Other Notes: The resistance, inductance, and capacitance matrices are also > | referred to as "RLC matrices" within this specification. > | > | When measuring the entries of the RLC matrices, either with > | laboratory equipment or field-solver software, currents are > |* defined as ENTERING the pins of the package or mated model > |* from the board > | (General Syntax Rule #11). The corresponding voltage drops are > | to be measured with the current pointing "in" to the "+" sign > | and "out" of the "-" sign. > | > | I1 +-----+ I2 > | -----> | | <------ > | board o--------| Pkg |---------o board > | + V1 - | | - V2 + > | +-----+ > | > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > I think I understand, and agree with, the current conventions but I am > > confused by the voltage references. Can you elaborate? The context of this description is for the existing IBIS Version 2.1 package model only. Here I1 and I2 are two different, unrelated pins. I agree that this is confusing. The voltages could be with respect to a general, undefined ground. However, even within the package model, there may be some different reference planes. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > |****************************************************************************** > |* BIRD28.3 ADDITION > |****************************************************************************** > |****************************************************************************** > | There are two different ways to extract the coefficients that are reported > | in the the capacitance and inductance matrices. For the purposes of this > | specification, the coefficients reported in the capacitance matrices shall > | be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. > | The Maxwell capacitance Kij is defined as the charge induced on conductor "j" > | when conductor "i" is held at 1 volt and all other conductors are held at > | zero volts. Note that Kij ( when i /= j) will be a negative number and > | should be entered as such. Likewise, for the inductance matrix the > | coefficients for Lij are defined as the voltage induced on conductor "j" > | when conductor "i"'s current is changed by 1amp/sec and all other > | conductors have no current change. > | > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 1. Why is "K" used for capacitance instead of "C"? This causes confusion > > with the inductive coupling coefficient in SPICE which is "K". 1. The K convention existed in one reference paper. However, I agree that it is confusing and would prefer a different notation. > > 2. Why do we care HOW these Matrixes are CREATED if they give valid model > > performance? After all, these matrixes just represent a set of > > capacitance and inductance values. As long as the matrix values > > provided, do not require a simulator to handle them any differently, > > does it matter? If that is what is really important, how can we say > > that clearly? 2. In general, the simulator needs to know how the matrices are defined. The definitions above are consistent with field solver output formats. We may need to clarify your concerns further. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -------- End of Forwarded Message From owner-ibis Thu Apr 4 14:59:41 1996 Received: from ingr.ingr.com (ingr.ingr.com [129.135.211.100]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA16963 for ; Thu, 4 Apr 1996 14:59:38 -0800 (PST) Received: from hq14.pcmail.ingr.com by ingr.ingr.com (5.65c/1.920611) id AA28492; Thu, 4 Apr 1996 16:50:12 -0600 Received: by hq14.pcmail.ingr.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB2246.C7AB7BA0@hq14.pcmail.ingr.com>; Thu, 4 Apr 1996 16:50:07 -0600 Message-Id: From: "Wiens, David" To: "ibis@vhdl.org" Subject: Use of EDIF for layout data transfer Date: Thu, 4 Apr 1996 16:50:21 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 59 TEXT Folks, The IBIS Packaging Subcommittee has narrowed its search for a PCB/MCM layout data transfer format to EDIF 4.0.0. The EDIF specification is currently in ballot stage, which means we've got a window of opportunity to get some changes included. The following issues were brought up by the subcommittee for clarification or enhancement of the standard : - Need to have an EDIF construct inside a 'component' and/or 'part' that references an external IBIS model file. This can currently be done using a generic name/value 'property', but leaves itself open for misinterpretation. - Make sure there is only one way to specify R/L/C for components. - Can EDIF support multiple-board definition? EDIF 4.0.0 is open for comment until May 28th. If you're interested in reviewing it, you can get the docs off the net or on CD. The docs are in Frame v4 as hypertext online format. I'd advise against printing the doc out (~3500 pgs). If you're Frame-handicapped, I can probably send you a PS file of one of the better sections (~100pgs). CD : - Call Patti Rusher at 703-907-7545 or E-mail at prusher@eia.org. (While supplies last... she's running low). Jon Powel, you've got a copy headed your way. FTP : - E-mail Julie Spink at jules@edif.org or jules@cs.man.ac.uk and request a password to the server. Warning...this site is in the UK and takes a while to pull... If you review the doc, I'd recommend starting with the Level-0 Information Model (IMTOC.DOC). If you have suggestions regarding use of EDIF in association with IBIS, please send them to me, and the subcommittee will send them as a collection to EIA. We may be able to lend more weight that way. For general EDIF comments, send them to Patti Rusher or Hilary Kahn. Patti said that the EDIF group prepared an EDIF file of the PCB Design Conference (non)benchmark board. I'll see if we can get our hands on it for review... If you're interested in companies supplying APIs for EDIF reading/writing, I believe the following companies are in the process of writing (or are done with) software : - Engineering Data Express - 408-243-8786 - Electronic Tools Company - 707-996-3320 David Wiens VeriBest Inc. From owner-ibis Fri Apr 5 09:51:59 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA00446 for ; Fri, 5 Apr 1996 09:51:59 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id JAA15922 for ; Fri, 5 Apr 1996 09:43:08 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id JAA09074 for ibis@vhdl.org; Fri, 5 Apr 1996 09:43:07 -0800 (PST) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Fri, 05 Apr 96 09:43:07 PST Date: Fri, 05 Apr 96 09:40:00 PST From: Will Hobbs Message-ID: To: ibis@vhdl.org Subject: Golder Parser V2.1.11 Hello, The source diskettes for those who have licensed the ibis_chk source code will be sent out on Monday. If you are a licensee and haven't received them by the end of next week, let me know. Regards, Will From owner-ibis Sun Apr 7 16:15:11 1996 Received: from user1.channel1.com (user1.channel1.com [199.1.13.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA14507 for ; Sun, 7 Apr 1996 16:15:09 -0700 (PDT) Received: from remote23.channel1.com (remote23.channel1.com [204.96.32.23]) by user1.channel1.com (8.6.12/8.6.9) with SMTP id TAA11018 for ; Sun, 7 Apr 1996 19:04:04 -0400 Date: Sun, 7 Apr 1996 19:04:04 -0400 Message-Id: <199604072304.TAA11018@user1.channel1.com> X-Sender: haselect@user1.channel1.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: haselect Subject: [Resistance Matrix] keyword Hello Ibisians, I wonder if somebody could clarify the use of resistance matrices in package models. Should the values entered in these matrices be in Siemens or Ohms? It seems to me that the resistance matrix is really a conductance matrix, because in the case of a banded matrix (for example) it is assumed that values outside the bandwidth are zero - doesn't this mean zero Ohms and so wouldn't it mean that the corresponding pins would be short circuited togther? Zero conductance on the other hand would imply an open circuit which would make more sense. For example if we had a 2 pin package: [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 1.0 [Row] 2 1.0 My understanding of the IBIS spec' leads me to understand that the full matrix would be: | 1 0 | | 0 1 | I.e. pins 1 and 2 have resistances of 1 Ohm, but there is a 0 Ohm short circuit between them. Have I misunderstood something here? I'm about to model a device package where there is a degree of resistive coupling between the pins and I need to know the correct units to use, Siemens or Ohms? Haruny Said H.A.S. Electronics, Inc. 130 Bishop Allen Drive Cambridge MA 02139 Email haselect@haselect.com WWW http://www.haselect.com Phone (617) 868 7828 From owner-ibis Mon Apr 8 05:39:13 1996 Received: from maxwell.ansoft.com (maxwell.ansoft.com [192.149.1.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id FAA26114 for ; Mon, 8 Apr 1996 05:39:12 -0700 (PDT) Received: from saturn.ansoft.com by maxwell.ansoft.com (4.1/SMI-4.1) id AA11341; Mon, 8 Apr 96 08:28:22 EDT Received: by saturn.ansoft.com (4.1/SMI-4.1) id AA15010; Mon, 8 Apr 96 08:28:22 EDT Message-Id: <9604081228.AA15010@saturn.ansoft.com> To: haselect Cc: ibis@vhdl.org Subject: Re: [Resistance Matrix] keyword In-Reply-To: Your message of "Sun, 07 Apr 1996 19:04:04 EDT." <199604072304.TAA11018@user1.channel1.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <15008.828966499.1@saturn.ansoft.com> Date: Mon, 08 Apr 1996 08:28:20 -0400 From: Eric Bracken With regard to the units: It's Ohms. With regard to the off-diagonal entries of the R-matrix: [R] really represents the voltages developed along the conductors in response to DC current flows: V1 = R11 * I1 + R12 * I2 V2 = R12 * I2 + R22 * I2 If R12 = 0, this is just saying that V1 = R11 * I1 and V2 = R22 * I2 and so the only voltage drop you get on the wire is due to current flowing along THAT wire, and not the other one. This is like having two separate wires with an ideal ground return: I2 ----> V2 0---[ R22 ]---0 V2 - R22*I2 I1 ----> V1 0----[ R11 ] ---0 V1 - R11*I1 + + - - 0----------------0 ground (ideal) <--------- I1 + I2 Note that by KCL the current flowing back along the ground line is I1 + I2; in this ideal case, there's no voltage developed due to the ground current. In the case where R12 is NONzero, this is like having a ground return with some resistance Rg associated with it: I2 ----> V2 0---[ R2 ]---0 V2 - R2*I2 - Rg*(I1 + I2) I1 ----> V1 0----[ R1 ] ---0 V1 - R1*I1 - Rg*(I1 + I2) + + - - 0----[ Rg ]----0 ground (nonideal) <--------- I1 + I2 Here, R12 = Rg and R11 = R1 + Rg, R22 = R2 + Rg. I hope that this helps... --Eric __________________________________________________________________ ________ ________ __ ________ /\_______\ /\_______\ /\_\ /\_______\ J. Eric Bracken, Ph.D. / / ______// / ____ // / // / ______/ Ansoft Corporation / / /__\ / / /__\/ // / // / / Four Station Square, Suite 660 / / ____/ / / ___ _// / // / /___ Pittsburgh, PA 15219-1119 / / /____\ / / / \/ / / / // / /____\ (412) 261-3200 FAX (412) 471-9427 \/_______/ \/_/ \/_/ \/_/ \/_______/ bracken@ansoft.com http://www.ece.cmu.edu/afs/ece/usr/bracken/.home-page.html __________________________________________________________________ From owner-ibis Mon Apr 8 08:13:55 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA26957 for ; Mon, 8 Apr 1996 08:13:55 -0700 (PDT) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA16573; Mon, 8 Apr 1996 08:04:58 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma828975896.016569; Mon Apr 8 08:04:56 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id LAA13602; Mon, 8 Apr 1996 11:04:54 -0400 Date: Mon, 8 Apr 1996 11:04:54 -0400 From: "C. Kumar" Message-Id: <199604081504.LAA13602@hot> To: haselect@haselect.com, ibis@vhdl.org Subject: Re: [Resistance Matrix] keyword Cc: cpk@hot.cadence.com X-Sun-Charset: US-ASCII The resistance matrix is resistance(not conductance) and the off diagonal elements can be zero. Let us take an example of 2 pin system V = [R]I (1) where [R] is a 2x2 matrix r11 r12 r21 r22 V and I are vectors V = (v1 v2) and I=(i1 i2) whcih define the voltage and currents The expanded form of equation 1 is v1 = r11 * i1 + r12 * i2 v2 = r21 * i1 + r22 * i2 You can see that the off diagonal terms can be zero without producing a short circuit Regards - kumar > From owner-ibis@vhdl.vhdl.org Sun Apr 7 19:16 EDT 1996 > Received-Date: Sun, 7 Apr 1996 19:16:10 -0400 > X-Sender: haselect@user1.channel1.com (Unverified) > X-Mailer: Windows Eudora Light Version 1.5.2 > Mime-Version: 1.0 > To: ibis@vhdl.org > From: haselect > Subject: [Resistance Matrix] keyword > X-Lines: 48 > > Hello Ibisians, > > I wonder if somebody could clarify the use of resistance matrices in > package models. Should the values entered in these matrices be in Siemens or > Ohms? > > It seems to me that the resistance matrix is really a conductance > matrix, because in the case of a banded matrix (for example) it is assumed > that values outside the bandwidth are zero - doesn't this mean zero Ohms and > so wouldn't it mean that the corresponding pins would be short circuited > togther? Zero conductance on the other hand would imply an open circuit > which would make more sense. > > For example if we had a 2 pin package: > > [Resistance Matrix] Banded_matrix > [Bandwidth] 0 > [Row] 1 > 1.0 > [Row] 2 > 1.0 > > My understanding of the IBIS spec' leads me to understand that the full > matrix would be: > > > | 1 0 | > | 0 1 | > > I.e. pins 1 and 2 have resistances of 1 Ohm, but there is a 0 Ohm short > circuit between them. > > > Have I misunderstood something here? > > > I'm about to model a device package where there is a degree of resistive > coupling between the pins and I need to know the correct units to use, > Siemens or Ohms? > Haruny Said > H.A.S. Electronics, Inc. > 130 Bishop Allen Drive > Cambridge MA 02139 > Email haselect@haselect.com > WWW http://www.haselect.com > > Phone (617) 868 7828 > > From owner-ibis Tue Apr 9 05:22:36 1996 Received: from user1.channel1.com (user1.channel1.com [199.1.13.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id FAA12222 for ; Tue, 9 Apr 1996 05:22:35 -0700 (PDT) Received: from remote4.channel1.com (remote4.channel1.com [204.96.32.4]) by user1.channel1.com (8.6.12/8.6.9) with SMTP id IAA15093; Tue, 9 Apr 1996 08:11:35 -0400 Date: Tue, 9 Apr 1996 08:11:35 -0400 Message-Id: <199604091211.IAA15093@user1.channel1.com> X-Sender: haselect@user1.channel1.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "C. Kumar" From: haselect Subject: Re: [Resistance Matrix] keyword Cc: ibis@vhdl.org Kumar & Co, thankyou for your replies, I suspected it was a Z parameter matrix; but something I read in a signal intergrity tool user's manual lead me to think that the tool was treating this differently - anyway an equation saves a thousand words as far as I'm concerned, thanks. At 11:04 AM 4/8/96 -0400, you wrote: >The resistance matrix is resistance(not conductance) and the off diagonal elements can be zero. > >Let us take an example of 2 pin system > >V = [R]I (1) > >where [R] is a 2x2 matrix > >r11 r12 >r21 r22 > >V and I are vectors V = (v1 v2) and I=(i1 i2) whcih define the voltage and currents > >The expanded form of equation 1 is > >v1 = r11 * i1 + r12 * i2 >v2 = r21 * i1 + r22 * i2 > >You can see that the off diagonal terms can be zero without producing a >short circuit > >Regards >- kumar > >> From owner-ibis@vhdl.vhdl.org Sun Apr 7 19:16 EDT 1996 >> Received-Date: Sun, 7 Apr 1996 19:16:10 -0400 >> X-Sender: haselect@user1.channel1.com (Unverified) >> X-Mailer: Windows Eudora Light Version 1.5.2 >> Mime-Version: 1.0 >> To: ibis@vhdl.org >> From: haselect >> Subject: [Resistance Matrix] keyword >> X-Lines: 48 >> >> Hello Ibisians, >> >> I wonder if somebody could clarify the use of resistance matrices in >> package models. Should the values entered in these matrices be in Siemens or >> Ohms? >> >> It seems to me that the resistance matrix is really a conductance >> matrix, because in the case of a banded matrix (for example) it is assumed >> that values outside the bandwidth are zero - doesn't this mean zero Ohms and >> so wouldn't it mean that the corresponding pins would be short circuited >> togther? Zero conductance on the other hand would imply an open circuit >> which would make more sense. >> >> For example if we had a 2 pin package: >> >> [Resistance Matrix] Banded_matrix >> [Bandwidth] 0 >> [Row] 1 >> 1.0 >> [Row] 2 >> 1.0 >> >> My understanding of the IBIS spec' leads me to understand that the full >> matrix would be: >> >> >> | 1 0 | >> | 0 1 | >> >> I.e. pins 1 and 2 have resistances of 1 Ohm, but there is a 0 Ohm short >> circuit between them. >> >> >> Have I misunderstood something here? >> >> >> I'm about to model a device package where there is a degree of resistive >> coupling between the pins and I need to know the correct units to use, >> Siemens or Ohms? >> Haruny Said >> H.A.S. Electronics, Inc. >> 130 Bishop Allen Drive >> Cambridge MA 02139 >> Email haselect@haselect.com >> WWW http://www.haselect.com >> >> Phone (617) 868 7828 >> >> > > Haruny Said H.A.S. Electronics, Inc. 130 Bishop Allen Drive Cambridge MA 02139 Email haselect@haselect.com WWW http://www.haselect.com Phone (617) 868 7828 From owner-ibis Thu Apr 11 16:47:51 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA18980 for ; Thu, 11 Apr 1996 16:47:46 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id QAA14107 for ; Thu, 11 Apr 1996 16:38:53 -0700 (PDT) Received: from pdx836 by ichips.intel.com (8.7.1/jIII) id QAA05834; Thu, 11 Apr 1996 16:38:48 -0700 (PDT) Received: by pdx836 (4.1/10.0i); Thu, 11 Apr 96 16:38:47 PDT Message-Id: <9604112338.AA28864@pdx836> Subject: comments on BIRD 31.1 To: ibis@vhdl.org Date: Thu, 11 Apr 1996 16:38:47 -0700 (PDT) From: "David Fogel" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: ibis@vhdl.org Subj.: Mated connector model, BIRD 31.1 Regarding the proposed BIRD31.1 specs, I have the following questions/comments 1. Power and ground pins assignment will affect L,C values 1. Ground (and power) pins assignment will affect both the self LC values of a pin and the LC coupling matrix, based on the position of each pin relative to the ground pins. Consider the following three connector pins example: o o o ^ ^ ^ | | | gnd 1 2(or gnd) The pins are 50 mils apart. When only the center pin is a signal and the other two are ground I get: SINGLE CONDUCTOR LC: ____________________ i j Lij Cij Ze Zo Se So Fwdx Rvsx from to (nh/in) (pf/in) (ohms) (ohms) (ns/ft)(ns/ft) (s/s) (v/v) -------------------------------------------------------------------------- 1 1 10.537 3.066 58.63 - 2.16 - - - ; and when only one side pin is a ground I get: DUAL CONDUCTOR LC: _________________ i j Lij Cij Ze Zo Se So Fwdx Rvsx from to (nh/in) (pf/in) (ohms) (ohms) (ns/ft)(ns/ft) (s/s) (v/v) -------------------------------------------------------------------------- 1 1 15.880 3.066 88.36 - 2.16 - - - 1 2 10.903 1.502 130.90 33.01 2.46 1.81 0.303 0.597 2 2 22.247 2.188 123.78 - 2.16 - - - ; Which clearly demonstrates the fact that you can not assign LC values to connector pins just by their physical location in the connector. You also need to know their position relative to the ground pins. This can be accomplished by depicting several most likely to be used signal-gnd configurations and providing the LC matrices to all of them. In a dual row connector you may end up with about 10 different combinations. This kind of information is precisely what's needed for high speed simulations and will make the modeling effort worthwhile from system engineering point of view. 2. Another level of complication in a mated model is the plug-in daughter card. The fingers themselves are part of a PC board. How long are those fingers in the mated model? is there any definition for it? The electrical characteristics can be affected by the presence (or absence) of a ground plane in between the daughter cards' top and bottom layers (the finger layers). How is this going to be reflected in the model? 3. Another issue is measurements and verifications of the model itself. Since we are talking about relatively small LC values, the test set-up can greatly affect the measured LC values. You may build a very elaborate test fixture at your facilities and obtain very precise figures. But can every vendor or user do the same? How do we decide which values are the right ones. I believe that we need a well defined measurement methodology to be included as part of the specs. 4. Another method for model development is to use the mechanical drawings and feed the physical dimension to a field solver. If precise mechanical dimensions, including the ER of the connector body, can be provided, then a field solver can be used to extract the LC matrices. This can be an alternative to the above methods. The issue here is which field solver to use? 2D? 3D? from which CAE vendor? etc. David Fogel From owner-ibis Fri Apr 12 09:51:12 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA01933 for ; Fri, 12 Apr 1996 09:51:11 -0700 (PDT) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA12590 for ; Fri, 12 Apr 1996 09:42:17 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma829327335.012579; Fri Apr 12 09:42:15 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id MAA04495 for ibis@vhdl.org; Fri, 12 Apr 1996 12:42:13 -0400 Date: Fri, 12 Apr 1996 12:42:13 -0400 From: "C. Kumar" Message-Id: <199604121642.MAA04495@hot> To: ibis@vhdl.org Subject: DAC meeting X-Sun-Charset: US-ASCII Guys: I cannot recollect what we decided about IBIS meeting during DAC. Can any one of you know more details? Thanx - kumar From owner-ibis Fri Apr 12 10:14:41 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA02050 for ; Fri, 12 Apr 1996 10:14:39 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 10:05 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 10:08 PDT Message-Id: Date: Fri, 12 Apr 96 10:08 PDT From: bob@icx.com ( Bob Ross) To: cpk@cadence.com, ibis@vhdl.org Subject: Re: DAC meeting Kumar: That will be an agenda item for the next telephone meeting on April 19. We need to select a day/time for our DAC meeting and make arangements. Bob Ross Interconnectix, Inc. > Date: Fri, 12 Apr 1996 12:42:13 -0400 > From: "C. Kumar" > Message-Id: <199604121642.MAA04495@hot> > To: ibis@vhdl.org > Subject: DAC meeting > X-Sun-Charset: US-ASCII > Status: R > Guys: > I cannot recollect what we decided about IBIS meeting during DAC. > Can any one of you know more details? > Thanx > - kumar From owner-ibis Fri Apr 12 10:42:21 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA02264 for ; Fri, 12 Apr 1996 10:42:18 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 10:33 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 10:36 PDT Message-Id: Date: Fri, 12 Apr 96 10:36 PDT From: bob@icx.com ( Bob Ross) To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: Ramp rate and Rising/Falling waveform Syed: I believe that [Ramp] dV/dt information extracted from actual measurements of a packaged part could have the dt derated in some consistent manner to produce an effective die dV/dt. Whether this is done depends on how much the actual package degrades the response. There may be several methods to do the adjustment. One well-known rise time degradation approximation is based on the 10-90% definition of rise time and to use 2 2 2 Tmeas = Tdie + Tpkg to solve for Tdie from Tmeas and some Tpkg derating risetme. I do not support extending the [Ramp] definition to provide any further detail because such detail would be as complicated as the details needed for [Rising Waveform] and [Falling Waveform] WITHOUT the corresponding improved resolution that the Waveform provides. In other words, there would be a lot of parameters for completeness without the corresponding increase in accuracy. Bob Ross Interconnectix, Inc. > Date: Wed, 10 Apr 96 16:57:35 PDT > From: huq@rockie.nsc.com (Syed Huq) > To: ibis-users@vhdl.org > Subject: Ramp rate and Rising/Falling waveform > IBISgurus: > Ramp rate has been defined to be measured WITHOUT package information. > Rising/Falling waveform has been defined to include the pkg and fixture > information seperately. > I think Ramp rate should have the same options as Rising/Falling, ie. the > ability to add pkg and fixture parameters. This will allow an easy way > to measure Ramp rate WITH a packaged unit and not on a 'bare die' ! > I also wonder what inaccuracies I can expect if I provide Ramp rate > data on a packaged unit instead of a bare die. > Regards, > Syed > National Semiconductor From owner-ibis Fri Apr 12 11:37:56 1996 Received: from crimp.amp.com (crimp.amp.com [198.80.3.102]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA02716 for ; Fri, 12 Apr 1996 11:37:33 -0700 (PDT) Message-Id: <199604121837.LAA02716@vhdl.vhdl.org> Received: by crimp.amp.com id AA16301 (InterLock SMTP Gateway 3.0 for ibis@vhdl.org); Fri, 12 Apr 1996 14:28:10 -0400 Received: by crimp.amp.com (Internal Mail Agent-1); Fri, 12 Apr 1996 14:28:10 -0400 From: Herrmann Hank To: IBIS Reflector Cc: Millard Steve , Schroeder Jim Subject: RE: comments on BIRD 31.1 Date: Fri, 12 Apr 96 15:22:00 E Encoding: 161 TEXT X-Mailer: Microsoft Mail V3.0 To: David Fogel & IBIS Forum David raises good questions. My responses are inserted in his text below, set off by "+++++" for easy location. Hank Herrmann Technical Staff Member AMP Incorporated, Electromagnetic Technology M.S. 106-14 P.O. Box 3608 Harrisburg, PA 17105-3608 Phone: 717-986-5534 FAX: 717-986-5643 INTERNET: hank.herrmann@amp.com ---------- From: owner-ibis To: ibis Subject: comments on BIRD 31.1 Date: Thursday, April 11, 1996 4:38PM To: ibis@vhdl.org Subj.: Mated connector model, BIRD 31.1 Regarding the proposed BIRD31.1 specs, I have the following questions/comments 1. Power and ground pins assignment will affect L,C values 1. Ground (and power) pins assignment will affect both the self LC values of a pin and the LC coupling matrix, based on the position of each pin relative to the ground pins. Consider the following three connector pins example: o o o ^ ^ ^ | | | gnd 1 2(or gnd) The pins are 50 mils apart. When only the center pin is a signal and the other two are ground I get: SINGLE CONDUCTOR LC: ____________________ i j Lij Cij Ze Zo Se So Fwdx Rvsx from to (nh/in) (pf/in) (ohms) (ohms) (ns/ft)(ns/ft) (s/s) (v/v) -------------------------------------------------------------------------- 1 1 10.537 3.066 58.63 - 2.16 - - - ; and when only one side pin is a ground I get: DUAL CONDUCTOR LC: _________________ i j Lij Cij Ze Zo Se So Fwdx Rvsx from to (nh/in) (pf/in) (ohms) (ohms) (ns/ft)(ns/ft) (s/s) (v/v) -------------------------------------------------------------------------- 1 1 15.880 3.066 88.36 - 2.16 - - - 1 2 10.903 1.502 130.90 33.01 2.46 1.81 0.303 0.597 2 2 22.247 2.188 123.78 - 2.16 - - - ; Which clearly demonstrates the fact that you can not assign LC values to connector pins just by their physical location in the connector. You also need to know their position relative to the ground pins. This can be accomplished by depicting several most likely to be used signal-gnd configurations and providing the LC matrices to all of them. In a dual row connector you may end up with about 10 different combinations. This kind of information is precisely what's needed for high speed simulations and will make the modeling effort worthwhile from system engineering point of view. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + From a pure academic perspective, you are correct, but there is another way. We at AMP have devised proprietary methods that enable us to develop SPICE models that behave correctly without having defined the ground locations. You get the right behavior by just connecting the model to the actual circuit wiring pattern. There are full series and mutual parameters in the model for every line of the connector. Obviously, I can not share those methods but I feel that they are applicable and should be permitted by IBIS. If they are not permitted, there will have to be an overwhelming mass of specifically modeled configurations for each connector. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2. Another level of complication in a mated model is the plug-in daughter card. The fingers themselves are part of a PC board. How long are those fingers in the mated model? is there any definition for it? The electrical characteristics can be affected by the presence (or absence) of a ground plane in between the daughter cards' top and bottom layers (the finger layers). How is this going to be reflected in the model? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + This is exactly my point for the need to define model boundaries. We have definitions for each case. For card edge connectors, the model includes the recommended pads (as shown on the AMP customer drawing). There are separate models for boards with and without ground planes where those are common practices. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3. Another issue is measurements and verifications of the model itself. Since we are talking about relatively small LC values, the test set-up can greatly affect the measured LC values. You may build a very elaborate test fixture at your facilities and obtain very precise figures. But can every vendor or user do the same? How do we decide which values are the right ones. I believe that we need a well defined measurement methodology to be included as part of the specs. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + This is a real challenge. EIA/JC-15 has been struggling with this for packages for some time now. Capacitance is easy compared to inductance measurements. You can not measure a package or connector to get the inductances that are in the model. All measurements find the effects of all series and mutual inductances in the entire set of current loops. The values in the model are the partial parameters that work together to behave correctly. I do agree that some defined validation process should be sought but I suggest that it should measure behavior, not partial parameters. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4. Another method for model development is to use the mechanical drawings and feed the physical dimension to a field solver. If precise mechanical dimensions, including the ER of the connector body, can be provided, then a field solver can be used to extract the LC matrices. This can be an alternative to the above methods. The issue here is which field solver to use? 2D? 3D? from which CAE vendor? etc. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + I believe there are at least three major problems with this approach. First, I know we do not want to release manufacturing level drawings or files to the world. I think other companies would feel the same way. Second, field solvers are expensive, slow, require considerable expertise to use correctly, and generate very large model files. Also, there are many common structures that can not be analyzed directly with 2D solvers and the 3D solvers are really difficult to use correctly. Finally, how do you know the model is good? Validation is another expensive and time consuming engineering specialty, as is modeling. Bottom line, the suppliers should provide validated models. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ David Fogel From owner-ibis Fri Apr 12 12:04:58 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA02901 for ; Fri, 12 Apr 1996 12:04:48 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 11:54 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 11:57 PDT Message-Id: Date: Fri, 12 Apr 96 11:57 PDT From: bob@icx.com ( Bob Ross) To: dfogelx@ichips.intel.com, ibis@vhdl.org Subject: Re: comments on BIRD 31.1 David, Hank, and IBIS Team: Here are some comments on David's points. David, you have raised some good questions, and some of my responses may be controversial. However, I believe they are generally supportive and complimentary to Hank's comments which I just received. 1. One of the underlying assumptions is that the IBIS mated model captures the electrical contents of the connector without reference to any external connections. I believe that the BIRD31.1 data can be entered with that assumption. There are two further assumptions: a. The contents of the BIRD31.1 structure can be reformatted into a Spice Nodal Syntax. b. It is up to the simulator companies to correctly identify the rail connections (ground and power) and either do the analysis correctly or to transform the model internally with that assumption. Simulators vary in analysis capability and in purpose, so how this is done may differ and may be more a function of the type of analysis being done. Predefined rail connections may apply for certain classes of mated models. But as mating components extent to thousand(s) of contacts, this becomes impractical for the general case. In the case of a Spice simulator, the rail connections can be applied to the Spice connector model. To my knowledge, Spice Connector models (which include coupling between pins) do not rely on predefined rail connections. Therefore, for defining the IBIS data base for a mated models, we should assume that the rail definition is external to the mated model. 2. The mated model applies only to the "mated" configuration. So the part of any finger that extends into the connector is included in the mated model, and the part outside should be part of the circuit board physical layout. I believe designer's assume that 1/2 of the finger is inside the connector socket for optimal tolerance purposes. You have raised a fundamental question regarding how the analysis program should treat this situation and how any extending reference planes for the fingers themselves would be accounted in the matrix mated model. My presumption is that the mated model would be provided assuming the suggested finger design configuration or separate models would be provided for suggested variations. 3. I have some brief thoughts the measurement methodology question. I do not believe any stated measurement defined extraction can be defined that would work in all cases because an "ideal" test setup cannot be built. Therefore, I would rather see crisp definitions of the parameters that are needed which can be derived from any source - Spice equivalent structures, field extractors, measurements, etc. 4. Field solver extraction is an expected option. Which one is used may depend on the connector itself and what specification detail (such as "edge rate") is required in the model. For a closing comment, you have touched on some very difficult issues. With respect to mated models one key concept is that the purpose is to provide a MODEL that is suitable for the analysis that is being done. It will NOT be a perfect replication of all aspects of performance - just as any model is not a perfect representation of any particular device. So the representation must reflect a reasonable compromise between complexity and accuracy that makes it suitable for the intended purposes. The questions you raise are useful to nail down the definition and scope of the data contents of the mated model itself. Bob Ross Interconnectix, Inc. > Subject: comments on BIRD 31.1 > To: ibis@vhdl.org > Date: Thu, 11 Apr 1996 16:38:47 -0700 (PDT) > From: "David Fogel" > To: ibis@vhdl.org > Subj.: Mated connector model, BIRD 31.1 > Regarding the proposed BIRD31.1 specs, I have the following questions/comments > 1. Power and ground pins assignment will affect L,C values > 1. Ground (and power) pins assignment will affect both the self LC values > of a pin and the LC coupling matrix, based on the position of each pin > relative to the ground pins. > Consider the following three connector pins example: > o o o > ^ ^ ^ > | | | > gnd 1 2(or gnd) > The pins are 50 mils apart. > When only the center pin is a signal and the other two are ground I get: > SINGLE CONDUCTOR LC: > ____________________ > i j Lij Cij Ze Zo Se So Fwdx Rvsx > from to (nh/in) (pf/in) (ohms) (ohms) (ns/ft)(ns/ft) (s/s) (v/v) > -------------------------------------------------------------------------- > 1 1 10.537 3.066 58.63 - 2.16 - - - > ; > and when only one side pin is a ground I get: > DUAL CONDUCTOR LC: > _________________ > i j Lij Cij Ze Zo Se So Fwdx Rvsx > from to (nh/in) (pf/in) (ohms) (ohms) (ns/ft)(ns/ft) (s/s) (v/v) > -------------------------------------------------------------------------- > 1 1 15.880 3.066 88.36 - 2.16 - - - > 1 2 10.903 1.502 130.90 33.01 2.46 1.81 0.303 0.597 > 2 2 22.247 2.188 123.78 - 2.16 - - - > ; > Which clearly demonstrates the fact that you can not assign LC values to > connector pins just by their physical location in the connector. You also > need to know their position relative to the ground pins. > This can be accomplished by depicting several most likely to be used signal-gnd > configurations and providing the LC matrices to all of them. In a dual > row connector you may end up with about 10 different combinations. > This kind of information is precisely what's needed for high speed > simulations and will make the modeling effort worthwhile from system > engineering point of view. > 2. Another level of complication in a mated model is the plug-in daughter > card. The fingers themselves are part of a PC board. How long are those > fingers in the mated model? is there any definition for it? > The electrical characteristics can be affected by the presence (or absence) > of a ground plane in between the daughter cards' top and bottom layers (the > finger layers). How is this going to be reflected in the model? > 3. Another issue is measurements and verifications of the model itself. > Since we are talking about relatively small LC values, the test set-up > can greatly affect the measured LC values. > You may build a very elaborate test fixture at your facilities and obtain > very precise figures. But can every vendor or user do the same? > How do we decide which values are the right ones. I believe that we need a > well defined measurement methodology to be included as part of the > specs. > 4. Another method for model development is to use the mechanical drawings and > feed the physical dimension to a field solver. If precise mechanical dimensions, > including the ER of the connector body, can be provided, then a field solver can > be used to extract the LC matrices. This can be an alternative to the above methods. > The issue here is which field solver to use? 2D? 3D? from which CAE vendor? > etc. > David Fogel From owner-ibis Fri Apr 12 14:59:42 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA04000 for ; Fri, 12 Apr 1996 14:59:39 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 14:50 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 12 Apr 96 14:53 PDT Message-Id: Date: Fri, 12 Apr 96 14:53 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING 4/19/96 IBIS Open Forum Meeting Agenda for 4/19/96 Bridge Number Reservation # Passcode (916) 356-9200 2-66106 5576848 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. (Note, Due to Daylight Savings Time, the meeting now starts at 15:00 GMT) 8:00 Check-In, Intros, Announcements Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Rusher/Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates All - New Models Available, Library Update All - Opens for New Issues All 8:15 EIA/IBIS Activities - 1996 Membership Rusher/Hobbs - DAC EDA Standards Booth/Sign Powell - Progress on ANSI/EIA-656 Publication Rusher 8:25 Administrative and Project Discussions DAC Meeting Arrangements and Agenda Hobbs Model Reward Program Huq Web Project Update Huq Golden Parser 2.1 Status Hobbs/Ross S2IBIS 1.3 Status Ross S2IBIS 2.1 Status & Bug List Ross Express Information Model Actions Ross New Administrative Issues All 8:50 IBIS Comments on EDIF 3 9 9 Dodd/Wiens 9:00 Technical Discussion BIRD31.1 - Mated Models Ross Physical Package Committee Report Peters, etc. (BIRD33, SULTAN, EDIF, BIRD32, etc.) BIRD34.1 - Stored Charge Proposal Progress Ross EGG10 - PARSER TESTS 1-5 Rukusek/Peters New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From owner-ibis Thu Apr 18 15:43:57 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA14638 for ; Thu, 18 Apr 1996 15:43:56 -0700 (PDT) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id PAA06256 for ; Thu, 18 Apr 1996 15:34:57 -0700 Received: from cds9258.cadence.com(158.140.32.4) by mailgate.cadence.com via smap (V1.0mjr) id sma829866891.006245; Thu Apr 18 15:34:51 1996 Received: from [158.140.52.74] (mac514.cadence.com [158.140.52.74]) by cds9258.cadence.com (8.6.8/8.6.8) with SMTP id PAA19818 for ; Thu, 18 Apr 1996 15:34:48 -0700 X-Sender: debc@cds9258 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Apr 1996 14:34:45 -0800 To: ibis@vhdl.org From: debc@cadence.com (Deborah Chalmers) Subject: DAC Signs We are preparing our list of DAC signs and I have a request from you. Can you give me a bit of background on your relationship with Cadence for the paperwork I need to fill out. We have your parameters and making the sign shouldn't be a problem. Please advise. Deborah A. Chalmers Marketing Communications Manager Cadence Design Systems Phone: 408-428-5795 Fax: 408-944-0747 debc@cadence.com http://www.cadence.com From owner-ibis Mon Apr 22 03:37:44 1996 Received: from alcatel.fr (mail.alcatel.fr [193.104.30.131]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id DAA07877 for ; Mon, 22 Apr 1996 03:37:40 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.241]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id MAA29583 for ; Mon, 22 Apr 1996 12:27:34 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id MAA24775 for ; Mon, 22 Apr 1996 12:28:07 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA07812; Mon, 22 Apr 96 12:31:00 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00371; Mon, 22 Apr 96 12:30:57 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <317B5FDF.1CFBAE39@ln.cit.alcatel.fr> Date: Mon, 22 Apr 1996 12:30:55 +0200 From: FITZPATRICK John Organization: Alcatel CIT, 22304 Lannion, France X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Switched clamping diodes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Thanks to everyone who replied to my earlier mail to ibis-users. >From the answers, I don't think my 2nd point was expressed clearly enough > 2) One family of components switches out the power clamp > diode whenever the output buffer is in tri-state. This family is 5V tolerant LVC from Philips (and TI). When in 3-state, the clamping diode to Vcc is "removed". However, in active state, it is present. In the IBIS spec, it is assumed that: "the data in the clamping curve sections are handled as constantly present curves and the pullup and pulldown curves are used only when needed" This assumption is false for LVC. The clamping curves are not constantly present! A work-around for 2.1 is to put the clamping curve in with the pull-up and pull-down curves. As long as the 3-state curve is truly high-impedance, the model will be very good. For 3.0, perhaps it would it be an idea to have separate curves for active and 3-state modes? 2.1 3-state: [3-state] = [GND_clamp] + [POWER_Clamp] Active: ( [Pullup] or [Pulldown] ) + [3-state] 3.0 Proposal: 3-state: [3-state] = [GND_clamp] + [POWER_Clamp] Active: [Pullup] or [Pulldown] In order to reduce confusion, it would be better to rename [GND_clamp] and [POWER_clamp] to [3-state pullup] and [3-state pulldown]. Then, if the simulator detects the new keywords, it will know that the definition of [Pullup] and [Pulldown] has changed. In this way, a 2.1 description would still be valid in 3.0. Any comments? John -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From owner-ibis Mon Apr 22 16:44:46 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA19421 for ; Mon, 22 Apr 1996 16:44:40 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.4/10.0i); Mon, 22 Apr 1996 22:41:53 GMT Received: from ccm.fm.intel.com by fmmail.fm.intel.com (Smail3.1.28.1 #2) id m0uBUH2-000rHlC; Mon, 22 Apr 96 15:40 PDT Received: by ccm.fm.intel.com (ccmgate 3.0) Mon, 22 Apr 96 15:40:00 PST Date: Mon, 22 Apr 96 15:40:00 PST From: Arpad Muranyi Message-ID: <960422154000_5@ccm.fm.intel.com> To: owner-ibis@vhdl.org, ibis@vhdl.org Subject: Re: Switched clamping diodes Text item: John, You might understand the situation of I-V curves a little better if you compare the case of the I/O and Output only (non 3-statable) buffers. If you make a model for an output only buffer, the clamp curves will have to be part of the pullup/pulldown I-V curves. This is because you cannot 3-state the device to measure the clamps separately by themselves. (In a way both pullup or pulldown are always present together with the clamps). The quote you cited below refers to 3-statable buffers or I/O-s, in which the clamps are always present, while the driver section of the buffer may not be there all the time (when the device acts as a receiver, for example). The intention in IBIS was to separate the static "constantly present", and the switched "when needed" characteristics of the buffers somehow. Now, if you have a buffer that has a switched clamp, I don't see anything wrong with combining the switched clamp I-V curves with the pullup or pulldown I-V curves, as long as they are switched together. If they are switched separately in time, you might need to model things differently, which might not be possible with IBIS directly. If the simulator tool you are using is flexible enough, you might be able to get around this problem by making two models, one to represent the pullups/pulldowns and another to represent the clamps and then driving them with two independent clocks or enables. By the way, some 5 V safe 3.3 V buffers do have constantly present clamps, but they clamp above 5 V only. If a CMOS device has a p-channel pullup, the pullup I-V curve will cross 0 mA at 3.3 V and draw current between 3.3 and 5 V due to the symmetrical nature of the CMOS channel. I would not call this a clamp, however, since this current is part of the pullup transistor's characteristics and not it's parasitic diode or a separate ESD structure I hope this helps in clarifying the usage of I-V curves. Arpad Muranyi Intel Corporation =============================================================================== All, Thanks to everyone who replied to my earlier mail to ibis-users. >From the answers, I don't think my 2nd point was expressed clearly enough > 2) One family of components switches out the power clamp > diode whenever the output buffer is in tri-state. This family is 5V tolerant LVC from Philips (and TI). When in 3-state, the clamping diode to Vcc is "removed". However, in active state, it is present. In the IBIS spec, it is assumed that: "the data in the clamping curve sections are handled as constantly present curves and the pullup and pulldown curves are used only when needed" This assumption is false for LVC. The clamping curves are not constantly present! A work-around for 2.1 is to put the clamping curve in with the pull-up and pull-down curves. As long as the 3-state curve is truly high-impedance, the model will be very good. For 3.0, perhaps it would it be an idea to have separate curves for active and 3-state modes? 2.1 3-state: [3-state] = [GND_clamp] + [POWER_Clamp] Active: ( [Pullup] or [Pulldown] ) + [3-state] 3.0 Proposal: 3-state: [3-state] = [GND_clamp] + [POWER_Clamp] Active: [Pullup] or [Pulldown] In order to reduce confusion, it would be better to rename [GND_clamp] and [POWER_clamp] to [3-state pullup] and [3-state pulldown]. Then, if the simulator detects the new keywords, it will know that the definition of [Pullup] and [Pulldown] has changed. In this way, a 2.1 description would still be valid in 3.0. Any comments? John -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: Switched clamping diodes To: ibis@vhdl.org Mime-Version: 1.0 X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c) Organization: Alcatel CIT, 22304 Lannion, France From: FITZPATRICK John Date: Mon, 22 Apr 1996 12:30:55 +0200 Message-Id: <317B5FDF.1CFBAE39@ln.cit.alcatel.fr> Sender: fitzpat1@ln.cit.alcatel.fr Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00371; Mon, 22 Apr 96 12:30:57 +0200 Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA07812; Mon, 22 Apr 96 12:31:00 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id MAA24775 for ; Mon, 22 Apr 1996 12:28:07 +0200 (METDST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.241]) by mailg ate.alcatel.fr (8.7.3/8.7.3) with ESMTP id MAA29583 for ; Mon, 22 Apr 1996 12:27:34 +0200 Received: from alcatel.fr (mail.alcatel.fr [193.104.30.131]) by vhdl.vhdl.org (8 .7.3/8.7.3) with ESMTP id DAA07877 for ; Mon, 22 Apr 1996 03:37:4 0 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.7.4/8.7.3) with ESMTP id DAA22346; Mon, 22 Apr 1996 03:35:11 -0700 (PDT) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.192.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id DAA20722; Mon, 22 Apr 1996 03: 35:55 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Apr 23 01:02:13 1996 Received: from alcatel.fr (mail.alcatel.fr [193.104.30.131]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id BAA22488 for ; Tue, 23 Apr 1996 01:02:10 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.241]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id JAA12645 for ; Tue, 23 Apr 1996 09:51:58 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id JAA17527 for ; Tue, 23 Apr 1996 09:52:34 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA21489; Tue, 23 Apr 96 09:55:28 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01610; Tue, 23 Apr 96 09:55:26 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <317C8CED.284797A9@ln.cit.alcatel.fr> Date: Tue, 23 Apr 1996 09:55:25 +0200 From: FITZPATRICK John Organization: Alcatel CIT, 22304 Lannion, France X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Re: Switched clamping diod Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Thanks to Arpad and Andy for very informative replies to my question on how to use pullup and clamping curves. I've forwarded the answers to the component manufacturer in question. Hopefully, when he sees what feedback can be had, he'll join the list himself. I guess that what worried me was the assumption that there is a constantly present curve. Seeing what gymnastics manufacturers do to keep 5V tolerance, I wonder if this assumption will always be true? But now is not the time for hypothetical situations. Back to the real problem of getting any ol' IBIS model at all at all... Merci encore, John -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From owner-ibis Tue Apr 23 06:32:25 1996 Received: from center.farside.net (bin@center.farside.net [194.163.159.200]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA01149 for ; Tue, 23 Apr 1996 06:32:22 -0700 (PDT) From: olaf@pad.incases.com Received: (from bin@localhost) by center.farside.net (8.7.5/8.7.2) id PAA00597 for ; Tue, 23 Apr 1996 15:23:10 +0200 (MET DST) Received: from isdn.pad.incases.com(194.64.13.226) by center.farside.net via smap (V1.3) id sma000592; Tue Apr 23 15:23:00 1996 Received: from pluto.incases.com by mail.pad.incases.com with smtp (Smail3.1.28.1 #3) id m0uBi3I-00045PC; Tue, 23 Apr 96 15:22 MET DST Received: by pluto.incases.com (4.1) id AA11779; Tue, 23 Apr 96 15:22:44 +0200 Message-Id: <9604231322.AA11779@pluto.incases.com> Subject: Express Information Model To: ibis@vhdl.org Date: Tue, 23 Apr 1996 15:22:43 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hello all, today, I found an information-model of IBIS (2.0) on 'vhdl.org/pub/die/express'. The author of this document is Alan Williams of the University of Manchester. Maybe, this information is useful for the standardization process of ibis and we may contact Alan Williams for further assistance? Olaf From owner-ibis Tue Apr 23 06:37:27 1996 Received: from gate.ti.com (news.ti.com [192.94.94.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA01163 for ; Tue, 23 Apr 1996 06:37:26 -0700 (PDT) Received: from kadet.asic.sc.ti.com ([156.117.182.198]) by gate.ti.com (8.6.13/ac3i.dseg.ti.com) with ESMTP id IAA08652 for ; Tue, 23 Apr 1996 08:27:54 -0500 Received: from sho.asic.sc.ti.com (sho.asic.sc.ti.com [156.117.182.238]) by kadet.asic.sc.ti.com (8.6.10/8.6.6) with ESMTP id IAA19518 for ; Tue, 23 Apr 1996 08:27:09 -0500 Received: from localhost (andresen@localhost) by sho.asic.sc.ti.com (8.6.4/8.6.4) id IAA12489 for ibis@vhdl.org; Tue, 23 Apr 1996 08:27:08 -0500 Date: Tue, 23 Apr 1996 08:27:08 -0500 From: Ben Andresen Message-Id: <199604231327.IAA12489@sho.asic.sc.ti.com> To: ibis@vhdl.org Subject: Re: Switched clamping diodes Since TI was mentioned in the earlier msg from John I want to clarify the switching clamp diode situation as far as our clamp diodes are concerned. All 5V tolerant ASIC I/O with clamp diodes have the diode continuously attached to the 5V supply. Arpad's description is exactly how the TI ASIC circuits perform. The only exceptions are the universal PCI buffers which have diodes to the VI/O supply which could be either 3V or 5V. Those diodes are also continuously attached to VI/O. Ben Andresen andresen@asic.sc.ti.com > From owner-ibis@vhdl.vhdl.org Mon Apr 22 18:40:27 1996 > To: owner-ibis@vhdl.org, ibis@vhdl.org > Subject: Re: Switched clamping diodes > > > Text item: > > John, > > You might understand the situation of I-V curves a little better if you compare > the case of the I/O and Output only (non 3-statable) buffers. > > If you make a model for an output only buffer, the clamp curves will have to be > part of the pullup/pulldown I-V curves. This is because you cannot 3-state the > device to measure the clamps separately by themselves. (In a way both pullup or > pulldown are always present together with the clamps). > > The quote you cited below refers to 3-statable buffers or I/O-s, in which the > clamps are always present, while the driver section of the buffer may not be > there all the time (when the device acts as a receiver, for example). The > intention in IBIS was to separate the static "constantly present", and the > switched "when needed" characteristics of the buffers somehow. > > Now, if you have a buffer that has a switched clamp, I don't see anything wrong > with combining the switched clamp I-V curves with the pullup or pulldown I-V > curves, as long as they are switched together. If they are switched separately > in time, you might need to model things differently, which might not be possible > with IBIS directly. If the simulator tool you are using is flexible enough, you > might be able to get around this problem by making two models, one to represent > the pullups/pulldowns and another to represent the clamps and then driving them > with two independent clocks or enables. > > By the way, some 5 V safe 3.3 V buffers do have constantly present clamps, but > they clamp above 5 V only. If a CMOS device has a p-channel pullup, the pullup > I-V curve will cross 0 mA at 3.3 V and draw current between 3.3 and 5 V due to > the symmetrical nature of the CMOS channel. I would not call this a clamp, > however, since this current is part of the pullup transistor's characteristics > and not it's parasitic diode or a separate ESD structure > > I hope this helps in clarifying the usage of I-V curves. > > Arpad Muranyi > Intel Corporation > =============================================================================== > > All, > > Thanks to everyone who replied to my earlier mail to ibis-users. > > >From the answers, I don't think my 2nd point was > expressed clearly enough > > > 2) One family of components switches out the power clamp > > diode whenever the output buffer is in tri-state. > > This family is 5V tolerant LVC from Philips (and TI). When in > 3-state, the clamping diode to Vcc is "removed". However, in > active state, it is present. > > In the IBIS spec, it is assumed that: > "the data in the clamping curve sections are handled > as constantly present curves and the pullup and > pulldown curves are used only when needed" > > This assumption is false for LVC. The clamping curves are not > constantly present! > > A work-around for 2.1 is to put the clamping curve in with the > pull-up and pull-down curves. As long as the 3-state curve is > truly high-impedance, the model will be very good. > > For 3.0, perhaps it would it be an idea to have separate curves > for active and 3-state modes? > > 2.1 > 3-state: [3-state] = [GND_clamp] + [POWER_Clamp] > Active: ( [Pullup] or [Pulldown] ) + [3-state] > > 3.0 Proposal: > 3-state: [3-state] = [GND_clamp] + [POWER_Clamp] > Active: [Pullup] or [Pulldown] > > In order to reduce confusion, it would be better to rename > [GND_clamp] and [POWER_clamp] to [3-state pullup] and > [3-state pulldown]. Then, if the simulator detects the new keywords, > it will know that the definition of [Pullup] and [Pulldown] > has changed. In this way, a 2.1 description would still be valid > in 3.0. > > Any comments? > John > > > > -- > John Fitzpatrick > Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France > Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=us-ascii > Subject: Switched clamping diodes > To: ibis@vhdl.org > Mime-Version: 1.0 > X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c) > Organization: Alcatel CIT, 22304 Lannion, France > From: FITZPATRICK John > Date: Mon, 22 Apr 1996 12:30:55 +0200 > Message-Id: <317B5FDF.1CFBAE39@ln.cit.alcatel.fr> > Sender: fitzpat1@ln.cit.alcatel.fr > Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) > id AA00371; Mon, 22 Apr 96 12:30:57 +0200 > Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) > id AA07812; Mon, 22 Apr 96 12:31:00 +0200 > Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by > nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id MAA24775 for ; Mon, > 22 Apr 1996 12:28:07 +0200 (METDST) > Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.241]) by mailg > ate.alcatel.fr (8.7.3/8.7.3) with ESMTP id MAA29583 for ; Mon, 22 > Apr 1996 12:27:34 +0200 > Received: from alcatel.fr (mail.alcatel.fr [193.104.30.131]) by vhdl.vhdl.org (8 > .7.3/8.7.3) with ESMTP id DAA07877 for ; Mon, 22 Apr 1996 03:37:4 > 0 -0700 (PDT) > Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c > om (8.7.4/8.7.3) with ESMTP id DAA22346; Mon, 22 Apr 1996 03:35:11 -0700 (PDT) > Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.192.4]) > by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id DAA20722; Mon, 22 Apr 1996 03: > 35:55 -0700 (PDT) > Return-Path: owner-ibis@vhdl.vhdl.org > From owner-ibis Tue Apr 23 08:31:21 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id IAA01874 for ; Tue, 23 Apr 1996 08:31:21 -0700 (PDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id IAA09546; Tue, 23 Apr 1996 08:22:21 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id IAA16875; Tue, 23 Apr 1996 08:22:16 -0700 (PDT) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Tue, 23 Apr 96 08:22:15 PDT Date: Tue, 23 Apr 96 08:18:00 PDT From: Will Hobbs Message-ID: To: owner-ibis@vhdl.org, ibis@vhdl.org Subject: Re: Express Information Model Text item: Olaf, Does it appear fairly complete? Is there any pointer to Alan's e-mail so we can contact him? Will Hello all, today, I found an information-model of IBIS (2.0) on 'vhdl.org/pub/die/express'. The author of this document is Alan Williams of the University of Manchester. Maybe, this information is useful for the standardization process of ibis and we may contact Alan Williams for further assistance? Olaf Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Type: text X-Mailer: ELM [version 2.4 PL23] Date: Tue, 23 Apr 1996 15:22:43 +0200 (MET DST) To: ibis@vhdl.org Subject: Express Information Model Message-Id: <9604231322.AA11779@pluto.incases.com> Received: by pluto.incases.com (4.1) id AA11779; Tue, 23 Apr 96 15:22:44 +0200 Received: from pluto.incases.com by mail.pad.incases.com with smtp (Smail3.1.28.1 #3) id m0uBi3I-00045PC; Tue, 23 Apr 96 15:22 MET DST Received: from isdn.pad.incases.com(194.64.13.226) by center.farside.net via sma p (V1.3) id sma000592; Tue Apr 23 15:23:00 1996 Received: (from bin@localhost) by center.farside.net (8.7.5/8.7.2) id PAA00597 f or ; Tue, 23 Apr 1996 15:23:10 +0200 (MET DST) From: olaf@pad.incases.com Received: from center.farside.net (bin@center.farside.net [194.163.159.200]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA01149 for ; Tue, 23 Apr 1996 06:32:22 -0700 (PDT) Received: from vhdl.vhdl.org by hermes.intel.com (8.7.4/10.0i); Tue, 23 Apr 1996 08:10:42 -0700 Received: from hermes.intel.com by ichips.intel.com (8.7.4/jIII) id IAA20407; Tue, 23 Apr 1996 08:09:29 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by relay.jf. intel.com (8.7.4/8.7.3) with ESMTP id IAA14979; Tue, 23 Apr 1996 08:10:44 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Apr 23 13:20:11 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA04117 for ; Tue, 23 Apr 1996 13:20:00 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 23 Apr 96 13:10 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 23 Apr 96 13:13 PDT Message-Id: Date: Tue, 23 Apr 96 13:13 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 4/19/96 DATE: April 23, 1996 SUBJECT: 4/19/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann* Cadence Design C. Kumar* Contec CAE, Ltd. Dileep Divekar*, Norio Matsui Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier* Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet*, Donald Telian, Jim Kruchowski Interconnectix, Inc. Bob Ross* Meta-Software (Les Spruiell) Mitsubushi Tam Cao Motorola Ahmed Omer* National Semiconductor Syed Huq*, Donald Snyder, Chune-Sin Yeh NCR (formerly ATT-GIS) Dave Moxley, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell, Chris Rokusek* Quantic Labs (Mike Ventham) Tanner Research, Inc. (Scott Wedge) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia VLSI Technology Dick Ulmer, Sung Oh*, Swami Gangadharan, Daniel Kim, Tom Dockery Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard* Digital Equipment Corp. Jeff Chu* EIA Patti Rusher* IC Works Eric Chen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella* North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison Veribest/Integraph Ian Dodd, David Wiens Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 5/10/96 (916) 356-9200 2-66109 4323275 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 Gus Panella of Molex joined because of recent IBIS interest. Gus has been involved for many years with electromagnetic extraction of connector model information. EIA MEMBERSHIP AND TREASURER'S REPORT Patti Rusher received membership requests from Jeff Chu of Digital Equipment and Ian Dodd of Veribest. Patti Rusher estimated the treasury at $6000, with $2500 pending for DAC participation. (After the meeting, Patti updated the actual number to be $12,488.59. DAC booth participation expense reduces this to $9,988.59.) MINUTES REPORT, MISC. No Corrections. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Patti Rusher has written a correction letter to EDN indicating that IBIS has been formally ratified by EIA and ANSI. NEW MODELS Bob Ross reports that VLSI has submitted information to Michael Steer, although it has not yet been posted on vhdl.org. AR - Bob Ross investigate posting of VLSI information. OPENS FOR NEW ISSUES None. EIA/IBIS 1996 MEMBERSHIP Patti Rusher indicates about 5 or 6 outstanding invoices, although she has to verify with accounting the most recent status. AR - Bob Ross continue working with Patti Rusher to monitor the payment for official EIA/IBIS Committee Membership. DAC STANDARDS BOOTH Patti Rusher is coordinating the booth with Jon Powell. It will have a back-lit logo and poster. We still should send the 8-1/2" by 11" posters with Velcro backing to Jon. You can also take them to DAC if you will be at DAC the first day. Pat Manley, a graphics artist at the advertising agency doing the other EIA work will create an electronic combination of logos. Send electronic version of logos to adgroup@aol.com Patti received the IBIS bullet items information from Bob Ross for the poster. Since this is coordinated with Jon Powell, Patti and Jon need to work out the exact process for the posters and communicate it to the reflector. (Also pending are the "I Speak IBIS" badges.) ANSI/EIA-656 PUBLICATION Patti Rusher reports that the published version of ANSI/EIA-656 has been sent to member companies. Several members have reported getting a copy. AR - EIA/IBIS Members: if you have not received your copy, notify Patti. DAC (DESIGN AUTOMATION CONFERENCE) MEETING ARRANGEMENTS AND AGENDA Patti Rusher reports that Ron Werner is planning a Standards Roadmap Birds of the Feather meeting on Thursday, June 6, 1996 between 6 PM and 8 PM. We will participate in this rather than doing our own BOF session because IBIS is now quite well-known. We will hold the DAC IBIS Meeting on Friday morning, June 7, 1996, and allowing time for people to return that afternoon. Past DAC meetings have been focused on ratification and administrative issues versus technical issues. However, since we have only a few administrative issues and some pending technical development, we probably will have some technical discussions. We are seeking company sponsors for the meeting which usually involves booking a room and providing some refreshments. Chris Rokusek of Quad Design, Will Hobbs of Intel, and C. Kumar of Cadence all check on sponsoring the Face-to-Face meeting. We estimate about 25 participants. A fallback plan is to use IBIS funds. AR - Chris Rokusek, Will Hobbs, and C. Kumar obtain closure by April 26 regarding hosting the meeting. MODEL REWARD PROGRAM Syed Huq reintroduced the program to reward companies which provide free, public IBIS models. We decided to issue certificates of appreciation to be presented at the IBIS meeting to the companies which provide such models along with acknowledgment in a press release. This certificate would be signed by EIA officers and Will Hobbs. Several organizations providing free models and free utilities were mentioned. Patti Rusher, Syed Huq, and Bob Ross will work off line to identify the recipients. Many IBIS models are also available through direct contact with companies. Bob Ross is interested in identifying these contacts and publicizing them. AR - Bob Ross post a request for anyone to submit possible contact people who have IBIS models for distribution. Appropriate contacts for getting IBIS models will be published on vhdl.org. EIA WEB UPDATE No change. Over 860 people have hit the page. GOLDEN PARSER UPDATE The Parser has been sent out. Patti Rusher has paid the submitted bill. AR - Bob Ross will check out the new parser. AR - Jon Powell create new executable and work with Bob to update the information on vhdl.org. SPICE TO IBIS VERSION 1.3 Bob Ross has put the new version on vhdl.org. SPICE TO IBIS VERSION 2.1 Michael Steer reported privately that he will plan an upgrade. AR - Bob Ross work with Michael Steer concerning the s2ibis2.1 upgrade. EXPRESS ACTION ITEMS Patti Rusher reports that ANSI/EIA-656 has been put forth for international standardization under TC-93. An Express representation is required. The pending EDIF 4 0 0 has an Express representation as does several other EDA standards. Anyone within the IBIS community may propose doing an Express representation. We are also seeking a proposal from Hilary Kahn from the University of Manchester, UK, an Express expert who is familiar with IBIS. DARPA funding may also be available for such a project. AR - Patti Rusher request a proposal from Hilary Kahn and also copy Randy Harr to inquire about the possibility of DARPA funding. [Done] IBIS COMMENTS ON EDIF 3 9 9 Stephen Peters discussed the comments by David Wiens. Several vendors are seriously considering interfacing to EDIF 4 0 0. The main concerns are to have EDIF syntax to reference IBIS models and to reduce the redundant ways to reference passive R, L, C components. The comments will be adopted as an IBIS committee position. Patti Rusher wants the comments as early as possible so that the EDIF technical group can move forward on them within the introduction schedule. Patti also indicates that Hilary Kahn has a sample PCB description that may be posted on the reflector. AR - Stephen Peters work with David Wiens to finalize the response and copy Patti Rusher and post the official comment on the Reflector. BIRD31.1 - MATED MODELS Bob Ross recapped the key points of BIRD31.1. The mated model will be in a separate .mmf file and not in a .ibs file. BIRD31.1 will track any approved package model development beyond BIRD28.3. BIRD31.1 is a two-terminal syntax for similar capability. One addition is optional a pad capacitance. Some reflector comments by Hank Herrman and David Fogel were noted. The first point concerns Hank's proposal to add an edge rate parameter to the mated model. His main point is that, unlike a package model which is assumed to be associated with a particular die and therefore constructed with correspondingly adequate detail, there is no way to determine the intended performance limit of a mated model. If the edge rate is too fast, the model may simulate too much ringing. Bob Ross argued against the additions by stating these points: (1) There already exists a required [Description] parameter where such information could be presented in a manner similar to comment lines in Spice programs. (2) In any case, simulators would not be able to do anything about non-compliance. (3) There is no parallel counterpart for package models. (4) It is unclear which limit to use - the largest time for which one "stage" would give adequate limits, or the smallest time for which an infinitely distributed stage would gives an accurate structure. Hank clarified that this would be a model structure limit - the smallest time would apply before a more complicated model would be appropriate. After some more discussion and support by Gus Panella and Stephen Peters, Bob agreed to add an edge rate specification subparameter. The second point relates to defining the mated model physical limits. With an edge card connector the circuit board fingers which could also have their own ground plane extendions into the connector. The consensus was that the mated model would end at the surface of the mated-model. The mated model contains the optional C_pad1 and C_pad2 to provide an estimate of adjoining PCB pad capacitances that are typically not within the mated model. Because of historical evolution from the simplest L_pkg, R_pkg, C_pkg structures to the more complicated coupled matrix models, the package model already provides for such pad capacitances. Stephen questioned whether the mated model should apply for sockets. IBIS models for the Pentium Pro includes the socket within the package model. When the socket is modeled as a mated model, the package parameters of the device to be inserted into the socket may contain inappropriate, excessive information. However, independent socket models are still needed. So we agreed to continue including sockets within the mated model syntax. Bob Ross will issue BIRD31.2 adding the edge rate limit parameter and clarifying the mated model boundaries. BIRD33 (EGG8) - PHYSICAL PACKAGE DISCUSSION Stephen Peters reported that the package committee endorsed the EDIF 4 0 0 approach for physical representation. Future discussion will be on electrical representations. Two possibilities include a Spice-like approach by C. Kumar and a sement approach by Jon Powell. While syntactically different, these approaches have similarities with respect to transmission line and nodal structures. They both can handle general topologies which include forks and possibly closed loops. Stephen indicated that handling ball grid array packages with stub elements is a real necessity. He also has a proposal which extends the existing BIRD28.3 structure to include forks and nodes. The next meeting will be on Thursday, May 2, 1996. BIRD34.1 (EGG9) - HANDLING STORED CHARGE Bob Ross plans to send an HSPICE example which illustrates the BIRD34.1 proposal. Simulations of the equations in the proposal match the Spice diode model simulations. C. Kumar advised Bob of a recent March, 1996 paper in the IEEE Circuits and Systems Transactions on diode modeling including stored charge effects. EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING Chris Rokusek mentioned the two key items: A check is needed to assure that the [Rising Waveform] and [Falling Waveform] voltage ranges for given fixture provide ranges consistent with the V/I tables. Also, Stephen Peters proposes a units check for realistic values - a common trap. Bob Ross pointed out that this test needs to be based on actual values since the parser already process the numerical information. More time will be available at the next meeting for discussion. NEXT MEETING: The next telephone meeting is set for Friday, May 10, 1996. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Server Chipset System Validation Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Tue Apr 23 22:26:14 1996 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id WAA07215 for ; Tue, 23 Apr 1996 22:26:12 -0700 (PDT) Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id WAA17139 for ; Tue, 23 Apr 1996 22:13:45 -0700 (PDT) Received: from localhost (precise@localhost) by web1.calweb.com (8.7.3/8.7.3) with SMTP id WAA03171 for ; Tue, 23 Apr 1996 22:16:38 -0700 (PDT) X-Authentication-Warning: web1.calweb.com: precise owned process doing -bs Date: Tue, 23 Apr 1996 22:16:38 -0700 (PDT) From: "Paul A. Munsey" To: IBIS Reflector Subject: New name and email address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII IBISians, This is to notify you that I've changed my business name and email address. All IBIS source code files refer to me at: PC Ware of Roseville California, 73053.721@compuserve.com The new and correct information is now: Precision Works, precise@calweb.com I'll be closing my compuserve account very soon so future mail sent to me there will not reach me. My home address and phone number are still the same. Thank you, Paul Munsey From owner-ibis Wed Apr 24 16:17:49 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA22251 for ; Wed, 24 Apr 1996 16:17:46 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Apr 96 16:07 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Apr 96 16:10 PDT Message-Id: Date: Wed, 24 Apr 96 16:10 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Express Representation Cc: alanrw@cs.man.ac.uk, hkahn@cs.man.ac.uk, rharr@arpa.mil, trtrthurma@cacd.rockwell.com To IBIS Committee: I have put an Express representation of IBIS Version 2.0 that was done in June of 1994 on vhdl.org under /pub/ibis/wip along with a permission document allowing people to use the document for review and standardization activities. The "ibisexpr.ps.Z" has been transformed to make it suitable for US Letter-sized printing. Thanks to Olaf Rethmeier for originally pointing out the existence of this document. It serves as a very good example of the Express format. The document is 69 pages with definitions, relationships and graphical representations. I plan to provide a very thorough technical review of the contents with the expectation that it be upgraded to represent IBIS Version 2.1. Anyone else is welcome to review the document and provide comments. Please send me any of your comments. Note, the pending EDIF 4 0 0 uses an Express representation. Attached is some recent correspondence related to these matters. Bob Ross Interconnectix, Inc. ---------------------------- Forwarded with Changes --------------------------- From: kahn@cs.man.ac.uk at SMTPGATE Date: 4/24/96 12:55PM To: Will Hobbs at JFCCM16 Subject: Re: Express format for IBIS/EIA-656 ------------------------------------------------------------------------------- Alan Williams, who works in my research group, has passed your message on to me. As I am sure you are aware, here in Manchester we are closely involved in information modelling and in the development of standards such as EDIF. We have been aware of IBIS for some time (and as a member of TC93 and convenor of WG3 - I was indeed aware of the standarization route being followed). I am not able to commit much of Alan's time directly to new modelling work at present (he is full time on another contract), but we will of course be delighted to help as much as we can. We feel that the model Alan did needs to be properly reviewed by IBIS experts as soon as possible - and we are happy to take comments and try where we can to accommodate them. If it turns out that a lot needs to be done to get the IBIS model fully correct, we will need to revisit the topic. Longer term it seems a good idea to help ensure that EDIF and IBIS are linked appropriately so I suspect we should be keeping in touch about that too. Hope this helps Hilary Kahn >From Will_Hobbs@ccm.jf.intel.com Tue Apr 23 22:21:06 1996 >Date: Tue, 23 Apr 96 14:18:00 PDT >From: Will Hobbs >To: alanrw@cs.man.ac.uk >Cc: bob@icx.com >Subject: Express format for IBIS/EIA-656 >Content-Length: 925 > > >Alan, > >Olaf Rethmeier of Incases in Germany found that you have created an >Express formatted version of IBIS V2.0. As you know (being a principal >reviewer), we have achieved U.S. standardization of the specification, >and it is now known as ANSI EIA-656. We have filed for international >ratification (proposal TC-93) for the spec and received the feedback >that an Express version is desirable. Bob Ross, our secretary, has >looked your document over and feels it is relatively complete and an >excellent starting point for the Express request, though it is for IBIS >2.0. > >Would you be willing for us to use your work as a basis for our >standardization work? Would you be interested in working with us to >bring it up to full EIA-656 completion? > >Bob Ross will contact you on technical matters if you are interested and >willing. > >Best regards, > >Will Hobbs >Chair, EIA IBIS Committee and >Chipset SV Manager, Intel Corp. >------------- End Forwarded Message ------------- > > -------------------------------------------------------------------------- Professor Hilary J. Kahn Director: EDIF Technical Centre Dept. of Computer Science Tel: +44 161 275 6156 University of Manchester Fax: +44 161 275 6280 Oxford Road e-mail: hkahn@cs.man.ac.uk Manchester M13 9PL UK -------------------------------------------------------------------------- From owner-ibis Wed Apr 24 16:28:48 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA22307 for ; Wed, 24 Apr 1996 16:28:45 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Apr 96 16:19 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 24 Apr 96 16:22 PDT Message-Id: Date: Wed, 24 Apr 96 16:22 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING CHANGE To IBIS Members: This is early notification that the Phone meeting scheduled for Friday, May 10 has been moved to Friday, May 17, 1996 to avoid some schedule conflicts and to better position it 3 weeks before the Design Automation Conference Friday, June 7, 1996 Face to Face Meeting. I hope this does not cause any inconvenience. Bob Ross Interconnectix, Inc. From owner-ibis Thu Apr 25 13:03:45 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA07340 for ; Thu, 25 Apr 1996 13:03:43 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 25 Apr 96 12:48 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 25 Apr 96 12:51 PDT Message-Id: Date: Thu, 25 Apr 96 12:51 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, moxley@eagle.ColumbiaSC.NCR.COM Subject: Re: IBIS GP 2.1.11 Source Cc: jonp@qdt.com Dave Moxley and Jon Powell: Dave, thanks for the valuable hint. I also was successful and have checked it against the filed bugs. All the bugs are fixed. Jon, could you make the executables that we can put on vhdl.org? Bob Ross, Interconnectix, Inc. > To: Will Hobbs > Subject: IBIS GP 2.1.11 Source > Cc: bob@icx.com > Status: RO > Hello Will, > It may have been previously reported that the diskette contains two files, > copyof~1.c and copyof~1.h, that prevent a successful compile. Just deleting them > works. Otherwise preliminary testing looks good. > Dave > moxley@eagle.columbiasc.ncr.com From owner-ibis Mon Apr 29 09:40:07 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA27444 for ; Mon, 29 Apr 1996 09:39:58 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 Apr 96 09:30 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 Apr 96 09:33 PDT Message-Id: Date: Mon, 29 Apr 96 09:33 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBISCHK2 EXECUTABLES To All: The new Version 2.1.11 ibischk2 executables for various systems are now available on vhdl.org under /pub/ibis/ibischk2. The previous version is stored under the same directory under v2_1_10.old. Thanks to Chris Rokusek of Quad Design for creating these. Bob Ross Interconnectix, Inc. From owner-ibis Mon Apr 29 11:33:42 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA28305 for ; Mon, 29 Apr 1996 11:33:21 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 Apr 96 11:23 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 Apr 96 11:26 PDT Message-Id: Date: Mon, 29 Apr 96 11:26 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD31.2 - Mated Models To IBIS Members: Based on discussions and prior e-mail on BIRD31.1, BIRD31.2 now contains the new subparameter Tedge_rate and more discussion on the mated model boundary. Since a numerical value of Tedge_rate is required, the extraction needs to be defined. The proposal below contains a method that is based on a discussion with Hank Herrmann of AMP that will be consistent for single line and coupled line models. Therefore, the existence of a Tedge_rate value does not guarentee that the model has coupling information. The rough guidance is that based on an "impedance measurement", Tedge_rate is the minimum edge rate for which the time-domain impedance response is within 10% of the actual impedance. At faster edge rates, structural discontiuities that exist in the physical device will show up which may not be captured by the model driven by that faster edge rate signal. That is the point at which a structural change (more detail) is needed. The "impedance measurement" is a dynamic measurement of both the voltage at the input and the current into the connector. The ratio of these two tables provides an "impedance profile". The test condition is to have the source and load sides terminated with 50 ohms and to have all other lines connected to ground. By doing it this way, the single line models and coupled line models of similar structural detail have the same "impedance" responses. Tedge_rate will be specified as the 20% to 80% duration so that it could be more readily extracted in a noisy simulation. It is also consistent with ECL technology definitions and with the dV/dt_r and dV/dt_f sub- parameters. A value of "0" is an indication that the information is not available. If the model is adequate for all edge rates, then an arbitrarily small value should be entered such as "1f" for one femto-second. The changes related to BIRD31.2 are designated by "|*2" comment lines. Some of the discussion in the ANALYSIS PATH ... section at the end might be added to the NOTES ON DATA DERIVATION portion of the IBIS document. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 31.2 ISSUE TITLE: Mated Models REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 11/22/95, 3/18/96, 4/29/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: No guidance is given within IBIS with respect to modeling connectors, cables and sockets used to connect boards to boards and boards to components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: "Mated model" text is blended within the original PACKAGE MODELING section, and the section is renamed as PACKAGE, CONNECTOR, CABLE AND SOCKET MODELS. The whole section is presented with BIRD28.3 extensions and additional changes noted by "|*" lines. (References to the "PACKAGE MODELING" section elsewhere would be changed to the new title. These are not shown.) |============================================================================= | |* PACKAGE, CONNECTOR, CABLE, AND SOCKET MODELING |* |* This section describes the [Define Package Model] syntax and its matrix, |* transmission line, and discrete element extension formats. This section |* also describes [Define Mated Model] as a generic class of I/O terminal |* extensions which can be used to describe the electrical characteristics |* of connectors, sockets, and cables. These can be referred to as "mated |* models" because the are used to provide the interconnection between circuit |* boards through connectors or cables, and also between boards and components |* through sockets. |* |* The electrical format for data is identical. Some operational details |* and syntax are noted. |* | The [Package Model] keyword is optional. If more than the default RLC |* package model is desired, use the [Define Package Model] keyword. There |* is no reference within the [Component] keyword to any connector model. |* The information within the [Define Mated Model] is available to |* simulators to define the interconnections using the simulator-specific |* syntax and interfaces. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... |* [End Package Model] keywords for each package model that is defined. |* However, the mated model keywords can exist only in a separate |* .mmf, and not in a .ibs or .pkg file. It exits |* between the [Define Mated Model] ... [End Mated Model] keywords for each |* connector that is defined. For reference, the keywords are listed |* below. Full descriptions follow. |* Simulators that do not support these keywords will ignore all entries between |* the [Define Package Model] and [End Package Model] keywords or between the |* [Define Mated Model] and [End Connector Model] keywords. |* | |* [Define Package Model] Required if the [Package Model] keyword is used |* [Define Mated Model] (note 3) | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) |** BIRD28.3 ADDITION BELOW |** [Number of Sections] (optional) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) |* [Model Data] (note 4) |* [Resistance Matrix] (note 4, optional) |* [Inductance Matrix] (note 4) |* [Capacitance Matrix] (note 4) |* [Bandwidth] (note 4, required for Banded_matrix matrices only) |* [Row] (note 4) |* [End Model Data] (note 4) |* [End Package Model] (note 2) |* [End Mated Model] (note 3) | |* (note 1) Required when the [Define Package Model] or [Define Mated Model] |* keyword is used |* (note 2) Required for ending a package model definition |* (note 3) Required for beginning and ending a mated model definition |* (note 4) Used only when the [Model Data] ... [End Model Data] is used |* | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | |* USAGE RULES FOR THE .PKG AND .MMF FILES | | Package models are stored in a file whose name looks like: | .pkg. |* |* Mated models are stored in a file whose name looks like: | .mmf. | | The provided must adhere to the General Syntax Rules. Use the |* ".pkg" extension to identify files containing package models. Use the |* ".mmf" extension to identify files containing mated models. The .pkg and |* .mmf files | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment Char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg |* or .mmf files. The .pkg file is for package models only. The .mmf file |* is used for mated models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |*============================================================================= |* Keyword: [Define Mated Model] |* Required: Yes |*2 Sub-params: Tedge_rate, Cpad_1, Cpad_2 |* Description: Marks the beginning of a mated model description. |* Usage Rules: If the .mmf file contains data for more than one mated model, |* each section must begin with a new [Define Mated Model] |* keyword. The length of the mated model name must not |* exceed 40 characters in length. Blank characters are |* allowed. |* |*2 The Tedge_rate is as a required subparameter defining the |*2 the minimum time edge rate for which the mated model is |*2 considered accurate under test fixture conditions. A more |*2 detailed mated model topology would be preferred if the edge |*2 rate were smaller. The Tedge_rate subparameter may serve |*2 to produce a warning that the simulations are being done |*2 outside of the mated model performance range. |*2 |*2 A numerical value must be defined. It is the input pulse |*2 rise time defined between the 20% and 80% points. |*2 This value will be the minimum value where the signal line |*2 "impedance" is within 10% of the simulated impedance. This |*2 impedance parameter is the dynamic ratio at the mated model |*2 input voltage to input current over time under the condition |*2 that the signal line has a source and load termination of |*2 of 50 ohms and all other lines are grounded. A value of 0 |*2 is permitted, and would serve as an indication that no |*2 performance limit is available. However, if the model is |*2 suitable for all edge rates, use a very small, non-zero |*2 value such as 1e-15 seconds. |*2 |* The Cpad_1 and Cpad_2 subparameters are optional and define |* default pad capacitances at sides 1 and 2 of the mated model. |* The values default to 0 pF if omitted. However, in all cases |* the simulator may override the default values based on |* actual geometrical pad dimensions. |*2 |*2 Other Notes: The mated model extends to the physical surfaces of the |*2 structure in the mated configuration. For example, the |*2 the printed circuit board fingers of an edge card connector |*2 that extend into the connector are included in the mated |*2 model electrical description. The Cpad_1 and Cpad_2 sub- |*2 parameters are optional default extensions for pads outside |*2 the mated model physical dimensions. |*------------------------------------------------------------------------------ [Define Mated Model] CONN4X40 Tedge_min = 0.1nS | Cpad_1 = .5pF Cpad_2 = 1.0pF |* |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package |* or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs and .pkg files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes |* Description: Declares the manufacturer of the package or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs and .pkg | files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of |* what kind of package the [Package Model] or mated model is |* representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package |* stub' or mated model. | A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |* This keyword also defines the number of sections that make up |* a mated model. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |****************************************************************************** |****************************************************************************** |* BIRD28.3 REPLACEMENT BELOW |****************************************************************************** |****************************************************************************** |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package |* or mated model | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section |* of a pin's die to pin connection or mated model connection. | Sub-Params: Len, L, R, C, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. |* |* For package models, the first column is used for listing each |* pin. For mated models, the first and second columns are used |* to list the side 1 pins and the corresponding side 2 pins. |* Normally the side 2 listing is the same as the side 1 listing. |* However, for cables and connectors that crossover or have |* different pin names or groupings at either end, the two columns |* will have different entries. All Matrix references will be |* based on the first column notation and order. | | Subparameters: | The subparameters specify the length, inductance, capacitance |* and resistance of each section of each stub on a package or mated |* model. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. The subparameters are defined as | follows: |* Len The length of a package or mated model stub section. |* Lengths are given | in terms of arbitrary 'units'. |* L The inductance of a package stub or mated model section, |* in terms of | 'inductance/unit length'. For example, if the total | inductance of a package stub section is 3.0nH and the | length of this section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). |* C The capacitance of a package stub or mated model section, |* in terms of | capacitance per unit length. |* R The DC (ohmic) resistance of a package stub or mated |* model section,in | terms of ohms per unit length. | Matrix Use of this subparameter means that this package stub |* or mated model | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | | Specifying a length or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. | |* Using the Subparameters to Describe Package or Mated Model |* Sections: | Each section description must begin with the Len subparameter and | ends with the slash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. All | package stub descriptions must contain the same number of | sections however, a particular section description can contain | no data (i.e. the description is given as 'Len = 0 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | slash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the slash. |----------------------------------------------------------------------------- [Pin Numbers] A1 Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 / A2 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.1 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01/ A5 Len = 0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | | Note that the actual length for each section is reported, even for | those sections that use the Matrix subparameter. | |* Note that there are two columns of pin numbers if this is for a |* mated model definition. |============================================================================= | Keyword: [Model Data] |* Required: Yes, if any of the sections in a package stub or mated model |* description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |*Description: Indicates the beginning of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub |* or mated model | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub |* or mated model | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 REPLACEMENT OF EXITING VERSION 2.1 TEXT |****************************************************************************** |****************************************************************************** |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The subparameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the subparameters. | After each of these subparameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are |* defined as ENTERING the pins of the package or mated model |* from the board | (General Syntax Rule #11). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | There are two different ways to extract the coefficients that are reported | in the the capacitance and inductance matrices. For the purposes of this | specification, the coefficients reported in the capacitance matrices shall | be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. | The Maxwell capacitance Kij is defined as the charge induced on conductor "j" | when conductor "i" is held at 1 volt and all other conductors are held at | zero volts. Note that Kij ( when i /= j) will be a negative number and | should be entered as such. Likewise, for the inductance matrix the | coefficients for Lij are defined as the voltage induced on conductor "j" | when conductor "i"'s current is changed by 1amp/sec and all other | conductors have no current change. | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | |* For even a modest-sized package or mated model, |* this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N x M, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The Banded_matrix is used to specify the coupling effects up to B pins | on either side. Two variations are supported. One allows for the coupling | to circle back on itself. This is technically a simple form of a bordered | block diagonal matrix. However, its data can be completely specified | in terms of a Banded_matrix for an N x M matrix consisting of N rows | and M = N + B columns. The second variation is just in terms of an N x N | matrix where no circle back coupling needs to be specified. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | For case where coupling can circle back on itself, consider a matrix of | N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | The first row only needs to specify the entries [1,1] through [1,1+B] since | all other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2,2+B], and so on. For row K | the entries [K,K] through [K,K+B] are given when K + B is less than or | equal to the size of the matrix N. When K + B exceeds N, the entries in the | last columns 1 ... B specify the coupling to the first rows. For row K, the | entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = | mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. To avoid | redundant entries, the bandwidth is limited to B <= int((N - 1) / 2). | | For the case where coupling does not circle back on itself, the process is | modified. Only N columns need to be considered. When K + B finally exceeds | the size of the matrix N, the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. This construction | constrains the bandwidth to B < N. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs). | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | With this convention, please note that the N'th row of an | N x N matrix has just a single entry (the diagonal entry). | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |*============================================================================= |* Keyword: [End Mated Model] |* Required: Yes |* Description: Marks the end of a mated model description. |* Usage Rules: This keyword must come at the end of each complete mated |* model description. |* |* Optionally, add a comment after the [End Package Model] keyword |* to clarify which package model has just ended. For example, |* |* [Define Mated Model] My_Model |* | |* | ... content of model ... |* | |* [End Mated Model] | end of My_Model |* |*---------------------------------------------------------------------------- [End Mated Model] |* |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] December 13, 1995 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRD31.1 is a total rewrite of BIRD31 which proposed connector models split and attached directly on [Component] models. It was impractical, limiting, and burdensome to provide split models. "Mated models" is introduced as a general term to describe connectors, cables and socket. Its electrical format is the same as the package model format. The final form will track any further developments in package model syntax. Thus the mated model text was merged with the existing package model text to form a combined section. The interconnection is based on simulator dependent interfaces. The [Component] pins for the connector footprint must contain reference to Model_names or NC, POWER, or GND. The package model elements can be used to approximate the termination effects if the connector is NOT mated. The mated model elements override these package parameters when the interconnection is made. The electrical model of cables contain the effects of the connectors at both ends along with the cable wire descriptions. For [Components] modeled on sockets, the package model of the [Component] model will be used. Here the simulator interface could distinguish between a connection made to another board, and a connection made to just a component. (3) The mated model introduces the [Define Mated Model] and [End Mated Model] keywords because it differs from the package model in the following ways: (a) It adds optional Cpad_1 and Cpad_2 subparameters for pad capacitance. Most connector model do not include these effects. (b) The mated model is NOT referenced by any [Component] directly. The simulator interface determines how a mated model is connected (or not connected as in the case of an empty socket for optional memory. (c) The mated model must exist only in a separate file since it cannot be determined which mated model file to use if it also exists within a .ibs file. (In contrast, the [Package Model] keyword provides the direct reference, and its model is searched first in the .ibs file and then in any .pkg file.) (d) The mated model contains two columns of pins so that the pins on one side can be defined differently than the pins on the other side. Thus cables which have cross-over connections, or which can be split and feed several different connectors can be described. BIRD31.2 contains two addtions to the mated model definition that were requested at the April 19, 1996 meeting and discussed in related e-mail by Hank Herrmann and David Fogel. A definition of the mate model physical boundary is clarified. Also the Tedge_rate parameter is needed because there is no surrounding basis to know whether the mate model is accurate enough for the simulations. With package models, it is presumed that the model is of suitable accuracy to be used with the associated components. Since the Tedge_rate is required, it is necessary to specify how it is determined. Hank Herrmann recommended an impedance profile method to relate physical and simulated model accuracy within 10% as a function of the edge_rate of the input signal. The point at which deviations exceed 10% is where the mated model needs more structural detail. The proposed impedance profile method illustrated below works both for single line models and coupled line models. A properly formed coupled line model will converge to the same impedance profile as a single line model of similar structural detail. So this subparameter is consistent for both cases. mate model or physical connection __ --> i(t), v(t) ______ / o---/\/\/\-------O______O--/\/\/\---o GND V(t) / 50 ohms ^ 50 ohms __/ ^ | | Compare v(t)/i(t) | (other contacts grounded) Tedge_rate is the 20% to 80% duration rise time Note, if faster edge rate models are constructed by cascading IDENTICAL sections, the Tedge_rate subparameter shall be defined using a large or maximal number of cascaded sections to accomodate simulators which will treat each stage using (coupled) transmission line methodology. Thus even if that stage is presented as one section, its Tedge_rate will be based on a distributed model with a large number of identical cascaded sections. Programs which use discrete lumped sections would need to expand a section along into the appropriate number of cascaded identical sections based on the Tedge_rate value. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Mon Apr 29 13:06:27 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA28993 for ; Mon, 29 Apr 1996 13:06:27 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id MAA12135 for ; Mon, 29 Apr 1996 12:57:23 -0700 (PDT) Received: from xtg801.intel.com by ichips.intel.com (8.7.4/jIII) id MAA27892; Mon, 29 Apr 1996 12:55:17 -0700 (PDT) Received: from localhost by xtg801.intel.com (4.1/SW1.11) id AA00479; Mon, 29 Apr 96 12:57:23 PDT Message-Id: <9604291957.AA00479@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD31.2 - Mated Models Date: Mon, 29 Apr 1996 12:57:21 -0700 From: Stephen Peters Hello Bob: A quick comment on the Tedge_rate parameter. I think the allowable values for Tedge_rate should also include 'NA' - not available. If the information is not available, I feel it should be stated explicitly, not by entering a value of zero. Anyway, that is my preference. Regards, Stephen Peters Intel Corp. >>>> excerpt for BIRD follows follows |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |*============================================================================= |* Keyword: [Define Mated Model] |* Required: Yes |*2 Sub-params: Tedge_rate, Cpad_1, Cpad_2 |* Description: Marks the beginning of a mated model description. |* Usage Rules: If the .mmf file contains data for more than one mated model, |* each section must begin with a new [Define Mated Model] |* keyword. The length of the mated model name must not |* exceed 40 characters in length. Blank characters are |* allowed. |* |*2 The Tedge_rate is as a required subparameter defining the |*2 the minimum time edge rate for which the mated model is |*2 considered accurate under test fixture conditions. A more |*2 detailed mated model topology would be preferred if the edge |*2 rate were smaller. The Tedge_rate subparameter may serve |*2 to produce a warning that the simulations are being done |*2 outside of the mated model performance range. |*2 |*2 A numerical value must be defined. It is the input pulse |*2 rise time defined between the 20% and 80% points. |*2 This value will be the minimum value where the signal line |*2 "impedance" is within 10% of the simulated impedance. This |*2 impedance parameter is the dynamic ratio at the mated model |*2 input voltage to input current over time under the condition |*2 that the signal line has a source and load termination of |*2 of 50 ohms and all other lines are grounded. A value of 0 |*2 is permitted, and would serve as an indication that no |*2 performance limit is available. However, if the model is |*2 suitable for all edge rates, use a very small, non-zero |*2 value such as 1e-15 seconds. |*2 |* The Cpad_1 and Cpad_2 subparameters are optional and define |* default pad capacitances at sides 1 and 2 of the mated model. |* The values default to 0 pF if omitted. However, in all cases |* the simulator may override the default values based on |* actual geometrical pad dimensions. |*2 |*2 Other Notes: The mated model extends to the physical surfaces of the |*2 structure in the mated configuration. For example, the |*2 the printed circuit board fingers of an edge card connector |*2 that extend into the connector are included in the mated |*2 model electrical description. The Cpad_1 and Cpad_2 sub- |*2 parameters are optional default extensions for pads outside |*2 the mated model physical dimensions. |*------------------------------------------------------------------------------ From owner-ibis Mon Apr 29 14:39:16 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA29885 for ; Mon, 29 Apr 1996 14:39:10 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 Apr 96 14:24 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 Apr 96 14:27 PDT Message-Id: Date: Mon, 29 Apr 96 14:27 PDT From: bob@icx.com ( Bob Ross) To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org, speters@ichips.intel.com Subject: Re: BIRD31.2 - Mated Models To Arpad, Stephen and IBIS committee. In every case in IBIS, the subparameter syntax "XXX = yyy" requires that "yyy" be numerical. I do not feel it is necessary to make a syntactical exception which could create confusion elsewhere. One option is to make Tedge_rate optional. The omission of the subparameter is effectively identical to "Tedge_rate = NA". I would prefer this option. Then "Tedge_rate = 0" can mean no limit. Another alternative is to develop another syntax such as [Define Mated Model] Tedge_rate Tedge_rate is a numerical value or NA. Again I am sensitive to setting up unnecessary deviations from existing conventions. Bob Ross Interconnectix, Inc. > Text item: > I second that, zeroes (and infinites) are dangerous numbers some times... > Arpad > ============================================================================== > Hello Bob: > A quick comment on the Tedge_rate parameter. I think the allowable > values for Tedge_rate should also include 'NA' - not available. If the > information is not available, I feel it should be stated explicitly, not by > entering a value of zero. Anyway, that is my preference. > Regards, > Stephen Peters > Intel Corp. From owner-ibis Mon Apr 29 15:03:30 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA00235 for ; Mon, 29 Apr 1996 15:03:30 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id OAA27213 for ; Mon, 29 Apr 1996 14:54:20 -0700 (PDT) Received: from xtg801.intel.com by ichips.intel.com (8.7.4/jIII) id OAA05761; Mon, 29 Apr 1996 14:52:12 -0700 (PDT) Received: from localhost by xtg801.intel.com (4.1/SW1.11) id AA02326; Mon, 29 Apr 96 14:54:19 PDT Message-Id: <9604292154.AA02326@xtg801.intel.com> To: ibis@vhdl.org Subject: Re: BIRD31.2 - Mated Models Date: Mon, 29 Apr 1996 14:54:18 -0700 From: Stephen Peters Hello Bob: Ok, you win . Seriously, I think this is a valid argument for making Tedge_rate an optional parameter. HOWEVER, it should be clearly stated that if the parameter is missing, the Tedge_rate information is unavailable and the user can make no assumptions about the suitablility of the model for high frequency simulations. Regards, Stephen To Arpad, Stephen and IBIS committee. In every case in IBIS, the subparameter syntax "XXX = yyy" requires that "yyy" be numerical. I do not feel it is necessary to make a syntactical exception which could create confusion elsewhere. One option is to make Tedge_rate optional. The omission of the subparameter is effectively identical to "Tedge_rate = NA". I would prefer this option. Then "Tedge_rate = 0" can mean no limit. Another alternative is to develop another syntax such as [Define Mated Model] Tedge_rate Tedge_rate is a numerical value or NA. Again I am sensitive to setting up unnecessary deviations from existing conventions. Bob Ross Interconnectix, Inc. > Text item: > I second that, zeroes (and infinites) are dangerous numbers some times... > Arpad > ============================================================================== > Hello Bob: > A quick comment on the Tedge_rate parameter. I think the allowable > values for Tedge_rate should also include 'NA' - not available. If the > information is not available, I feel it should be stated explicitly, not by > entering a value of zero. Anyway, that is my preference. > Regards, > Stephen Peters > Intel Corp. From owner-ibis Tue Apr 30 18:20:06 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA17530 for ; Tue, 30 Apr 1996 18:20:03 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 Apr 96 18:10 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 Apr 96 18:13 PDT Message-Id: Date: Tue, 30 Apr 96 18:13 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: VLSI IBIS Models To IBIS List: I have put information concerning available VLSI Technology IBIS models on vhdl.org in: /pub/ibis/models/vlsi/00readme IBIS models are available directly from VLSI. There are no models stored on vhdl.org. Bob Ross Inteconnectix, Inc.