From owner-ibis Mon Dec 1 11:11:19 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA22044 for ; Mon, 1 Dec 1997 11:11:17 -0800 (PST) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Mon, 1 Dec 1997 11:09:15 -0800 (PST) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Mon, 1 Dec 1997 11:09:07 -0800 (PST) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Mon, 1 Dec 1997 11:09:08 -0800 (PST) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Mon, 1 Dec 1997 11:09:08 -0800 (PST) From: bob@icx.com (Bob Ross) To: ibis@eda.org Subject: Agenda IBIS Meeting 12/5/97 IBIS Open Forum Meeting Agenda for 12/5/97 Bridge Number Reservation # Passcode (916) 356-9200 3-159556 6788873 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions International Progress Rusher/Ross - IEC 62014-1 (IBIS Version 2.1) - EIAJ III (I/O Interface Model for ICs) DesignCon98 IBIS Summit Meeting Huq DATE98 (Design Automation and Test in Europe - Ross formerly EuroDAC) - IBIS Summit - PCB Symposium - IBIS Fringe Meeting s2ibis for NT Status Dodd/Wiens Editing Committee Ross/Peters BIRD44 Interpretation of Min/Max/Weak/Strong Data Ross (to be discussed) IBISCHK2+ (Ver 2.115) PROGRESS Flora/Rokusek Version 3.1 Parser Development Ross/Peters - Funding - Test Matrix - Samples Cookbook Status Peters - Examples New Administrative Issues All 9:15 Technical Discussion BUG19 - "typ" Data Outside "min" "max Not Reported Gregory/Ross As a Warning BIRD42.3 Modeling Current Waveforms Kumar/Ross BIRD45.1 Dynamic Clamps Orhanovic/Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Thu Dec 4 18:44:45 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA13534 for ; Thu, 4 Dec 1997 18:44:44 -0800 (PST) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Thu, 4 Dec 1997 18:42:33 -0800 (PST) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Thu, 4 Dec 1997 18:42:20 -0800 (PST) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Thu, 4 Dec 1997 18:35:30 -0800 (PST) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Thu, 4 Dec 1997 18:35:30 -0800 (PST) From: bob@icx.com (Bob Ross) To: ibis@eda.org Subject: IBIS BIRD46 on FILE NAMES Buffer Issue Resolution Document (BIRD) BIRD ID#: 46 ISSUE TITLE: Relaxation of some IBIS model file name restrictions. REQUESTOR: Matthew Flora and Kellee Crisafulli, HyperLynx DATE SUBMITTED: 4 Dec 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The file names of IBIS models are currently limited to 8 characters in length (not counting the mandatory .ibs extension) and "must conform to DOS rules". We propose that the length limit be expanded to 64 characters and that periods be allowed within the file name. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Item 3 in Section 3 of the IBIS 3.0 specification, General Syntax Rules and Guidelines, currently states: 3) File names used in the file must only have lower case characters to enhance UNIX compatibility and must conform to DOS rules. (The length of a file name should not exceed eight plus three characters and it must not contain special characters that are illegal in DOS). We propose that this item would be changed to state: 3) File names used in the file must only have lower case characters to enhance UNIX compatibility. The length of a file name should not exceed sixty-four. This number includes the four characters of the mandatory file extension ".ibs". File names must not contain special characters that are illegal in DOS other than periods. Periods may be used throughout the file name, not just to mark the file extension. The following examples are legal names: 82374eb.ibs redoct_12cmos50_a50_d50.ibs gtl.q612mea.ibs The [File Name] keyword would be updated to state: |============================================================================= | Keyword: [File Name] | Required: Yes | Description: Specifies the name of the IBIS file. | Usage Rules: | The file name must not be longer than 64 characters (including | the extension). The file name must not use characters that | are illegal in DOS other than periods. In addition, the file | name must be all lower case, and use the extension ".ibs". | The file name must be the actual name of the file. |----------------------------------------------------------------------------- ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: We believe that engineers have moved beyond DOS as an engineering platform. Therefore, we would like to lift some of the restrictions that were imposed by DOS. We already encounter IBIS model files which violate the 8.3 length rule. Extending the allowed length of file names gives model creators the opportunity to use more descriptive file names. The choice of 64 characters was arbitrary, however names longer than that may not display well in applications. The limit should not be increased to more than 255, since that would be illegal under Windows NT, Windows 95, and some versions of UNIX. Allowing the use of periods throughout file names is common in the majority of file systems and is another means of making file names more descriptive. Since some operating systems (Windows NT 4.0 for one) still ignore the case of characters in file names, file names should still be required to be all lower-case. As far as we are aware, DOS has the largest set of characters which are not allowed in file names. Continuing to disallow all of those characters (bar one - the period) should ensure that IBIS model file names are still valid on all common platforms. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From owner-ibis Thu Dec 4 20:12:15 1997 Received: from cello.cs.iitm.ernet.in ([206.103.12.228]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id UAA14937 for ; Thu, 4 Dec 1997 20:11:56 -0800 (PST) Received: from oyster.ee.iitm.ernet.in (root@oyster.ee.iitm.ernet.in [144.16.244.42]) by cello.cs.iitm.ernet.in (8.6.12/8.6.9) with ESMTP id JAA00642 for ; Fri, 5 Dec 1997 09:37:25 +0530 Received: (from presi@localhost) by oyster.ee.iitm.ernet.in (8.6.12/8.6.9) id IAA00179; Fri, 5 Dec 1997 08:56:43 +0530 Date: Fri, 5 Dec 1997 08:56:43 +0530 (IST) From: Sanjeev To: The IBIS reflector Subject: ECL bugs in s2ibis2.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, If you have any bugs which are related to the making of ECL models through s2ibis2.1 please pass them to me. Please DO give a test-case for the same. regards, presi ***************************************************** What do you call a rabbit with fleas: Bugs Bunny! R.Sanjeev --------- e-mail: presi@usa.net presi@oyster.ee.iitm.ernet.in snail-mail: 61, Rangarajapuram Main Road, Kodambakkam, Chennai-24. **************************************************** From owner-ibis Fri Dec 5 10:36:07 1997 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA29633 for ; Fri, 5 Dec 1997 10:36:06 -0800 (PST) Received: from fmmail.fm.intel.com (fmmail.fm.intel.com [198.175.75.69]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id KAA05447; Fri, 5 Dec 1997 10:33:50 -0800 (PST) Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id KAA02339; Fri, 5 Dec 1997 10:32:28 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 05 Dec 97 10:32:25 PST Date: Fri, 05 Dec 97 07:33:00 PST From: Arpad Muranyi Message-ID: To: neven@icx.com cc: ibis@eda.org Subject: Re[2]: BIRD 45.1 -- Dynamic clamps Text item: Looking at the buffer scheduler keyword in the IBIS spec. I would like to make suggestion that we rather modify that instead of adding these keywords (in BIRD45.1). When it boils down to the operation of the device, it really doesn't matter whether we call the I-V curves clamps or drivers, as long as there are curves which can be controlled by something (time, voltage, etc.). So I would like to suggest the addition of a couple of items to the buffer scheduling mechanizm that would allow the translation (shifting) of the I-V curves, and allow them to be controlled by the voltage on the I/O pad (kind of like a feedback). If we had these features, we could use the scheduler to do a lot of different things, including some of the devices that may come out in the future. Any comments? Arpad ================================================================================ It seems to me that the values for V_trigger, V_trigger_min, and V_trigger_max ought to be in the three column format the same as other typ, min, max data. This is the convention used for other such data and to introduce a new convention without a clear reason for it would lead to confusion. Thus, | Subparameters: V_trigger, V_trigger_min, V_trigger_max | Usage Rules: The [Dynamic GND Clamp] and [Dynamic PWR Clamp] specifications | contain three subparameters and two keywords. The subparameters | (V_trigger, V_trigger_min, V_trigger_max) specify the threshold | clamp voltage value that causes the clamp to begin switching | from "off" to "on" according to the [Pulse Table] section. | These values correspond to the typical, weak (slow), and strong | (fast) situations. | [Dynamic GND Clamp] V_trigger = 1.4V V_trigger_min = 1.2V V_trigger_max = 1.6V Would change to | Subparameters: V_trigger | Usage Rules: The [Dynamic GND Clamp] and [Dynamic PWR Clamp] specifications | contain one subparameter and two keywords. The subparameter | (V_trigger) specifies the threshold | clamp voltage value that causes the clamp to begin switching | from "off" to "on" according to the [Pulse Table] section. | These values correspond to the typical, weak (slow), and strong | (fast) situations. [Dynamic GND Clamp] | typ min max V_trigger 1.4V 1.2V 1.6V -- -- Paul Gregory phone: (208) 396-5086 USmail: Hewlett-Packard fax: (208) 396-4122 M/S 143 email: paul_gregory@hp.com 11311 Chinden Blvd. Boise, ID 83714 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***. Mailer: Elm [revision: 70.85] In-Reply-To: ; from "Neven Orhanovic" at Nov 2 0, 97 4:23 pm Cc: ibis@eda.org Date: Fri, 21 Nov 97 8:10:24 MST To: neven@icx.com (Neven Orhanovic) (Neven Orhanovic) Subject: Re: BIRD 45.1 -- Dynamic clamps Message-Id: <9711211510.AA04054@hpbs2933.boi.hp.com> From: Paul Gregory Received: by hpbs2933.boi.hp.com (1.38.193.4/15.5+IOS 3.22) id AA04054; Fri, 21 Nov 1997 08:10:24 -0700 Received: from hpbs2933.boi.hp.com (pgregory@hpbs2933.boi.hp.com [15.8.28.3]) by palrel3.hp.com (8.8.5/8.8.5tis) with SMTP id HAA17629 for ; Fri, 21 Nov 1997 07:13:04 -0800 (PST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by server.vhdl. org (8.8.5/8.8.3) with ESMTP id HAA15986 for ; Fri, 21 Nov 1997 07 :15:02 -0800 (PST) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id HAA05204; Fri, 21 Nov 1997 07:34:23 -0800 (PST) Received: from ganymede.or.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0xYv2m-000qERC; Fri, 21 Nov 97 07:30 PST From owner-ibis Mon Dec 8 08:32:23 1997 Received: from ihgw2.lucent.com (ihgw2.lucent.com [207.19.48.2]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id IAA09692 for ; Mon, 8 Dec 1997 08:32:22 -0800 (PST) Received: from ihgp3.ih.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA08032; Mon, 8 Dec 1997 10:21:15 -0600 Received: by ihgp3.ih.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id KAA28926; Mon, 8 Dec 1997 10:30:06 -0600 From: ushman@lucent.com (Robert C Ushman) Received: by ihgp3.ih.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id KAA28840; Mon, 8 Dec 1997 10:30:03 -0600 Date: Mon, 8 Dec 1997 10:30:03 -0600 Message-Id: <199712081630.KAA28840@ihgp3.ih.lucent.com> Original-From: rcu@ihgp.ih.lucent.com (Robert C Ushman) To: ibis@vhdl.org Subject: Success with s2ibis2 tool??? Content-Type: text Hi, I have been trying to use the s2ibis2 tool to convert a spice model, but, have not been able to get any results. (Right now, I'm getting messages about "cannot open file... for reading..."). Has anyone been successful at implementing this tool, that would mind trading some email to help me get this tool working? I would greatly appreciate it. Regards, Robert Ushman ushman@lucent.com From owner-ibis Mon Dec 8 08:59:02 1997 Received: from ganymede.or.intel.com (root@ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA10179 for ; Mon, 8 Dec 1997 08:59:02 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id JAA03722 for ; Mon, 8 Dec 1997 09:11:07 -0800 (PST) Received: from xtg801 (xtg801.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id IAA20572 for ; Mon, 8 Dec 1997 08:58:09 -0800 (PST) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1) id IAA20403; Mon, 8 Dec 1997 08:56:54 -0800 (PST) Message-Id: <199712081656.IAA20403@xtg801> X-Mailer: exmh version 1.6.9 8/22/96 To: ibis@eda.org Subject: EIA IBIS Open Forum Minutes 12/5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 1997 08:56:53 -0800 From: Stephen Peters DATE: 12/9/97 SUBJECT: 12/5/97 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1997 PARTICIPANTS LIST: AMP Jeff Walden Applied Simulation Technology [Dileep Divekar], Norio Matsui, Raj Raghuram, Fred Balistreri* Cadence Design & UniCAD C. Kumar, Don Telian, Cameron Seitz Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu Hewlett Packard, EEsof Karl Kachigan, Henry Wu High Design Technology (Razvan Ene) HyperLynx Kellee Crisafulli, Steve Kaufer, Matthew Flora* INCASES Olaf Rethmeier, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi*, Henry Maramis, Will Hobbs, Frank Kern Interconnectix Bob Ross*, Neven Orhanovic Mitsubushi Tam Cao, Hoang Nguyen Motorola [Ahmed Omer], Michael Desiderio, Paul Bolden, Tom Myers, Rob Wenzel National Semiconductor Syed Huq*, Cheng-Yang Kao, Mike Bristol, [Peter Laflamme], [Kevin Smith] NCR Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher Thomson-CSF/SCTF (Jean LeBrun) Viewlogic Jon Powell, Chris Rokusek, Peivand Tehrani Graham Bell VeriBest Ian Dodd, William Bell, Dave Wiens VLSI Technology Harish Patel, D.C. Sessions* OTHER PARTICIPANTS IN 1997: 3M [Fran Hart] Actel Scott Schlachter Acuson & Free Model Foundation Richard Munden Alcatel John Fitzpatrick Ansoft Eric Bogatin Apteq Design Systems Dan FitzPatrick Compaq Weston Beal, Mark Leonard Dell Computer Dave Baranauskas, Doug Wallace EIA Patti Rusher EMC Fabrizio Zanella Hewlett Packard, Boise Paul Gregory* Hewlett Packard, France Jean-Christophe Pautrat Hitachi Saburo Hojo, Yasushi Ogawa IBM Brad Herrman Interface Technology Dan Waterloo Micron Technology Brian Johnson Molex Gus Panella North Carolina State U. (Michael Steer) Philips Semiconductor Todd Andersen S3, Inc. Porsh Shih, Sarathy Sribhashyam Symmetry Andy Hughes Tandem Mark Simpson TRW Ray Steele Ultratest International Charles Im Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode January 9, 1998 (916) 356-9200 6-8002 4618642 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM No new participants. MEMBERSHIP UPDATE AND TREASURER'S REPORT No new report since the last report of about $6008. Bob Ross wants the IBIS DAC98 support fee of the EDA Booth at the Design Automation Conference (DAC) to be taken out of these funds. Bob also requested Syed Huq to do the update of the roster to catch up with company name changes, affiliations, etc. Syed will do this in January. REVIEW OF MINUTES AND AR'S Bob Ross noted a name correction. The AR's will be talked discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Bob Ross mentioned that discussions about Majordomo conversion have begun. Some points still need to be resolved regarding archiving mail, bounced messages, and "closed" list. One of the consequences may be that only people whose e-mail addresses match those on the list will be able to send messages. In other words, if you send a message from another account or from your system which does not match the "alias" address, you would get a Majordomo message on how to subscribe message. So this could be an in convenience to some during the transition. Arpad Muranyi asked why we are doing the conversion, and Bob responded that this was requested for computer support reasons. Bob will be on vacation through December 15, and Syed Huq will be handling the Sys Op duties including mailing list management. PRESS AND WEB PAGE UPDATES Syed Huq reported that he has uploaded his presentation on "Understanding and Using IBIS Models for Signal Integrity Analysis", presented at the High-level Electronic System Design Conference, (HESDC) in October, 1997. It is located on the EIA IBIS Home page under "Articles" for downloading. Syed also has corrected the FAQ file. Bob Ross changed bug.dir to bugdir.txt under /pub/ibis/bugs/ibischk on eda.org so that it could be more easily viewed and downloaded from browsers. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported an updated link from QuickLogic: http://www.quicklogic.com/support/tech_support Bob also reported new models on the Cypress and IDT sites. OPENS FOR NEW ISSUES Bob Ross on IBIS East Meeting. Bob Ross on meeting regarding helping create good models Matthew Flora on BIRD46, Relaxation of some IBIS Model file name restrictions INTERNATIONAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Bob Ross reported that Patti Rusher is still waiting for the official approval of the unanimous vote from IEC. When approval is reached, the IEC nomenclature will be added to the ANSI/EIA-656 document. Patti will also issue a press release. - EIAJ III (I/O Interface Model for ICs) - No report DESIGNCON98 IBIS SUMMIT Syed Huq updated us on the IBIS Summit meeting planned on Monday, January 26, 1998 and Hosted by National Semiconductor and the same location as DesignCon98. Syed Huq updated us on plans for the EIA IBIS Summit Meeting on Monday, January 26, 1998. He has reserved a room at the Westin Hotel adjacent to the Santa Clara Convention Center. Syed has sent out early information regarding location and hotels and a call for presentations. He is still seeking more presentations. If you want to do an IBIS related presentation, send the information to huq@rockie.nsc.com Please indicate the Title, and estimated time. (We are looking for about 15-20 minute presentations with possible discussions afterwards, and will plan the agenda around the presentations submitted. If possible electronic copies should be submitted beforehand to Syed so that he can have copies available at the IBIS Summit.) Bob Ross indicated that he might talk about what he looks at to validate models - and have a discussion based on some material discussed later in the minutes regarding getting better IBIS models. Paul Gregory and/or Arpad Muranyi might talk about higher speed considerations. Arpad might also talk about modeling dynamic clamps. (later, Ed Sayre might talk about IBIS East Users group.) Syed will send out the formal call for presentations at a later time. He also needs people to sign up for planning the buffet lunch. Syed and Bob discussed that IBIS Meeting attendees who are on the IBIS mailing lists may get a discount to attend DesignCon98. If this is possible, the details will be in the next IBIS Summit message from Syed. The only issue is if the logistics are doable. DESIGNCON98 DesignCon98 (formerly Design SuperCon) is scheduled Tuesday-Thurday, January 28-30, 1998 at the Santa Clara Convention Center. The Signal Integrity track on Tuesday has three presentation that relate to IBIS modeling along with an IBIS panel session on "How Good are the Currently Available IBIS Models". Several IBIS Committee members are expected to be on the panel. This will provide an opportunity to express plans in addressing the issue of getting better IBIS models from all sources. DesignCon98 information is available at: http://www.designcon.com DATE98 (DESIGN AUTOMATION AND TEST IN EUROPE) IBIS SUMMIT The DATE98 Conference will be held Monday thru Thursday, February 23-26, 1998 in Paris France. Several IBIS and PCB Design related activities are being planned. The DATE Conference itself is the continuation of EuroDAC (with EuroVHDL) and ED&TC (EDAC, ETC, and EuroASIC). More information is available at: http://www.date-conference.com - IBIS Fringe Meeting - Tuesday, February 24, 1998 Bob Ross mentioned that there is a possibility of an IBIS fringe meeting on Tuesday evening, February 24 to give general IBIS information, answer questions, and discuss IBIS. This has not been formally set up yet and is probably unlikely in view of the activity the following days. - PCB Symposium - Wednesday, February 25, 1998 Bob Ross reported on plans in progress for an all day PCB Symposium on Wednesday, February 25, 1998. So far, it is co-sponsored by Cadence, Incases, Mentor Graphics, VeriBest, ViewLogic, Xynetix, and Zuken-Redac. The plans are to include 30 minute presentations from each company on an aspect of PCB design. The Mentor contribution will be on Getting IBIS Models by Bob. Also a one-hour panel session is planned. A buffet lunch will be provided. This is planned from 10 AM to 5 PM. Information on this including how to sign up will be sent to the IBIS reflector when it is available. - IBIS Summit - Thursday, February 26, 1998 Bob reported that so far Cadence and High Design Technology and Mentor Graphics are co-sponsoring the IBIS Summit meeting scheduled on Thursday, February 26, 1998. A buffet lunch will be planned for attendees. Bob has sent out an initial Call for Papers and is still seeking papers. The response so far indicates a very good program for exchanging ideas and information. Possible presentations planned so far include: John Fitzpatrick: Use of IBIS in Alcatel Syed Huq: IBIS Model Development at National Incases: IBIS and Radiation Analysis Razvan Ene (HDT): IBIS Models for EMC and High-Frequency Devices Bernhard Unger (Siemens) SI-Analysis with HSPICE Based on IBIS Behavioral Models Other presentations so far may be from Arpad Muranyi, (another from Siemens), and Bob (if needed). Send presentation proposals to bob@icx.com S2IBIS2 Bob Ross reported that R. Sanjeev (Presi) has done some working on s2ibis2 for handing ECL devices. He has put out a request on the reflector for Spice models for ECL devices to test s2ibis2. The Veribest AR regarding s2ibis2 for NT remains. AR - Ian Dodd put s2ibis_ver2.1 for Windows on the VeriBest Web site. EDITING COMMITTEE Bob Ross reported again that the first editorial pass of IBIS Version 3.0 as /pub/ibis/wip/ver3_1a.ibs The BNF AR remains. AR - Bob Ross generate and post a BNF for IBIS Version 3.0 (and IBIS Version 3.0 ratification AR). BIRD44 - INTERPRETATION OF MIN/MAX/WEAK/STRONG DATA Discussion on this was planned, but it was deferred until later. Later, the Bob wanted this to be considered at this time since the idea of having explicit min and max columns be changed to slow, or slow/weak and fast or fast/strong needs to be considered for continuing the editorial pass for IBIS Version 3.1. IBISCHK2+ (VER 2.115) PROGRESS Matthew Flora reported that he plans to address BUGs 8-18 this weekend and work with the ibischk3 developer since development is beginning the following week. Bob Ross will post any ibischk2+ parser upgrades on eda.org. AR - Matthew Flora implement the bug fixes needed to produce ibischk2 version 2.115. VERSION 3.1 PARSER DEVELOPMENT Atul Agawal of APT Software Avenues Pvt Ltd. plans to formally start the ibischk3 project Monday, December 8, 1997. As mentioned, Matthew Flora should communicate directly with Atul concerning updates and to help Atul become more effective. Bob Ross reported that he believes at least 8 purchase orders have been received and two more actually exist. He is correlating this with EIA. Several others may be possible. COOKBOOK No report, all the ARs are carried forward. AR - The following people have volunteered to supply examples Steve Kaufer/Hyperlynx -- Example 1 (Version 1.1 basic model) Arpad Muranyi - Example 2 Stephen Peters - Example 3 AR - Syed Huq. Review and expand (if necessary) Section 3.3. on "Obtaining I/V and Switching Information via Lab Measurement". IBISEAST MEETING Bob Ross reported off of some notes that Ed Sayre had just sent regarding the IBIS EAST Users Group meeting held on Thursday, December 4, 1997 on site at Cadence. Briefly, 23 people attended. Two sub-groups were formed. One deals with user community aspects such as IBIS to Spice, Spice to IBIS, syntax and documentation, materials for education, and standardization, etc. The second is focused on IBIS model validation, how one constructs a standard for valid model useful in system applications, how they simulate under different loading and termination conditions, etc. The plan is to make this group "open", not regionalized, but at this time working via face-to-face contact. The next meeting will be at Stratus computer on January 15, 1998. Ed may also give a presentation of the plans and activities at the IBIS Summit in January. The full minutes of the meeting will be sent out on the IBIS reflectors. MEETING ON HELPING GENERATE GOOD IBIS MODELS Bob Ross reported on a meeting on Thursday, December 4, 1997 with Bob, C. Kumar, Jon Powell, Stephen Peters, and Syed Huq. Syed had called this meeting to discuss educating semiconductor vendors on producing good IBIS models and how to deal with some flawed models that exist. Syed wanted to explore the ideas first with a small group to get some feedback and some additional ideas that would result in some actions. Bob reported that the discussion covered a variety of ideas ranging from a one day free education seminar to having the committee start "policing" or certifying sites. Bob indicated that the standard for a good IBIS model is much higher than for a Spice model where the user is expected to be knowledgeable about Spice to understand, configure (e.g., take out a built in test load) and connect the Spice model. Ideally, IBIS models should plug in just like the part itself into simulators and contain accurate and suitable information necessary for simulation and checking. The committee considered a seminar, but felt that the commitment to do it was too large considering the large number of other projects that the IBIS committee is doing. The most effective approach was to consider a process to review models and provide effective feedback to the model provider to help correct (and educate directly) what is needed for good suitable IBIS model. A number of ideas were discussed, leading to the proposal that we should ask for volunteers to form a sub-group for such a review. The action item from this meeting was to put this on the IBIS Agenda for general discussion. To start the discussion regarding setting up such a sub-group, Bob noted that there were still a variety of opinions what constituted a good IBIS model, and that the group itself would have to work this out. Part of the reason is that different simulators may need different capabilities and may deal with abnormal data in different ways. So it is possible for IBIS models to work or be suitable for some simulators, but not in others. An interactive discussion occurred covering many aspects of what the sub-group would look at and how it would function. Only a few of the points are captured here. Bob noted that he tests models by inspecting the contents, using ibischk2+, looking at the plots of the tables and doing actual simulation. Some simulators or translators do additional checks. So it would be ideal that a step in testing plug in compatibility would be to have the Model tested in several simulators. Many older IBIS models with problems were developed in environments where no IBIS simulator was available or, at best, one simulator. The only tools at the time were the evolving ibis_chk and evolving versions of s2ibis and s2ibis2 and plotting utilities. So there can be artifacts that are associated with the earlier development tools themselves that went undetected with the earlier checking processes and testing. As a more current example, a fully compliant IBIS Version 2.1 model which passes ibischk2 many still have waveform table end point data errors which are difficult to detect, but may be uncovered using ibishchk2+. Stephen Peters indicated that he had a model that he would like reviewed. D.C. Sessions also indicated that VLSI has some IBIS models for newer buffers that he would like reviewed.. However, they are available only through NDA. Furthermore, while the intent may be good, there may still be problems making such models available to what might be perceived as a "competing" semiconductor vendor for review. Bob indicated that many companies issue IBIS only directly to individuals that must not be distributed. Besides NDA processes, models are issued through direct request including including requesting a unique password for access or decryption. Since one desirable aspect of reviewing models would be to test them in a number different simulators, the most effective sub-group would be composed of simulator vendor personnel only. Then all members could, if necessary, go through the appropriate permission processes individually to get, review, and test the models. We must deal with the the reality that different companies have different policies regarding how they release IBIS models and optimize our processes accordingly. D.C. felt that this should be acceptable since it may be very difficult in some companies to issue permission to a multi-company sub-group. Further aspects of the process were mentioned. With a group composed of individuals from different simulator vendors, a model can be tested using several simulators. In reality, no semiconductor vendor is expected to have the resources directly available to the specific model developer to run it through several simulators. So the sub-group itself is a potential resource for more robust testing that is not available in practice. Furthermore good IBIS models with good data may work with some simulators and not work or be modified to work with others. This information could also be provided to the developer. Bob noted that some simulators may add even more checks than ibischk2+ such as non-monotonic checking of a summation of tables (ibischk2+ only checks one table at a time). Also some simulators have different ways for dealing with problems including rejecting the model, accepting the model or attempting to do "reasonable" adjustments. D.C. Sessions pointed out that some buffers really do have some slight non- monotonic [Pulldown] tables due to a method well-known and used in the semiconductor industry to protect the device during power-off/on cycles. The technique involves a feedback transistor to create a small current fold-back effect (less current for increasing voltage). Other points mentioned included whether IBIS Version 2.1 should be the baseline level for testing. Also, commercial model supplier vendors should really use this service since the greatest majority of models are available from such providers. The overall sense of the committee is recognize that there is a problem and to be pro active in addressing it in the most helpful method possible to provide information back to the model developer. So the action is to form a sub-group to address this issue. It should contain simulator company representatives. Bob and Matthew Flora said that they would join. It is seeking volunteers from other companies, and Matthew will be the contact person. To volunteer, contact Matthew at mbflora@hyperlynx.com. BUG19 - Warning for "typ" Data Outside "min" and "max" Paul Gregory had introduced BUG19 and there was some reflector discussion regarding it occurred. Bob Ross and others pointed out that there could be legitimate data where certain numbers fell outside the I/V table ranges. It would be a lot of work to do a thorough examination taking into account actual voltages, and Bob was concerned that we already have a lot of work in other areas. Bob classified BUG19 as an Enhancement of Low priority. After some further discussion the action is to classify this as Open, with the comment that we could do the testing only for table values where the data is ordered by definition according magnitudes into the typ, min and max columns. Examples would be C_comp, L_pkg, C_pkg, and R_pkg. No commitment was made that this enhancement would be done. BIRD42.3 - MODELING CURRENT WAVEFORMS No discussion. BIRD45 - DYNAMIC CLAMPS Bob Ross mentioned briefly that per the suggestion at the last meeting by Dave Moxley, we will still want to investigate using [Driver Selection] as part of the process. Arpad Muranyi will issue a comment on this subject on the reflector. BIRD46 - RELAXATION OF SOME IBIS FILE NAME RESTRICTIONS Bob Ross mentioned that Matthew Flora and Kelly Chrisafulli had just generated BIRD46, recently issued. Bob questioned whether this was for IBIS Version 3.1 or a later version, and after some discussion concluded that it could be for Version 3.1. This will be discussed at a later meeting. NEXT MEETING: The next meeting is on Friday, January 9, 1998, 8:00 A.M. to 9:55 A.M. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 SECRETARY: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== --=====================_881422935==_ Content-Type: text/plain; charset="us-ascii" --=====================_881422935==_-- From owner-ibis Mon Dec 8 19:37:04 1997 Received: from cello.cs.iitm.ernet.in ([206.103.12.228]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id TAA21476 for ; Mon, 8 Dec 1997 19:36:57 -0800 (PST) Received: from oyster.ee.iitm.ernet.in (presi@oyster.ee.iitm.ernet.in [144.16.244.42]) by cello.cs.iitm.ernet.in (8.6.12/8.6.9) with ESMTP id JAA09883; Tue, 9 Dec 1997 09:02:22 +0530 Received: (from presi@localhost) by oyster.ee.iitm.ernet.in (8.6.12/8.6.9) id IAA00231; Tue, 9 Dec 1997 08:56:49 +0530 Date: Tue, 9 Dec 1997 08:56:49 +0530 (IST) From: Sanjeev To: Robert C Ushman cc: ibis@vhdl.org Subject: Re: Success with s2ibis2 tool??? In-Reply-To: <199712081630.KAA28840@ihgp3.ih.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, > I have been trying to use the s2ibis2 tool to convert a spice model, > but, have not been able to get any results. (Right now, I'm getting > messages about "cannot open file... for reading..."). Either the base spice deck or one of the files "included" in the main spice file are not present in the present/specified directory. I'm sure the utility works. regards, presi ***************************************************** What do you call a rabbit with fleas: Bugs Bunny! R.Sanjeev --------- e-mail: presi@usa.net presi@oyster.ee.iitm.ernet.in snail-mail: 61, Rangarajapuram Main Road, Kodambakkam, Chennai-24. **************************************************** From owner-ibis Thu Dec 11 13:03:50 1997 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA01843 for ; Thu, 11 Dec 1997 13:03:48 -0800 (PST) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id PAA08877 for ; Thu, 11 Dec 1997 15:40:09 -0500 (EST) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Thu, 11 Dec 1997 15:40:05 -0500 Message-ID: <71EEA9EA5129D1118EA30000F840EBF1225B1A@sbuamapko3bc.eng.pko.dec.com> From: Greg Edlund To: "'Matthew Flora'" Cc: "'ibis@vhdl.org'" Subject: RE: IBIS Open Forum minutes of 12/5 Date: Thu, 11 Dec 1997 15:33:49 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" I agree that a single sub-committee on IBIS model quality would be in the best interest of the IBIS community. As I see it there are two main topics under model quality: 1. Syntactical correctness 2. Accurate prediction of electrical hardware behavior While topic 1 may cover a myriad of common modeling errors, it can be easily addressed: every IBIS model must pass the golden parser. Topic 2 is a bit more involved. The user community needs to see proof that a model developer measured the model against test hardware and the results were favorable. This leads to the questions, "What test hardware?" and "What is favorable?" This is where an amendment to the IBIS specification that covers model accuracy would lend great credibility to the IBIS model database. I think the sub-committee on model quality should work toward developing such an amendment, and I think the users and semiconductor vendors should work together toward a mutually agreeable solution. Perhaps the other sub-committee mentioned in the minutes would best be described as an "applications" sub-committee. I agree with Bob Ross that the user community needs to educate itself better about the various features of the IBIS spec and how to implement them in their design environment. The question about agreement between various simulation engines is certainly a valid one, but I'm really not sure about the best way to address it... Greg ---------- Greg Edlund, Principal Engineer Server Product Development Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (508) 493-4157 voice (508) 493-0941 FAX greg.edlund@digital.com ---------- From: Matthew Flora[SMTP:mbflora@hyperlynx.com] Sent: Thursday, December 11, 1997 6:43 AM To: Paul Galloway Cc: Greg Edlund; bob@icx.com; esayre@nesa.com; pgjr@node2.cadence.com; gpf@node2.cadence.com; breda@nesa.com; baxter@nesa.com; chen@nesa.com; sayre@unix.cie.rpi.edu; kellee@hyperlynx.com Subject: Re: IBIS Open Forum minutes of 12/5 Paul, > In reviewing the minutes of the last IBIS Forum Open meeting and in > reading the details of the meeting on helping generate good IBIS models > it appears that the formation of a sub-group here is very much overlapping > one of the User Group sub-committees being defined: from the User Group - > > "The second is focused on IBIS model validation, how one constructs a > standard for valid model useful in system applications..." > > Do we want to merge these two groups or do we want to keep separate at > this point and just have periodic joint discussions to see what differences > in definition occur? In general, I think that the more people discussing model quality, the better. For I assume that if people are talking about quality then quality will be on their minds when they create models. Multiple discussion groups allows more people to get involved, increases exposure, and increases the manpower available to "get the word out". However, I am concerned that the messages that come out of multiple groups may not be consistent. Having conflicting definitions/tests for quality models would obviously be detrimental to the development of "good" models. Therefore, I suggest that if multiple groups concerning model quality and model validation are formed, that one be designated as final arbiter. Perhaps not surprisingly, I would vote to designate the IBIS Open Forum sub-committee on model quality as the final arbiter. The sub-committee is open to the members of the IBIS Open Forum, and membership in the IBIS Open Forum is "open" to the public. The IBIS Open Forum is associated with the EIA and has a nationwide membership. Also, in the discussion on the model quality sub-committee at the last IBIS Open Forum meeting (5 Dec 1997), it was suggested that the sub-committee be given access to simulators by various EDA companies for use in validating models. (The simulator access would come from the sub-committee members themselves. The members would hopefully include representatives of the various simulator companies.) I think it unlikely that a local (regional) discussion group would have access to a broad range of tools. Matthew Flora Senior Engineer HyperLynx (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com From owner-ibis Thu Dec 11 14:30:55 1997 Received: from hyperwall.hyperlynx.com (root@[209.20.148.70]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA03511 for ; Thu, 11 Dec 1997 14:30:54 -0800 (PST) Received: from tensor ([209.20.148.75]) by hyperwall.hyperlynx.com (8.8.5/8.8.5) with SMTP id HAA31216; Thu, 11 Dec 1997 07:28:47 -0800 Message-Id: <3.0.5.32.19971211142907.009839d0@mail.nwlink.com> X-Sender: mbflora@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Dec 1997 14:29:07 -0100 To: Greg Edlund From: Matthew Flora Subject: RE: IBIS Open Forum minutes of 12/5 Cc: ibis@vhdl.org In-Reply-To: <71EEA9EA5129D1118EA30000F840EBF1225B1A@sbuamapko3bc.eng.pk o.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear Greg Edlund, > I agree that a single sub-committee on IBIS model quality would be in > the best interest of the IBIS community. > > As I see it there are two main topics under model quality: > 1. Syntactical correctness > 2. Accurate prediction of electrical hardware behavior > > While topic 1 may cover a myriad of common modeling errors, it can be > easily addressed: every IBIS model must pass the golden parser. If it were only that easy. The Golden IBIS Parser checks the syntax of the model, but not all of the semantics. Although the latest version of the parser does do some testing of the data within the model, there are some things that it simply cannot test for. For instance, the Golden IBIS Parser has no way of knowing if all of the part's pins have been listed. So a model could pass the parser and still not be usable with all simulators. This is why it was suggested that the model quality sub-committee run a model through several different simulators as well as through the Golden IBIS Parser. > Topic 2 is a bit more involved. The user community needs to see proof > that a model developer measured the model against test hardware and the > results were favorable. This leads to the questions, "What test > hardware?" and "What is favorable?" This is where an amendment to the > IBIS specification that covers model accuracy would lend great > credibility to the IBIS model database. I think the sub-committee on > model quality should work toward developing such an amendment, and I > think the users and semiconductor vendors should work together toward a > mutually agreeable solution. Proof of a model's accuracy is an admirable goal. However, you yourself pointed to some big questions: "What test hardware?" "What is favorable?". Since we would need an answer for all types of parts and since there will be many opinions concerning what is the best answer, I would prefer not to burden the sub-committee with such a weighty problem just yet. I propose that those questions be left to the full forum or be assigned to a separate sub-committee. The model quality sub-committee (I don't believe it has an official name yet) could be charged with "enforcing" the answers to those questions in the future. Don't misunderstand me. I am not saying that the answers to those questions shouldn't be pursued, I just don't think it is appropriate at this time for the small sub-committee to do so. Regards, Matthew Flora Senior Engineer HyperLynx (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com From owner-ibis Thu Dec 11 15:10:38 1997 Received: from gatekeeper2.nsc.com (natsemi3-bh.nsc.com [205.227.60.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id PAA04238 for ; Thu, 11 Dec 1997 15:10:38 -0800 (PST) From: huq@america.nsc.com Received: (from uucp@localhost) by gatekeeper2.nsc.com (8.6.12/8.6.11) id PAA27898 for ; Thu, 11 Dec 1997 15:08:29 -0800 Received: from nsc.nsc.com by natsemi3-bh.nsc.com via smap (3.2) id xma027694; Thu, 11 Dec 97 15:08:07 -0800 Received: from america.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA25164 for ibis@vhdl.org; Thu, 11 Dec 97 15:08:05 -0800 Received: from kural by america.nsc.com (4.1/SMI-4.1) id AA00132; Thu, 11 Dec 97 15:07:42 PST Date: Thu, 11 Dec 97 15:07:42 PST Message-Id: <9712112307.AA00132@america.nsc.com> To: ibis@vhdl.org Subject: s2ibis2 and Multiple PWR/GND defination Hi, I am using s2ibis2.sun4.fix on HSPICE for a 3.3V device. If you look at the s2i file below(extracted), I have multiple Power and Ground pins(Pin: 1,3,4,5,6,7) ..s2i file: ------------- |Pin Spice_node signal model_name R_pin L_pin C_pin |------------------------------------------------------- [Pin] 1 VSSIO GND GND 2 PAD lvttl lvttl -> SIGO EOE SIGO SIGO input dummy1 EOE EOE enable dummy2 3 VDDIO PWR POWER 4 VDDESD PWR POWER 5 VSS GND GND 6 VDD PWR POWER 7 GND GND GND | -------------------------------------------------------- But my s2ibis2 generated .spi file shows only connection to VDDIO and VSSIO. Ques#1: How do I know if my other Power and Ground nodes are connected to the proper level ? ..spi file: -------------------------- VOUTS2I PAD 0 DC 0 VCCS2I VDDIO 0 DC 3.3 <--------- for VDDIO VGNDS2I VSSIO 0 DC 0 <--------- for VSSIO VENAS2I EOE 0 DC 3.3 VINS2I SIGO 0 DC 3.3 .TEMP 27 .OPTIONS INGOLD=2 .DC VOUTS2I -3.3 6.6 0.1 .PRINT DC I(VOUTS2I) .END --------------------------- This netlist is also having DC convergence problems above 5.4V. I could edit the spi file to sweep only upto 5.4V and manually extract out the V/I datapoints and then extrapolate the data to the end range(2Vcc). It will be a very tough process considering the number of buffer types and all the V/I datapoints for each buffer. Ques#2: Is there anyway I can control the sweep range within my s2i file ? Regards, Syed. From owner-ibis Thu Dec 11 16:00:20 1997 Received: from internet-gw1.hea.com (internet-gw1.hea.com [199.97.2.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA05296 for ; Thu, 11 Dec 1997 16:00:19 -0800 (PST) Received: from internet-gw2.HEA.COM (localhost [127.0.0.1]) by internet-gw1.hea.com (8.7.6/8.7.3) with SMTP id PAA05838 for ; Thu, 11 Dec 1997 15:59:27 -0800 (PST) Received: from netmgmt.hyundai.com by internet-gw2.HEA.COM (4.1/SMI-4.1/HEA-GCA-gw2-940329-1) id AA05064; Thu, 11 Dec 97 16:01:24 PST Received: from mustang by netmgmt.hyundai.com (5.x/SMI-SVR4) id AA13336; Thu, 11 Dec 1997 15:49:12 -0800 Received: (from dselinge@localhost) by mustang (8.6.12h2/8.6.12) id PAA23915 for ibis@vhdl.org; Thu, 11 Dec 1997 15:53:53 -0800 Date: Thu, 11 Dec 1997 15:53:53 -0800 From: David Selinger(mustang) Message-Id: <199712112353.PAA23915@mustang> To: ibis@vhdl.org Subject: unsubscribe X-Sun-Charset: US-ASCII From owner-ibis Fri Dec 12 00:38:02 1997 Received: from alcatel.fr (gatekeeper.alcatel.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id AAA13942 for ; Fri, 12 Dec 1997 00:38:01 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (Alcanet/SMTP) with ESMTP id JAA17607 for ; Fri, 12 Dec 1997 09:38:02 +0100 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id JAA08999 for ; Fri, 12 Dec 1997 09:26:00 +0100 (MET) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA05657; Fri, 12 Dec 97 09:28:58 +0100 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00340; Fri, 12 Dec 97 09:28:44 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <3490F5BC.41C67EA6@ln.cit.alcatel.fr> Date: Fri, 12 Dec 1997 09:28:44 +0100 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: connector models Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Maybe someone could help me clear up a point? I've not been following recent IBIS activity as closely as I should... I'm preparing an internal presentation on IBIS, and am wondering what to say on the topic of connectors and cables. Are the following statements reasonably truthful? - Many attempts have been made to adapt IBIS to the creation of connector and cable models. No agreed synthax has been found, due mainly to the complex nature of coupling. - Limited connector and cable models are possible with IBIS 3.0, using the expanded package model and the new series element. - There is no medium-term prospect of a better IBIS synthax - Most simulator companies have developed their own connector model synthax. Comments? John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Fri Dec 12 07:39:24 1997 Received: from wile.nesa.com ([204.240.29.34]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA21517 for ; Fri, 12 Dec 1997 07:39:20 -0800 (PST) Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma005688; Fri Dec 12 10:32:19 1997 Message-Id: <3.0.3.32.19971212103422.006bc16c@mail.nesa.com> X-Sender: esayre@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 12 Dec 1997 10:34:22 -0500 To: Matthew Flora From: "Dr. Edward P. Sayre" Subject: RE: IBIS Open Forum minutes of 12/5 Cc: ibis@vhdl.org, ibis@eda.org, si-list@silab.Eng.Sun.COM In-Reply-To: <3.0.5.32.19971211142907.009839d0@mail.nwlink.com> References: <71EEA9EA5129D1118EA30000F840EBF1225B1A@sbuamapko3bc.eng.pk o.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Matthew: The User's group don't agree with your assessment. We have very specific needs and they may be different from those of the manufacturers' or EDA folks. Until we settle some of these issues amongst ourselves, it is not an Open Forum issue in my mind. We also happen to have the technical resources available at this time to address the issue. Greg Edlund and Bob Haller's approach is very supportive of that effort. ed sayre At 02:29 PM 12/11/97 -0100, you wrote: >Dear Greg Edlund, > >> I agree that a single sub-committee on IBIS model quality would be in >> the best interest of the IBIS community. >> >> As I see it there are two main topics under model quality: >> 1. Syntactical correctness >> 2. Accurate prediction of electrical hardware behavior >> >> While topic 1 may cover a myriad of common modeling errors, it can be >> easily addressed: every IBIS model must pass the golden parser. > >If it were only that easy. The Golden IBIS Parser checks the syntax of the >model, but not all of the semantics. Although the latest version of the >parser does do some testing of the data within the model, there are some >things that it simply cannot test for. For instance, the Golden IBIS Parser >has no way of knowing if all of the part's pins have been listed. So a model >could pass the parser and still not be usable with all simulators. > >This is why it was suggested that the model quality sub-committee run a model >through several different simulators as well as through the Golden IBIS >Parser. > >> Topic 2 is a bit more involved. The user community needs to see proof >> that a model developer measured the model against test hardware and the >> results were favorable. This leads to the questions, "What test >> hardware?" and "What is favorable?" This is where an amendment to the >> IBIS specification that covers model accuracy would lend great >> credibility to the IBIS model database. I think the sub-committee on >> model quality should work toward developing such an amendment, and I >> think the users and semiconductor vendors should work together toward a >> mutually agreeable solution. > >Proof of a model's accuracy is an admirable goal. However, you yourself >pointed to some big questions: "What test hardware?" "What is favorable?". >Since we would need an answer for all types of parts and since there will be >many opinions concerning what is the best answer, I would prefer not to burden >the sub-committee with such a weighty problem just yet. > >I propose that those questions be left to the full forum or be assigned to a >separate sub-committee. The model quality sub-committee (I don't believe it >has an official name yet) could be charged with "enforcing" the answers to >those questions in the future. > >Don't misunderstand me. I am not saying that the answers to those questions >shouldn't be pursued, I just don't think it is appropriate at this time for >the small sub-committee to do so. > >Regards, >Matthew Flora >Senior Engineer >HyperLynx >(425) 869-2320 PH >(425) 881-1008 FAX >mbflora@hyperlynx.com > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Fri Dec 12 07:38:47 1997 Received: from wile.nesa.com ([204.240.29.34]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA21514 for ; Fri, 12 Dec 1997 07:38:43 -0800 (PST) Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma005688; Fri Dec 12 10:32:19 1997 Message-Id: <3.0.3.32.19971212103422.006bc16c@mail.nesa.com> X-Sender: esayre@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 12 Dec 1997 10:34:22 -0500 To: Matthew Flora From: "Dr. Edward P. Sayre" Subject: RE: IBIS Open Forum minutes of 12/5 Cc: ibis@vhdl.org, ibis@eda.org, si-list@silab.Eng.Sun.COM In-Reply-To: <3.0.5.32.19971211142907.009839d0@mail.nwlink.com> References: <71EEA9EA5129D1118EA30000F840EBF1225B1A@sbuamapko3bc.eng.pk o.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Matthew: The User's group don't agree with your assessment. We have very specific needs and they may be different from those of the manufacturers' or EDA folks. Until we settle some of these issues amongst ourselves, it is not an Open Forum issue in my mind. We also happen to have the technical resources available at this time to address the issue. Greg Edlund and Bob Haller's approach is very supportive of that effort. ed sayre At 02:29 PM 12/11/97 -0100, you wrote: >Dear Greg Edlund, > >> I agree that a single sub-committee on IBIS model quality would be in >> the best interest of the IBIS community. >> >> As I see it there are two main topics under model quality: >> 1. Syntactical correctness >> 2. Accurate prediction of electrical hardware behavior >> >> While topic 1 may cover a myriad of common modeling errors, it can be >> easily addressed: every IBIS model must pass the golden parser. > >If it were only that easy. The Golden IBIS Parser checks the syntax of the >model, but not all of the semantics. Although the latest version of the >parser does do some testing of the data within the model, there are some >things that it simply cannot test for. For instance, the Golden IBIS Parser >has no way of knowing if all of the part's pins have been listed. So a model >could pass the parser and still not be usable with all simulators. > >This is why it was suggested that the model quality sub-committee run a model >through several different simulators as well as through the Golden IBIS >Parser. > >> Topic 2 is a bit more involved. The user community needs to see proof >> that a model developer measured the model against test hardware and the >> results were favorable. This leads to the questions, "What test >> hardware?" and "What is favorable?" This is where an amendment to the >> IBIS specification that covers model accuracy would lend great >> credibility to the IBIS model database. I think the sub-committee on >> model quality should work toward developing such an amendment, and I >> think the users and semiconductor vendors should work together toward a >> mutually agreeable solution. > >Proof of a model's accuracy is an admirable goal. However, you yourself >pointed to some big questions: "What test hardware?" "What is favorable?". >Since we would need an answer for all types of parts and since there will be >many opinions concerning what is the best answer, I would prefer not to burden >the sub-committee with such a weighty problem just yet. > >I propose that those questions be left to the full forum or be assigned to a >separate sub-committee. The model quality sub-committee (I don't believe it >has an official name yet) could be charged with "enforcing" the answers to >those questions in the future. > >Don't misunderstand me. I am not saying that the answers to those questions >shouldn't be pursued, I just don't think it is appropriate at this time for >the small sub-committee to do so. > >Regards, >Matthew Flora >Senior Engineer >HyperLynx >(425) 869-2320 PH >(425) 881-1008 FAX >mbflora@hyperlynx.com > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Fri Dec 12 08:34:07 1997 Received: from minos.intel.com ([134.134.214.6]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA22442 for ; Fri, 12 Dec 1997 08:34:06 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by minos.intel.com (8.8.6/8.8.5) with ESMTP id IAA25646; Fri, 12 Dec 1997 08:30:51 -0800 (PST) Received: from xtg801 (xtg801.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id IAA23263; Fri, 12 Dec 1997 08:26:15 -0800 (PST) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1) id IAA17014; Fri, 12 Dec 1997 08:24:09 -0800 (PST) Message-Id: <199712121624.IAA17014@xtg801> X-Mailer: exmh version 1.6.9 8/22/96 To: John V Fitzpatrick Cc: ibis@vhdl.org Subject: Re: connector models In-reply-to: Your message of "Fri, 12 Dec 1997 09:28:44 +0100." <3490F5BC.41C67EA6@ln.cit.alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Dec 1997 08:24:07 -0800 From: Stephen Peters On Fri, 12 Dec 1997 09:28:44 John Fitzpatrick wrote: > Hello, > > Maybe someone could help me clear up a point? > I've not been following recent IBIS activity > as closely as I should... > > I'm preparing an internal presentation on IBIS, and am > wondering what to say on the topic of connectors and cables. > > Are the following statements reasonably truthful? > > - Many attempts have been made to adapt IBIS to > the creation of connector and cable models. No > agreed synthax has been found, due mainly to the > complex nature of coupling. > - Limited connector and cable models are possible with > IBIS 3.0, using the expanded package model and the new > series element. > - There is no medium-term prospect of a better IBIS synthax > - Most simulator companies have developed their own > connector model synthax. > > Comments? > John Yes, I think that is a very accurate statement of the situation. Regards, Stephen Peters Intel Corp. From owner-ibis Fri Dec 12 11:10:54 1997 Received: from alabama.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA25020 for ; Fri, 12 Dec 1997 11:10:53 -0800 (PST) Received: (from kellee@localhost) by alabama.nwlink.com (8.8.8/8.8.8) id LAA25369; Fri, 12 Dec 1997 11:08:46 -0800 (PST) Message-Id: <3.0.5.32.19971212110850.00dc8dc0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Dec 1997 11:08:50 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Re: connector models In-Reply-To: <3490F5BC.41C67EA6@ln.cit.alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi John, At 09:28 AM 12/12/97 +0100, you wrote: >Are the following statements reasonably truthful? > - Many attempts have been made to adapt IBIS to > the creation of connector and cable models. No > agreed synthax has been found, due mainly to the > complex nature of coupling. The problem is just the lack of energy. We were very close to agreement at last years Design Super Con. The major problem I saw is that the participants from the connector companies have not provide enough energy to get resolution. If one or more connector companies put in even a small fraction of the energy that an Intel or National Semi puts into IBIS this would have been completed long ago. > - Limited connector and cable models are possible with > IBIS 3.0, using the expanded package model and the new > series element. yes > - There is no medium-term prospect of a better IBIS synthax I would agree there is no short term prospect. Medium term is always possible just needs energy from a few good people. Long term is highly probable > - Most simulator companies have developed their own > connector model synthax. Or they use one of the formats developed by a connector company. However there is alot to be desired in any format I am currently aware of. This is one thing that has made it so difficult to accomplish an IBIS standard for connector modeling. It is easy to agreement on a simple standard for connector models. It was difficult to get acceptance of that being good enough for a first pass. So rather than go forward with something basic we got nothing! Summary: We let those that must have everything or some special interest prevent the creation of simple starting point. This could have been overcome with a small push from one or two people after last years Design Super Con. Anyone with some energy to provide could make the difference on this one. It will take a few months to revive it though. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Fri Dec 12 11:10:43 1997 Received: from InterJet.apsimtech.com (apsimtech.com [209.21.21.35]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA25016 for ; Fri, 12 Dec 1997 11:10:42 -0800 (PST) Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id KAA28019; Fri, 12 Dec 1997 10:19:25 -0800 (PST) Received: from UNKNOWN(), claiming to be "contec12" via SMTP by InterJet.apsimtech.com, id smtpd028016; Fri Dec 12 10:19:21 1997 Sender: fred@apsimtech.com Message-ID: <34918011.2B01@apsimtech.com> Date: Fri, 12 Dec 1997 10:18:57 -0800 From: Fred Balistreri Organization: Apsim X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.3 sun4c) MIME-Version: 1.0 To: Stephen Peters CC: John V Fitzpatrick , ibis@vhdl.org Subject: Re: connector models References: <199712121624.IAA17014@xtg801> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Peters wrote: > > On Fri, 12 Dec 1997 09:28:44 John Fitzpatrick wrote: > > > Hello, > > > > Maybe someone could help me clear up a point? > > I've not been following recent IBIS activity > > as closely as I should... > > > > I'm preparing an internal presentation on IBIS, and am > > wondering what to say on the topic of connectors and cables. > > > > Are the following statements reasonably truthful? > > > > - Many attempts have been made to adapt IBIS to > > the creation of connector and cable models. No > > agreed synthax has been found, due mainly to the > > complex nature of coupling. > > - Limited connector and cable models are possible with > > IBIS 3.0, using the expanded package model and the new > > series element. > > - There is no medium-term prospect of a better IBIS synthax > > - Most simulator companies have developed their own > > connector model synthax. > > > > Comments? > > John > > Yes, I think that is a very accurate statement of the situation. > > Regards, > Stephen Peters > Intel Corp. Its even a bit worse than that. Connector makers typically model the electrical characteristics with some sort of field solver. The output of the field solver can be in various formats. The most common is Spice syntax. However it may be S parameters if a full wave solution is used. Its clear that those companys will have to be accessed and convienced to put out the models in IBIS format......once we can agree to some standard. We are currently still working on semiconductor vendors. Based on that experience I don't think its going to be an easy job. I do have faith in Bob Ross and crew though. Best Regards, -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Mon Dec 15 04:49:39 1997 Received: from coach.molex.com ([209.28.10.6]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id EAA19644 for ; Mon, 15 Dec 1997 04:49:37 -0800 (PST) From: apanella@molex.com Received: from ccMail by coach.molex.com (IMA Internet Exchange 3.0 Enterprise Beta 1) id 00000DCA; Mon, 15 Dec 97 06:48:50 -0330 Mime-Version: 1.0 Date: Mon, 15 Dec 1997 06:44:04 -0330 Message-ID: <00000DCA.eval@molex.com> Subject: Re[2]: connector models To: ibis@vhdl.org, Kellee Crisafulli Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Greetings All... Just for clarification... The connector companies main issue with IBIS is the lack of coupled line modeling. The connector companies suggested the use of a Maxwell matrix for the connector models a couple of years ago. I think a partial option has been installed in the V.3.0 IBIS specification. As far as "first pass".... I beleive that IBIS in V.2.0 can support series L, parallel C, and series R. This is the simplest solution with the most probablility of inaccurate results. ~~~~~~~ Now I think the other significant problem is going to become apparent... The fact the IBIS simulators have different methods of "circuit solving". When a connector model is provided in matrix format, the results will depend on the simulators solution algorithms (not an issue with Berkeley SPICE). I am concerned that connector models will perform differently on different simulators. Is this a valid concern?? ~~~~~~~~ A part of the problem might be... (besides the above concern) * Semiconductor manufactures need a way to provide models that do not provide insighth to proprietary fabrication methods. Connector companies already have this... SPICE. * Some SPICE simulators can accept some versions of IBIS models some can not support IBIS at all. Are there any IBIS simulators that support SPICE? In this case, it all depends on were the "energy" is assigned. Most connector companies do not sell simulation software. As such connector companies might not be the best source for driving this issue. Gus Panella Molex, Incorporated. ______________________________ Reply Separator _________________________________ Subject: Re: connector models Author: Kellee Crisafulli at INTERNET Date: 97/12/12 11:08 AM Hi John, At 09:28 AM 12/12/97 +0100, you wrote: >Are the following statements reasonably truthful? > - Many attempts have been made to adapt IBIS to > the creation of connector and cable models. No > agreed synthax has been found, due mainly to the > complex nature of coupling. The problem is just the lack of energy. We were very close to agreement at last years Design Super Con. The major problem I saw is that the participants from the connector companies have not provide enough energy to get resolution. If one or more connector companies put in even a small fraction of the energy that an Intel or National Semi puts into IBIS this would have been completed long ago. > - Limited connector and cable models are possible with > IBIS 3.0, using the expanded package model and the new > series element. yes > - There is no medium-term prospect of a better IBIS synthax I would agree there is no short term prospect. Medium term is always possible just needs energy from a few good people. Long term is highly probable > - Most simulator companies have developed their own > connector model synthax. Or they use one of the formats developed by a connector company. However there is alot to be desired in any format I am currently aware of. This is one thing that has made it so difficult to accomplish an IBIS standard for connector modeling. It is easy to agreement on a simple standard for connector models. It was difficult to get acceptance of that being good enough for a first pass. So rather than go forward with something basic we got nothing! Summary: We let those that must have everything or some special interest prevent the creation of simple starting point. This could have been overcome with a small push from one or two people after last years Design Super Con. Anyone with some energy to provide could make the difference on this one. It will take a few months to revive it though. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Mon Dec 15 05:39:11 1997 Received: from alcatel.fr (news2.alcatel.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id FAA20484 for ; Mon, 15 Dec 1997 05:39:07 -0800 (PST) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (Alcanet/SMTP) with ESMTP id OAA28944; Mon, 15 Dec 1997 14:37:33 +0100 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id OAA22544; Mon, 15 Dec 1997 14:32:44 +0100 (MET) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA13943; Mon, 15 Dec 97 14:36:02 +0100 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00389; Mon, 15 Dec 97 14:35:37 +0100 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <34953228.2781E494@ln.cit.alcatel.fr> Date: Mon, 15 Dec 1997 14:35:37 +0100 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Cc: Kellee Crisafulli Subject: Re: connector models References: <3.0.5.32.19971212110850.00dc8dc0@mail.nwlink.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id FAA20485 All, Thanks to everyone who replied to my recent message. I was hoping against hope that my summary was too pessimistic, but it wasn't. I attended the Design SuperCon, and remember the heated debates on matrix formats, definition of the where ground is, etc. There seemed to be little shortage of energy that day! I've been thinking a bit about how I characterise connectors for SI simulation. Basically, I just do a differential TDR measurement between two connector pins. This gives me impedance and coupling, plus lots of hints as to where the discontinuities are. Then I go build a Spice model of the connector which gives me the same TDR result in simulation. The detail of the model depends on the application. IBIS basic models are measurement based. So I could easily imagine a basic connector model containing common mode and differential TDR curves between pairs of points. Because connectors have a lot of symmetry,2-4 sets of curves should be enough. [Connector] InputPinA InputPinB OutputPinA OutputPinB Model [Model] Model_type Connector [Differential TDR] Time Vtyp Vmax Vmin [Common Mode TDR] Time Vtyp Vmax Vmin Then it would be up to the simulator to create a circuit model based on the TDR measurements, but that's only software :-) Bonnes fetes à tous! (Yes, the French can be politically correct too...) John > Summary: > We let those that must have everything or some special > interest prevent the creation of simple starting point. > This could have been overcome with a small push from > one or two people after last years Design Super Con. > Anyone with some energy to provide could make the difference > on this one. It will take a few months to revive it > though. -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Mon Dec 15 08:15:53 1997 Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA23123 for ; Mon, 15 Dec 1997 08:15:52 -0800 (PST) Received: from enterprise (ip120.kansas-city7.mo.pub-ip.psi.net [38.27.83.120]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id LAA28118; Mon, 15 Dec 1997 11:13:31 -0500 (EST) Message-Id: <3.0.32.19971215100344.007aab10@pop.mindspring.com> X-Sender: bogatine@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 15 Dec 1997 10:12:54 -0600 To: ibis@vhdl.org From: Eric Bogatin Subject: Re: Re[2]: connector models Cc: bogatin@ansoft.com, apanella@molex.com Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Please forgive my ignorance if I repeat what has already been said, as I only periodically follow the IBIS forum. I wanted to add my vote of support to what Gus Panella said about connector models. I've caught parts of threads from previous discussions about how to model a connector in such a way that the model can be used by SPICE for signal integrity analysis of such effects as reflection noise, cross talk and ground bounce. Then there's the question of how do you model it so that you can do arbitrary assignment of ground connections after the fact. The last issue is how to take this model and integrate it in a formalism that an IBIS simulation can use. I think the modeling of connectors, as well as leaded IC packages, and most other physically small structures with multiple leads, is straight forward and unambiguous. The equivalent circuit model includes the series elements, R, L and C to ground for each lead. In addition, there are the coupling terms between every pair of leads. There is the capacitance between each pair of leads and the mutual inductance between each pair of leads. When you have more than two leads, it gets complicated just keeping track of all the terms, so it is convenient to use a matrix formalism to describe the different terms. However, keep in mind that the matrices are just a short hand to track the terms that exist in the equivalent circuit model. With this circuit model, SPICE can model all the signal integrity effects. However, there is a limitation to the bandwidth of such a model. The shortest rise time that can accurately be simulated with this lumped circuit model is roughly reached when the time of flight through the connector is greater than about 1/3 the rise time. For a 150 psec time delay connector, this lumped circuit model is accurate for rise times greater than 450 psec, for example. Otherwise, absolutely all the electrical effects (except EMI) of this connector can be described by this circuit model. Why don't we adopt this circuit model as the simplest starting place? The concept of coupling capacitance is right out of SPICE. If you can draw the equivalent circuit, each of the capacitances you draw has an unambiguous value in SPICE. You just have to use engineering experience to extract these SPICE values from either a measurement or a field solver calculation. Some of the confusion arises because field solvers also report results in terms of capacitance matrices. However, the field solver definition of capacitance matrix is not the same definition of the matrix as used by SPICE. As long as you use the term 'SPICE' matrix or 'Maxwell' matrix (named for James Clerk maxwell, not an Ansoft term), there is no ambiguity. Most field solver tools will automatically convert between the two forms. I don't think there is any ambiguity in either of these uses of a capacitance matrix. Either one has a complete electrical description of the coupling capacitance between a collection of leads. The inductance terms are a bit more confusing. Some folks use the term loop inductance or effective inductance to describe the inductance of a lead or pair of leads. There are unambiguous definitions for each of these terms, though they are not often used correctly. What is confusing is that SPICE does not use either term. The SPICE definition of inductance is based on the concept of partial inductance. There is a lot of confusion and debate in the industry about this concept, but the fact remains that it is in popular use and works just fine. There are two kinds of inductances, partial self inductance and partial mutual inductance. If you have ever used the terms self or mutual inductance, you were really referring to partial inductances whether you knew it or not. When you draw a circuit diagram with inductances in it, and then write a SPICE deck for it, you are really using partial inductances. In a collection of leads, each lead has a partial self inductance and between every pair of leads there is a partial mutual inductance. Again, to keep track of them, it is useful to use a matrix. The diagonal elements are the self inductances, the off diagonal terms are the mutual inductances. The output of some field solvers is the same partial inductance matrix as is used with SPICE. There is no ambiguity about a circuit diagram and a partial inductance matrix. We have just gotten in the habit of calling it simply an inductance matrix, so it gets confused with loop and effective inductance. The value of this matrix is that you can now decompose any loop, which is what is measured, in terms of combinations of self and mutual inductances. The matrix values are purely a geometrical effect. The actual currents in the leads does not affect the value of the inductance matrix elements. Once you have the matrix, you can construct the equivalent circuit diagram and calculate any loop that might be measured. It is more difficult to go the other way- from measurements, extract the self and mutual inductances. It is possible, but requires some tricks. This means that if you have the (partial) inductance matrix for a connector, you can use it directly, with the circuit topology, in a SPICE situation and assign return paths after the fact in the circuit diagram. This model will allow the accurate calculation of ground bounce, as the return path is changed in the circuit diagram. My apologies if I have gone on too long on a topic that is obvious to some of you. If you would like more information, Gus and I wrote a paper on using partial inductance to model connectors that was in the 30th Annual Connector and Interconnection Symposium, 1997, Anaheim, CA. Contact me off line and I can get you a copy. --eric At 06:44 AM 12/15/97 -0330, apanella@molex.com wrote: > Greetings All... > > Just for clarification... > > The connector companies main issue with IBIS is the lack of coupled > line modeling. > > The connector companies suggested the use of a Maxwell matrix for the > connector models a couple of years ago. I think a partial option has > been installed in the V.3.0 IBIS specification. > > As far as "first pass".... I beleive that IBIS in V.2.0 can support > series L, parallel C, and series R. This is the simplest solution > with the most probablility of inaccurate results. > > > ~~~~~~~ > Now I think the other significant problem is going to become > apparent... The fact the IBIS simulators have different methods of > "circuit solving". When a connector model is provided in matrix > format, the results will depend on the simulators solution algorithms > (not an issue with Berkeley SPICE). > > I am concerned that connector models will perform differently on > different simulators. Is this a valid concern?? > ~~~~~~~~ > > > A part of the problem might be... (besides the above concern) > > * Semiconductor manufactures need a way to provide models that do not > provide insighth to proprietary fabrication methods. Connector > companies already have this... SPICE. > > * Some SPICE simulators can accept some versions of IBIS models some > can not support IBIS at all. Are there any IBIS simulators that > support SPICE? In this case, it all depends on were the "energy" is > assigned. Most connector companies do not sell simulation software. > As such connector companies might not be the best source for driving > this issue. > > > > Gus Panella > Molex, Incorporated. > > >______________________________ Reply Separator _________________________________ >Subject: Re: connector models >Author: Kellee Crisafulli < at INTERNET >Date: 97/12/12 11:08 AM > > >Hi John, > >At 09:28 AM 12/12/97 +0100, you wrote: >>Are the following statements reasonably truthful? >> - Many attempts have been made to adapt IBIS to >> the creation of connector and cable models. No >> agreed synthax has been found, due mainly to the >> complex nature of coupling. >The problem is just the lack of energy. >We were very close to agreement at last years >Design Super Con. The major problem I saw is that the participants >from the connector companies have not provide enough energy to >get resolution. If one or more connector companies put in even a >small fraction of the energy that an Intel or National Semi puts into >IBIS this would have been completed long ago. > >> - Limited connector and cable models are possible with >> IBIS 3.0, using the expanded package model and the new >> series element. >yes > >> - There is no medium-term prospect of a better IBIS synthax >I would agree there is no short term prospect. Medium term is >always possible just needs energy from a few good people. >Long term is highly probable > >> - Most simulator companies have developed their own >> connector model synthax. >Or they use one of the formats developed by a connector company. However >there is alot to be desired in any format I am currently aware of. This is >one thing that has made it so difficult to accomplish an IBIS standard for >connector >modeling. It is easy to agreement on a simple standard for connector models. >It was >difficult to get acceptance of that being good enough for a first pass. So >rather than >go forward with something basic we got nothing! > >Summary: >We let those that must have everything or some special interest prevent the >creation >of simple starting point. This could have been overcome with a small push from >one or two people after last years Design Super Con. Anyone with some energy to >provide could make the difference on this one. It will take a few months to >revive it >though. > > > > >------------------------------------------------------------------------- >Have a great day... >Kellee Crisafulli at HyperLynx >kellee@hyperlynx.com http://www.hyperlynx.com >------------------------------------------------------------------------- > ********************************************************************** Eric Bogatin Product Manager, Signal Integrity Products Ansoft Corporation 26235 W. 110th Terr. Olathe, KS 66061 voice: 913-393-1305 fax: 913-393-1306 email: bogatin@ansoft.com pager: 888-775-1138 web site: 0000,0000,ffffwww.ansoft.com "In God we trust, all others, show your data" ********************************************************************** From owner-ibis Mon Dec 15 09:48:51 1997 Received: from alabama.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA24774 for ; Mon, 15 Dec 1997 09:48:51 -0800 (PST) Received: from stargate (mail.hyperlynx.com [209.20.148.70]) by alabama.nwlink.com (8.8.8/8.8.8) with SMTP id JAA19818; Mon, 15 Dec 1997 09:46:27 -0800 (PST) Message-Id: <3.0.32.19971215094856.00938ad0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 15 Dec 1997 09:49:01 -0800 To: apanella@molex.com, ibis@vhdl.org From: Kellee Crisafulli Subject: Re: Re[2]: connector models Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Gus,IBIS At 06:44 AM 12/15/97 -0330, apanella@molex.com wrote: > The connector companies main issue with IBIS is the lack of coupled > line modeling. > The connector companies suggested the use of a Maxwell matrix for the > connector models a couple of years ago. I think a partial option has > been installed in the V.3.0 IBIS specification. Close but it is not used and it isn't set up for connectors. > As far as "first pass".... I beleive that IBIS in V.2.0 can support > series L, parallel C, and series R. This is the simplest solution > with the most probablility of inaccurate results. It doesn't work for connectors. Connectors need an input and an output defined. The pin definitions in IBIS 2.0 don't provide that. The Version 3.0 sytax is much closer with the additions that Steven Peters made. > Now I think the other significant problem is going to become > apparent... The fact the IBIS simulators have different methods of > "circuit solving". When a connector model is provided in matrix > format, the results will depend on the simulators solution algorithms > (not an issue with Berkeley SPICE). Not true. It is the same issue as for Spice, the problem is a standard. Just a coupling matrix is not a connector model. It could be; but just as it could be in Spice the format must be agree upon and then the simulators all work. > I am concerned that connector models will perform differently on > different simulators. Is this a valid concern?? Yes, but it should not be a problem if the format is well defined. > A part of the problem might be... (besides the above concern) > * Semiconductor manufactures need a way to provide models that do not > provide insighth to proprietary fabrication methods. Connector > companies already have this... SPICE. Perhaps but it is not in any sort of standard format. Each connector company uses different syntax. Also not all Spice packages support all connector formats. Also most connector companies do not provide their models for open download over the web. It requires an NDA or even extra fees. > Some SPICE simulators can accept some versions of IBIS models some > can not support IBIS at all. Are there any IBIS simulators that > support SPICE? In this case, it all depends on were the "energy" is > assigned. IBIS is not a simulator. IBIS is a description format, as has been pointed out by several people on this forum. Many Spice packages support IBIS. All SI simulators I know of support IBIS. Spice syntax has evolved in 30 separate directions over the years. It is now to the point that it is very difficult to exchange Spice files between two different types of Spice simulators and have it work. With IBIS we are attempting to maintain a standard syntax that all simulators can use including Spice. > Most connector companies do not sell simulation software. > As such connector companies might not be the best source for driving > this issue. This I believe is the real issue, I feel the connector company's participation is critical. As I work at a simulator company I would very much like to see all the connector companies participate in developing a single standard that all companies could use. It is certainly not required that the connector company have a simulator. In fact I think it is a big disadvantage because then they become biased toward their simulator. Perhaps we need a multi-day focused session on connector modeling to hammer out a syntax. I would very much like to see all the connector company's represented at the Jan. Design Con IBIS meeting and start to hammer out a solution. Perhaps we do a Phase 1, Phase 2, Phase 3. From owner-ibis Mon Dec 15 10:45:49 1997 Received: from wile.nesa.com ([204.240.29.34]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id KAA25902 for ; Mon, 15 Dec 1997 10:45:44 -0800 (PST) Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma028517; Mon Dec 15 13:39:15 1997 Message-Id: <3.0.3.32.19971215134121.006c3524@mail.nesa.com> X-Sender: esayre@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 15 Dec 1997 13:41:21 -0500 To: John V Fitzpatrick From: "Dr. Edward P. Sayre" Subject: Re: IBIS connector models Cc: baxter@nesa.com, chen@nesa.com, Edward Sayre , ibis@vhdl.org, ibis@eda.org, si-list@silab.Eng.Sun.COM In-Reply-To: <34953228.2781E494@ln.cit.alcatel.fr> References: <3.0.5.32.19971212110850.00dc8dc0@mail.nwlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" John & others: Do you do your measurements with connector mounted on a circuit card with ground planes or is the connect probed at the connection points with 50 ohm probing? Using your differential measurement, how do you account for signal/ground positions or ratios? I favor mounting connectors on circuit cards to include the mounting and footprint effects. I do not favor Maxwell matrices in IBIS unless they can be measured and characterized. Many Maxwell matrices include as many as 30+ crossections with no real justification on circuit element grounds for the large number. They often do not account for losses very well either. Aside from that, Maxwell matrices are not theoretically what one measures in a coupled N-port circuit measurement. Ed Sayre +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Mon Dec 15 10:46:25 1997 Received: from wile.nesa.com ([204.240.29.34]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id KAA25909 for ; Mon, 15 Dec 1997 10:46:22 -0800 (PST) Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma028517; Mon Dec 15 13:39:15 1997 Message-Id: <3.0.3.32.19971215134121.006c3524@mail.nesa.com> X-Sender: esayre@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 15 Dec 1997 13:41:21 -0500 To: John V Fitzpatrick From: "Dr. Edward P. Sayre" Subject: Re: IBIS connector models Cc: baxter@nesa.com, chen@nesa.com, Edward Sayre , ibis@vhdl.org, ibis@eda.org, si-list@silab.Eng.Sun.COM In-Reply-To: <34953228.2781E494@ln.cit.alcatel.fr> References: <3.0.5.32.19971212110850.00dc8dc0@mail.nwlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" John & others: Do you do your measurements with connector mounted on a circuit card with ground planes or is the connect probed at the connection points with 50 ohm probing? Using your differential measurement, how do you account for signal/ground positions or ratios? I favor mounting connectors on circuit cards to include the mounting and footprint effects. I do not favor Maxwell matrices in IBIS unless they can be measured and characterized. Many Maxwell matrices include as many as 30+ crossections with no real justification on circuit element grounds for the large number. They often do not account for losses very well either. Aside from that, Maxwell matrices are not theoretically what one measures in a coupled N-port circuit measurement. Ed Sayre +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Mon Dec 15 12:50:43 1997 Received: from coach.molex.com (coach.molex.com [209.28.10.6]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA28099 for ; Mon, 15 Dec 1997 12:50:39 -0800 (PST) From: apanella@molex.com Received: from ccMail by coach.molex.com (IMA Internet Exchange 3.0 Enterprise Beta 1) id 00001092; Mon, 15 Dec 97 14:48:52 -0330 Mime-Version: 1.0 Date: Mon, 15 Dec 1997 14:44:41 -0330 Message-ID: <00001092.eval@molex.com> Subject: Re[4]: connector models To: ibis@vhdl.org, Kellee Crisafulli Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Greetings... First Kellee, Thanks for the insight into what V2 and V3 support (as far as connectors are concerned). It has been my experience that some of our customers beleive that IBIS can be used for even the most basic connector models. Please correct me if I misinterpretted the V2 and V3 statements. In regards to Connector model format.. * All SPICE simulators I know of can read Berkeley SPICE format lists. I think there is a similiar goal in the IBIS committee / specification... that all IBIS simulators can read all IBIS format models. For this reason, we have taken a position as a company to only support a Berkeley compatible format. From your comments, I've learned that this is not the case for all connector manufacturers. Per comments below, is there a SPICE simulator that can not accept Berkeley SPICE that is known to the IBIS group? The following might be seen as an agressive statement, that is not my intent. Is it reasonable to suggest that the IBIS specification support standard Berkely SPICE formats for 3e1. I do not know the extended impact of this suggestion on the rest of the IBIS world. I apologize in advance for stepping on anyone's toes. But, I think the connector companies might find this an acceptable standard format. It gets around the matrix issue and model confirmation issues (i.e. a model only needs to be confirmed to empiricals in Berkely SPICE, not in every SI simulator in the market) Comments??? * SI simulators... What is the definition of a SI simulator. I don't think Berkely SPICE supports the IBIS format and it may be considered a SI simulator. I don't have an answer here.... But I would like to refine a common definition. Comments? In regards to providing open downloads over the web... ** Model complexity is a big issue here. Many times end users need assistance in dealing with a connector SPICE model. As such, support is generally needed. We distribute SPICE models on a one on one basis in order to assure that we are able to provide effective support ** In regards to NDA's... Yes, they do exist... mainly it is to provide protection for the newer designs. Remember, in a connector companies case... a signal integrity solution is a portion of our product, as such it is something that we (connector companies) would like to generally keep from our competition. As far as.. Meeting to hammering out a syntax... I would like to invite the IBIS group to evaluate the use of SPICE component syntax as outlined in SPICE 3e1 Users manual, April 1, 1991, for support in the IBIS syntax. Is this an acceptable addition to the IBIS syntax? If not.... why? This way we (as an IBIS group) might document a discussion matrix before we start in a meeting. Comments?? Gus Panella Molex, Inc. PH:630-527-4617 ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: connector models Author: Kellee Crisafulli at INTERNET Date: 97/12/15 9:49 AM Hi Gus,IBIS At 06:44 AM 12/15/97 -0330, apanella@molex.com wrote: > The connector companies main issue with IBIS is the lack of coupled > line modeling. > The connector companies suggested the use of a Maxwell matrix for the > connector models a couple of years ago. I think a partial option has > been installed in the V.3.0 IBIS specification. Close but it is not used and it isn't set up for connectors. > As far as "first pass".... I beleive that IBIS in V.2.0 can support > series L, parallel C, and series R. This is the simplest solution > with the most probablility of inaccurate results. It doesn't work for connectors. Connectors need an input and an output defined. The pin definitions in IBIS 2.0 don't provide that. The Version 3.0 sytax is much closer with the additions that Steven Peters made. > Now I think the other significant problem is going to become > apparent... The fact the IBIS simulators have different methods of > "circuit solving". When a connector model is provided in matrix > format, the results will depend on the simulators solution algorithms > (not an issue with Berkeley SPICE). Not true. It is the same issue as for Spice, the problem is a standard. Just a coupling matrix is not a connector model. It could be; but just as it could be in Spice the format must be agree upon and then the simulators all work. > I am concerned that connector models will perform differently on > different simulators. Is this a valid concern?? Yes, but it should not be a problem if the format is well defined. > A part of the problem might be... (besides the above concern) > * Semiconductor manufactures need a way to provide models that do not > provide insighth to proprietary fabrication methods. Connector > companies already have this... SPICE. Perhaps but it is not in any sort of standard format. Each connector company uses different syntax. Also not all Spice packages support all connector formats. Also most connector companies do not provide their models for open download over the web. It requires an NDA or even extra fees. > Some SPICE simulators can accept some versions of IBIS models some > can not support IBIS at all. Are there any IBIS simulators that > support SPICE? In this case, it all depends on were the "energy" is > assigned. IBIS is not a simulator. IBIS is a description format, as has been pointed out by several people on this forum. Many Spice packages support IBIS. All SI simulators I know of support IBIS. Spice syntax has evolved in 30 separate directions over the years. It is now to the point that it is very difficult to exchange Spice files between two different types of Spice simulators and have it work. With IBIS we are attempting to maintain a standard syntax that all simulators can use including Spice. > Most connector companies do not sell simulation software. > As such connector companies might not be the best source for driving > this issue. This I believe is the real issue, I feel the connector company's participation is critical. As I work at a simulator company I would very much like to see all the connector companies participate in developing a single standard that all companies could use. It is certainly not required that the connector company have a simulator. In fact I think it is a big disadvantage because then they become biased toward their simulator. Perhaps we need a multi-day focused session on connector modeling to hammer out a syntax. I would very much like to see all the connector company's represented at the Jan. Design Con IBIS meeting and start to hammer out a solution. Perhaps we do a Phase 1, Phase 2, Phase 3. From owner-ibis Mon Dec 15 14:38:40 1997 Received: from coach.molex.com (coach.molex.com [209.28.10.6]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id OAA00049 for ; Mon, 15 Dec 1997 14:38:38 -0800 (PST) From: apanella@molex.com Received: from ccMail by coach.molex.com (IMA Internet Exchange 3.0 Enterprise Beta 1) id 00001117; Mon, 15 Dec 97 16:37:52 -0330 Mime-Version: 1.0 Date: Mon, 15 Dec 1997 16:32:11 -0330 Message-ID: <00001117.eval@molex.com> Subject: Re[2]: IBIS connector models To: "Dr. Edward P. Sayre" Cc: baxter@nesa.com, chen@nesa.com, Edward Sayre , ibis@vhdl.org, ibis@eda.org, si-list@silab.Eng.Sun.COM Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Greetings, RE: Including mounting foot prints in the model... We reviewed this a while ago. A problem we've seen with this approach is that there are not standard routing methods or layer definitions. This precludes the creation of a general connector model. In our business making a special connector model for each application could become un-manageable. As such, our standard model only provides a connector model from where the current enters the connector to where the current exits the connector. This allows pcb models to be added to the connector model. RE: 30+ cross sections... There are sometimes reasons for multiple cross section models. Technical explanation is too long for this email. But generally, I would suggest that most models do not exceed 15 sections. (Maybe I should confirm what you mean by "cross sections" first. I might have a different definition than to what you are referring." RE: Justification for circuit grounds. Many connectors models do not have defined grounds. CURRENT RETURN PATHS can be defined in SPICE. We supply these type of models on a regular basis. RE: Accounting for losses... What is meant by not very well? I think this is relative to wavelength... right?? RE: correlating Maxwell matrices to measured data. It can be done. It has been done. It does take some work. It does take some special measurement and matrix extraction techniques. Again, technical explanation is too long for this email. RE: ... N-port circuit measurement ... One can use the same VNA to measure L, C and Z. These results can be correlated to matrix results. It does take some special measurement and matrix extraction techniques. Again, technical explanation is too long for this email. However... I believe that, N-Port measurements are seen as most appropriate for first order effects (??), sometimes (for better accuracy) further effects need to be reviewed. Gus Panella Molex, Inc. Ph: 630-527-4617 ______________________________ Reply Separator _________________________________ Subject: Re: IBIS connector models Author: "Dr. Edward P. Sayre" at INTERNET Date: 97/12/15 1:41 PM John & others: Do you do your measurements with connector mounted on a circuit card with ground planes or is the connect probed at the connection points with 50 ohm probing? Using your differential measurement, how do you account for signal/ground positions or ratios? I favor mounting connectors on circuit cards to include the mounting and footprint effects. I do not favor Maxwell matrices in IBIS unless they can be measured and characterized. Many Maxwell matrices include as many as 30+ crossections with no real justification on circuit element grounds for the large number. They often do not account for losses very well either. Aside from that, Maxwell matrices are not theoretically what one measures in a coupled N-port circuit measurement. Ed Sayre +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Mon Dec 15 14:38:41 1997 Received: from coach.molex.com (coach.molex.com [209.28.10.6]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id OAA00048 for ; Mon, 15 Dec 1997 14:38:38 -0800 (PST) From: apanella@molex.com Received: from ccMail by coach.molex.com (IMA Internet Exchange 3.0 Enterprise Beta 1) id 00001117; Mon, 15 Dec 97 16:37:52 -0330 Mime-Version: 1.0 Date: Mon, 15 Dec 1997 16:32:11 -0330 Message-ID: <00001117.eval@molex.com> Subject: Re[2]: IBIS connector models To: "Dr. Edward P. Sayre" Cc: baxter@nesa.com, chen@nesa.com, Edward Sayre , ibis@vhdl.org, ibis@eda.org, si-list@silab.Eng.Sun.COM Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Greetings, RE: Including mounting foot prints in the model... We reviewed this a while ago. A problem we've seen with this approach is that there are not standard routing methods or layer definitions. This precludes the creation of a general connector model. In our business making a special connector model for each application could become un-manageable. As such, our standard model only provides a connector model from where the current enters the connector to where the current exits the connector. This allows pcb models to be added to the connector model. RE: 30+ cross sections... There are sometimes reasons for multiple cross section models. Technical explanation is too long for this email. But generally, I would suggest that most models do not exceed 15 sections. (Maybe I should confirm what you mean by "cross sections" first. I might have a different definition than to what you are referring." RE: Justification for circuit grounds. Many connectors models do not have defined grounds. CURRENT RETURN PATHS can be defined in SPICE. We supply these type of models on a regular basis. RE: Accounting for losses... What is meant by not very well? I think this is relative to wavelength... right?? RE: correlating Maxwell matrices to measured data. It can be done. It has been done. It does take some work. It does take some special measurement and matrix extraction techniques. Again, technical explanation is too long for this email. RE: ... N-port circuit measurement ... One can use the same VNA to measure L, C and Z. These results can be correlated to matrix results. It does take some special measurement and matrix extraction techniques. Again, technical explanation is too long for this email. However... I believe that, N-Port measurements are seen as most appropriate for first order effects (??), sometimes (for better accuracy) further effects need to be reviewed. Gus Panella Molex, Inc. Ph: 630-527-4617 ______________________________ Reply Separator _________________________________ Subject: Re: IBIS connector models Author: "Dr. Edward P. Sayre" at INTERNET Date: 97/12/15 1:41 PM John & others: Do you do your measurements with connector mounted on a circuit card with ground planes or is the connect probed at the connection points with 50 ohm probing? Using your differential measurement, how do you account for signal/ground positions or ratios? I favor mounting connectors on circuit cards to include the mounting and footprint effects. I do not favor Maxwell matrices in IBIS unless they can be measured and characterized. Many Maxwell matrices include as many as 30+ crossections with no real justification on circuit element grounds for the large number. They often do not account for losses very well either. Aside from that, Maxwell matrices are not theoretically what one measures in a coupled N-port circuit measurement. Ed Sayre +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.508.897-8787 | | Stow, MA 01775 USA Fax +1.508.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Tue Dec 16 09:28:28 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id JAA20052 for ; Tue, 16 Dec 1997 09:28:28 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id JAA27228; Tue, 16 Dec 1997 09:26:17 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma026989; Tue, 16 Dec 97 09:26:02 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA03729 for ibis@vhdl.org; Tue, 16 Dec 97 09:25:54 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04382; Tue, 16 Dec 97 09:28:01 PST Date: Tue, 16 Dec 97 09:28:01 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9712161728.AA04382@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS Summit'98 & DesignCon discounts Cc: margery.conner@postoffice.worldnet.att.net IBISfans: Mark your calendar for the IBIS Summit'98 meeting: Place: Westin Hotel (Next to Santa Clara Convention Center - DesignCon98) 5101 Great America Parkway Santa Clara, California (408)986-0700 Date: Jan 26th Monday(one day) Time: 8am - 5pm Some additional information : 1) National Semiconductor is hosting the meeting again this year. Since Lunch/Refreshments will be provided, pls RSVP to me directly if you are planning to attend. We need to get headcounts. 2) The Agenda is almost ready. We also have time slots available if you are thinking of sharing your experience related to IBIS. You may send me the 'Title' of your presentation and time requested ASAP !! Agenda will be published first week of Jan'98. 3) DesignCon98 20% Discount: ---------------------------- DesignCon98 January 26-29, 1998 Santa Clara Convention Center, Santa Clara, CA On Tuesday, January 27, DesignCon98 will feature several papers and demonstrations on IBIS modeling. The scheduled papers are: "Making Behavioral Models from Physical Measurements" by Jon Powell and Chuck Berman, "Constructing Accurate Behavioral Models for I/O Buffers" by Greg Edlund and Bob Haller, and "Signal Integrity Models and the Real World" by Patrick Riffault. Following the papers will be a panel discussion on the subject, "How Good are the Available IBIS Models?", chaired by Jim Lippman, EDA editor for EDN magazine. This should be a stimulating discussion, with panel participants representing IBIS model users, third-party model vendors, semiconductor houses, and EDA houses. Following the panel will be a complimentary reception, as well as access to the demonstrations and exhibits. 20% REGISTRATION DISCOUNT TO IBIS COMMITTEE MEMBERS! ALL employees from any Company that is a IBIS committee member will be eligible for this discount. The IBIS roster lists the member companies with a "*" next to the company name. Register for DesignCon98 today via the DesignCon98 web site (www.designcon.com), e-mail designcon@iec.org or contact the DesignCon98 Customer Support department at 888.486.8736. Remember to identify yourself as a IBIS committee member to receive your registration discount. For Web registration, mention under "Comments" if you are a member of IBIS committee. Also, visit the DesignCon98 web site (www.designcon.com) to receive up-to-the-minute information. For any questions, feel free to contact me. Regards, Syed. Vice-Chair ANSI/EIA-656 National Semiconductor Corp. (408)721-4874 From owner-ibis Fri Dec 19 13:20:31 1997 Received: from kaw.com ([206.155.177.89]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id NAA08758 for ; Fri, 19 Dec 1997 13:20:29 -0800 (PST) Received: by kaw.com; id AA12233; Fri, 19 Dec 97 16:20:35 EST Received: from omni.kaw.com(192.168.200.83) by explorer via smap (V3.1) id xma012231; Fri, 19 Dec 97 16:20:28 -0500 Received: from blazer.kaw.com (blazer [192.168.200.90]) by kaw.com (8.7.5/8.7.3) with SMTP id QAA07149 for ; Fri, 19 Dec 1997 16:17:29 -0500 (EST) Received: by blazer.kaw.com (SMI-8.6/SMI-SVR4) id QAA00398; Fri, 19 Sep 1997 16:17:05 -0400 Date: Fri, 19 Sep 1997 16:17:05 -0400 From: dan@kaw.com (Dan Aleksandrowicz) Message-Id: <199709192017.QAA00398@blazer.kaw.com> To: ibis@vhdl.org Subject: unsubscribe X-Sun-Charset: US-ASCII unsubscribe From owner-ibis Tue Dec 23 09:57:13 1997 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA10715 for ; Tue, 23 Dec 1997 09:57:12 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id MAA06777 for ; Tue, 23 Dec 1997 12:51:15 -0500 (EST) Received: from mailhost.fremont.viewlogic.com (mhf.fremont.viewlogic.com [139.181.214.211]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA09882 for ; Tue, 23 Dec 1997 12:54:28 -0500 (EST) Received: from pc-jdowney (pc-jdowney.wcdf.viewlogic.com [192.5.151.161]) by mailhost.fremont.viewlogic.com (8.8.6/8.8.7) with SMTP id JAA27349 for ; Tue, 23 Dec 1997 09:50:37 -0800 (PST) Message-Id: <3.0.32.19971223095232.00dd6848@loki.wcdf.viewlogic.com> X-Sender: jhd@loki.wcdf.viewlogic.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Dec 1997 09:52:33 +0000 To: ibis@vhdl.org From: John Downey Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" unsubscribe From owner-ibis Tue Dec 23 23:32:54 1997 Received: from tulip.com (nlheigw01.tulipcomputers.com [194.178.222.10]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id XAA24498 for ; Tue, 23 Dec 1997 23:32:53 -0800 (PST) Received: by tulip.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 41256577.00286EC3 ; Wed, 24 Dec 1997 08:21:37 +0100 X-Lotus-FromDomain: TULIPTCI@TULIP@TULIPNET@TULIPINET From: "Alex Hilbers" To: ibis@vhdl.org Message-ID: <41256577.002A45D0.00@tulip.com> Date: Wed, 24 Dec 1997 08:43:33 +0100 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Happy new year to all! From owner-ibis Thu Dec 25 15:54:27 1997 Received: from ami4000.hei.co.kr ([202.30.128.30]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id PAA05312 for ; Thu, 25 Dec 1997 15:54:24 -0800 (PST) Received: from bc15136.hei.co.kr ([166.125.25.219]) by ami4000.hei.co.kr (8.6.12h2/8.6.9) with ESMTP id IAA14734 for ; Fri, 26 Dec 1997 08:50:54 +0900 Message-ID: <005601bd1190$190717e0$db197da6@bc15136.hei.co.kr> From: "=?euc-kr?B?sejAz7z2?=" To: Subject: Please don't send me a mail Date: Fri, 26 Dec 1997 08:51:53 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01BD11DB.838FEEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0053_01BD11DB.838FEEC0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 WW91ciBpbmZvcm1hdGlvbiB3YXMgdmVyeSBoZWxwZnVsIGJ1dCBJIGRvbid0IG5lZWQgeW91ciBp bmZvcm1hdGlvbiBhbnkgbW9yZSANCmJlY2F1c2UgSSBoYXZlIHRvIHdvcmsgbm90IHJlbGF0ZWQg SUJJUy4gc28gSSB3b3VsZCByYXRoZXIgbm90IHJlY2VpdmUgeW91ciBtYWlsLg0K ------=_NextPart_000_0053_01BD11DB.838FEEC0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjIxMDYuMTEiJyBuYW1lPUdFTkVSQVRPUj4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZm Zj4NCjxESVY+PEZPTlQgc2l6ZT0yPllvdXIgaW5mb3JtYXRpb24gd2FzIHZlcnkgaGVscGZ1bCBi dXQgSSBkb24ndCBuZWVkIHlvdXIgDQppbmZvcm1hdGlvbiBhbnkgbW9yZSA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5iZWNhdXNlIEkgaGF2ZSB0byB3b3JrIG5vdCByZWxhdGVkIElC SVMuIHNvIEkgd291bGQgcmF0aGVyIG5vdCANCnJlY2VpdmUgeW91ciBtYWlsLjwvRk9OVD48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0053_01BD11DB.838FEEC0--