From owner-ibis Thu Jun 1 09:11:48 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA11225; Thu, 1 Jun 2000 09:11:47 -0700 (PDT) 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 MAA12521; Thu, 1 Jun 2000 12:09:18 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA12195; Thu, 1 Jun 2000 12:09:16 -0400 (EDT) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id JAA25642; Thu, 1 Jun 2000 09:09:04 -0700 (PDT) Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4) id JAA15989; Thu, 1 Jun 2000 09:09:04 -0700 Date: Thu, 1 Jun 2000 09:09:04 -0700 From: guy@camarillo.viewlogic.com (Guy de Burgh) Message-Id: <200006011609.JAA15989@f22.viewlogic.com> To: ibis-users@eda.org, ibis@eda.org Subject: IBIS Summit Meeting Agenda (June 8, 2000) ________________________________________________________________________ To All: Below is the planned agenda for the IBIS Summit Meeting to be held on Thursday June 8, 2000 during the Design Automation Conference in Los Angeles, California. The meeting consists of presentations and discussions. The meeting is free to people interested in IBIS modeling, digital circuit design and related EDA tool development. Refreshments and lunch are included. If you plan to attend, please contact Bob Ross or Guy de Burgh at the addresses below (if you haven't already done so): Bob Ross Mentor Graphics Chair, EIA IBIS Open Forum bob_ross@mentor.com Guy de Burgh Innoveda Secretary, EIA IBIS Open Forum gdeburgh@innoveda.com ________________________________________________________________________ AGENDA, IBIS SUMMIT MEETING June 8, 2000 Manhattan Room Hyatt Regency Hotel Los Angeles, California 8:30 AM REFRESHMENTS AND SIGN-IN 9:00 AM INTRODUCTIONS 9:10 AM IBIS REPORT Bob Ross, Mentor Graphics 9:30 AM INTRODUCTION TO EQUATION BASED ANALOG MODELING IN STANDARD HDL LANGUAGES (VHDL_AMS AND VERILOG) Kenneth Bakalar, Mentor Graphics 10:00 AM ELECTION OF OFFICERS AND OTHER BUSINESS 10:30 AM BREAK 10:45 AM CONNECTOR MODEL SPECIFICATION & DISCUSSION Kellee Crisafulli, HyperLynx 12:00 PM LUNCH (Provided to Attendees) 1:00 PM IBIS FUTURE DIRECTIONS UPDATE Stephen Peters, Intel 1:30 PM OVERVIEW OF XML Mike LaBonte, Cadence Design 2:00 PM MACRO LANGUAGE Al Davis, HyperLynx 2:30 PM BREAK 2:45 PM OPEN DISCUSSION AND AD HOC PRESENTATIONS - Version 4.0 Issues - IBIS Futures Issues - Next Meetings - Etc. 5:00 PM MEETING ENDS ________________________________________________________________________ From owner-ibis Thu Jun 1 15:41:17 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA12624 for ; Thu, 1 Jun 2000 15:41:16 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA08674; Thu, 1 Jun 2000 15:38:43 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA00930; Thu, 1 Jun 2000 15:38:42 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3936E5F2.DFAE2CFB@mentor.com> Date: Thu, 01 Jun 2000 15:38:42 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Uploaded interim IBIS Connector Spec. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: For those attending the IBIS Summit Meeting, a a new Connector Specification document has been uploaded at: http://www.eda.org/pub/ibis/connector/ as IbisConnectorSpecV0943.doc This is only an interim document used by the Working Group. A revised version is planned soon within the Working Group with some technical changes. Bob Ross Mentor Graphics From owner-ibis Fri Jun 2 07:07:53 2000 Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA16381 for ; Fri, 2 Jun 2000 07:07:52 -0700 (PDT) From: jaydiep@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA20692 for ; Fri, 2 Jun 2000 09:56:20 -0500 Received: from d54mta06.raleigh.ibm.com (d54mta06.raleigh.ibm.com [9.67.228.38]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA38458 for ; Fri, 2 Jun 2000 10:05:53 -0400 Received: by d54mta06.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F2.004D6F3D ; Fri, 2 Jun 2000 10:05:47 -0400 X-Lotus-FromDomain: IBMUS To: ibis@eda.org Message-ID: <852568F2.004D6E6D.00@d54mta06.raleigh.ibm.com> Date: Fri, 2 Jun 2000 09:38:30 -0400 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe Jay Diepenbrock Email: jaydiep@us.ibm.com From owner-ibis Fri Jun 2 07:25:43 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA16458 for ; Fri, 2 Jun 2000 07:25:42 -0700 (PDT) Received: from cowboy.Cadence.COM (cowboy.Cadence.COM [158.140.143.52]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id HAA25806 for ; Fri, 2 Jun 2000 07:23:44 -0700 (PDT) Received: from pc-kiritm1 (d158140152130 [158.140.152.130]) by cowboy.Cadence.COM (8.8.8/8.8.5) with SMTP id JAA23847 for ; Fri, 2 Jun 2000 09:22:49 -0500 (CDT) Message-Id: <3.0.5.32.20000602092410.00e0da40@cowboy.cadence.com> X-Sender: kiritm@cowboy.cadence.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 02 Jun 2000 09:24:10 -0500 To: ibis@eda.org From: Kirit Mehta Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Received: By mailgate.Cadence.COM as HAA25806 at Fri Jun 2 07:23:44 2000 wwwww g( o 0 )g ---o00--(_)--00o--------------------------------- ___ ___________ Kirit Mehta | - | Lead Support AE | C a d e n c e | Cadence Design Systems, Inc. |_______________| Customer Support Hotline:877-237-4911 .ooo0 0ooo. fax: (512) 349-7619 ( ) ( ) email: kiritm@cadence.com -----\ (---) /------------------------------------------ \_) (_/ From owner-ibis Tue Jun 6 14:57:44 2000 Received: from bm0-0.e-dialog.com (root@bm0-0.e-dialog.com [64.28.75.167]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA04407 for ; Tue, 6 Jun 2000 14:57:43 -0700 (PDT) Received: from e-dialog.com (mf0-s0.e-dialog.com [10.200.3.110]) by bm0-0.e-dialog.com (8.9.3/8.8.7) with SMTP id RAA02392 for ibis@vhdl.org; Tue, 6 Jun 2000 17:55:43 -0400 Date: Tue, 6 Jun 2000 17:55:43 -0400 Message-Id: <200006062155.RAA02392@bm0-0.e-dialog.com> Content-Type: multipart/alternative; boundary="-_-_-_-_-_1234567890" Content-Transfer-Encoding: binary Mime-Version: 1.0 From: "TestMart" To: ibis@vhdl.org Subject: Win an Atomic Clock X-Mailer: EDMAIL 5.02.00 X-Types: 010 This is a multi-part message in MIME format... ---_-_-_-_-_1234567890 Content-Type: text/plain Content-Disposition: inline WIN AN ATOMIC CLOCK! TestMart at http://www.testmart.com/index.cfm?33 is a Web-based marketplace devoted to the test and measurement industry. Register at http://www.testmart.com/index.cfm?33 to be eligible to win an Atomic Clock. SITE FEATURES: * Detailed specifications on 14,000 products in over 120 categories * Unbiased product data for hundreds of manufacturers on one site * Powerful search and compare capabilities * Secure online commerce: buy, sell, lease or rent new, pre-owned and refurbished equipment * News and analysis of trends in the T&M industry TestMart is free. Visit and gain access to product specs, reference directories, equipment prices, and secure online commerce. Buy, sell, lease or rent new, pre-owned and refurbished test and measurement equipment. Phone: (888) 665-2765 e-mail: info@TestMart.com ____________________________________________________ For the first time ever DESIGN, MFG, AND RESEARCH ENGINEERS & SCIENTISTS will be able to share important product and service information available over the internet. To remove your name from the list, reply to this email with REMOVE in the subject fie [[6949]] ---_-_-_-_-_1234567890-- From owner-ibis Tue Jun 13 10:37:44 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA15494 for ; Tue, 13 Jun 2000 10:37:43 -0700 (PDT) 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 NAA06164 for ; Tue, 13 Jun 2000 13:35:05 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id NAA15082 for ; Tue, 13 Jun 2000 13:35:04 -0400 (EDT) Received: from pcchrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id KAA02410 for ; Tue, 13 Jun 2000 10:35:01 -0700 (PDT) From: "Chris Rokusek" To: "IBIS Mailing list" Subject: Connector spec swathing Date: Tue, 13 Jun 2000 10:39:29 -0700 Message-ID: <001601bfd55e$53d39300$aac2b58b@camarillo.viewlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <391719DF.5BF5633E@vlsi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Kellee & IBIS connector committee, The DAC IBIS meeting was one of the best I've attended...well done! I would like to request that the description of the "swath" matrix also describe how to properly construct a fully-coupled matrix from the swath matrix since there appears to be more than one "right" way to do it. It would also be nice if the parser itself could perform this algorithm so that a simulator may (if it so desires) just query the full matrix regardless of how it was specified (swath, full, sparse, ...). Best Regards, Chris Rokusek Innoveda From owner-ibis Tue Jun 13 13:31:39 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA16236 for ; Tue, 13 Jun 2000 13:31:38 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA04807; Tue, 13 Jun 2000 13:29:04 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA26585; Tue, 13 Jun 2000 13:29:03 -0700 (PDT) Message-ID: <3946998C.FC6DDC3B@mentor.com> Date: Tue, 13 Jun 2000 13:29:00 -0700 From: chris Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Rokusek CC: IBIS Mailing list Subject: Re: Connector spec swathing References: <001601bfd55e$53d39300$aac2b58b@camarillo.viewlogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Chris is absolutely correct. We need an unamiguous method of building an arbitrary submatrix from the connector swath. At ICX we wrote a program that translates SPICE connector models into full matrix models which our tool can use. This is a difficult process and needs significant input from the user. There are many cases with ambiguities, sometimes without even one clearly right answer let alone the case where there might be more than one right answer. The problem is best illustrated by considering what the SI tool must accoomplish. Given a particular situation to simulate (which may include coupling to other nets) certain pins on each component must be included in the simulation. If any two (or more) of these pins are situated such that using the swath for both of them results in an overlapping set of pins (but not coincident) then what is the coupling matrix that should be used? Chris Reid Chris Rokusek wrote: > > Kellee & IBIS connector committee, > > The DAC IBIS meeting was one of the best I've attended...well done! > > I would like to request that the description of the "swath" matrix also > describe how to properly construct a fully-coupled matrix from the swath > matrix since there appears to be more than one "right" way to do it. > > It would also be nice if the parser itself could perform this algorithm so > that a simulator may (if it so desires) just query the full matrix > regardless of how it was specified (swath, full, sparse, ...). > > Best Regards, > > Chris Rokusek > Innoveda From owner-ibis Tue Jun 13 14:07:38 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA16427 for ; Tue, 13 Jun 2000 14:07:37 -0700 (PDT) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id OAA11402; Tue, 13 Jun 2000 14:04:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20000613135351.00e77bf0@pop.nwlink.com> Received: from KELLEE98 by ip210.c246.blk1.bel.nwlink.com via smtpd (for mail.nwlink.com [209.20.130.40]) with SMTP; 13 Jun 2000 21:04:06 UT X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 14:03:52 -0700 To: chris , Chris Rokusek From: Kellee Crisafulli Subject: Re: Connector spec swathing Cc: IBIS Mailing list In-Reply-To: <3946998C.FC6DDC3B@mentor.com> References: <001601bfd55e$53d39300$aac2b58b@camarillo.viewlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id OAA16428 Hi Chris, Chris, I do like Chris Rokusek's idea of having the parser create a full matrix. This is not part of the specification but rather would be part of the parser's specification. It would also create at least one unambiguous representation of the matrix. I do not agree that the method should be unambiguous however. I do agree that the data must be unambiguous which I belive it will be when we are finished. Mostly likely this is really your concern. The swath method is an approximate method. All the connector companies I know of already uses this method with the existing SPICE models; they just require a manual operation by the user. The IBIS swath method refines this more and allows it to be automated for the first time. There are many methods possible some that interpolate, some that compress, some that decompress, and some that constrain to only the swath. These all depend on the end goal and need for a given situation. So forcing a particular type of conversation may lock out some uses of the model. best wishes Kellee At 01:29 PM 6/13/00 -0700, chris wrote: >Hello, > >Chris is absolutely correct. We need an unamiguous method of >building an arbitrary submatrix from the connector swath. At >ICX we wrote a program that translates SPICE connector models >into full matrix models which our tool can use. This is a >difficult process and needs significant input from the user. >There are many cases with ambiguities, sometimes without even >one clearly right answer let alone the case where there might >be more than one right answer. > >The problem is best illustrated by considering what the SI >tool must accoomplish. Given a particular situation to simulate >(which may include coupling to other nets) certain pins on each >component must be included in the simulation. If any two (or >more) of these pins are situated such that using the swath for >both of them results in an overlapping set of pins (but not >coincident) then what is the coupling matrix that should be used? > >Chris Reid > > >Chris Rokusek wrote: > > > > Kellee & IBIS connector committee, > > > > The DAC IBIS meeting was one of the best I've attended...well done! > > > > I would like to request that the description of the "swath" matrix also > > describe how to properly construct a fully-coupled matrix from the swath > > matrix since there appears to be more than one "right" way to do it. > > > > It would also be nice if the parser itself could perform this algorithm so > > that a simulator may (if it so desires) just query the full matrix > > regardless of how it was specified (swath, full, sparse, ...). > > > > Best Regards, > > > > Chris Rokusek > > Innoveda --------------------------------------------------------- Have a great day.... Kellee Crisafulli HyperLynx, a division of Pads Software Inc. SI,EMC,X-talk and IBIS tools E-mail: web:   --------------------------------------------------------- From owner-ibis Tue Jun 13 14:44:55 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA16519 for ; Tue, 13 Jun 2000 14:44:53 -0700 (PDT) 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 RAA11587 for ; Tue, 13 Jun 2000 17:42:18 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id RAA25426 for ; Tue, 13 Jun 2000 17:42:16 -0400 (EDT) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id OAA04906 for ; Tue, 13 Jun 2000 14:42:12 -0700 (PDT) Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4) id OAA19767; Tue, 13 Jun 2000 14:42:13 -0700 Date: Tue, 13 Jun 2000 14:42:13 -0700 From: guy@camarillo.viewlogic.com (Guy de Burgh) Message-Id: <200006132142.OAA19767@f22.viewlogic.com> To: ibis@eda.org Subject: EIA IBIS Summit Meeting minutes Date: 6/13/00 SUBJECT: 6/8/00 EIA IBIS Summit Meeting VOTING MEMBERS AND 2000 PARTICIPANTS LIST: 3Com Roy Leventhal Agilent (EEsof, etc.) Mark Chang Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri* Avanti Nikolai Bannov Cadence Design Mike LaBonte*, Todd Westerhoff, Ian Dodd*, Donald Telian, Patrick Dos Santos Cisco Systems Syed Huq*, Irfan Elahi, John Fisher Compaq [Bob Haller], Peter LaFlamme, Ron Bellomio, Shafier Rahman, Doug Burns Cypress (Rajesh Manapat) EMC Corporation (Fabrizio Zanella), Fairchild Semiconductor Craig Klem HyperLynx (& Pads Software) Matthew Flora*, Kellee Crisafulli*, Gene Garat, John Angulo*, Al Davis*, Lynne Green IBM Michael Cohen*, Greg Edlund, Jerry Hayes* Innoveda (Viewlogic Systems) Chris Rokusek*, Guy de Burgh*, Jun Tian, Cary Mandel, Brad Griffin, (Jon Powell) Intel Corporation Stephen Peters*, Arpad Muranyi*, Will Hobbs, Richard Mellitz, Charles Phares*, Meir Nakar*, Sigeti Gabi* LSI Logic (Larry Barnes) Mentor Graphics (& Veribest) Bob Ross*, Tom Dagostino*, Malcolm Ash, Kim Owen, Jean Oudinot, Sherif Hammad*, Hazam Hegazy, Weston Beal*, Ken Bakalar* Mitsubishi Shahab Ahmed, Carleen Murphy* Molex Incorporated Gus Panella Motorola Ron Werner National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre, Tony Sinker Nortel Networks Steve Coe, Calvin Trowell, Hassan Ali Philips Semiconductor D.C. Sessions, Todd Andersen* (& VLSI Technology) Quantic EMC (Mike Ventham) Siemens AG Bernhard Unger, Gerald Bannert SiQual Scott McMorrow, Wis Macomson Texas Instruments Stephen Nolan, Ramzi Ammar, Mac McCaughey, Thomas Fisher*, Jean-Claude Perrin, Jean-Yves Oberle Time Domain Analysis Systems Dima Smolyansky, Steven Corey Tyco Electronics (AMP) (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) Werner Rissiek, John Berrie* OTHER PARTICIPANTS IN 2000: Actel Corp. Silvia Montoya Advansis Mikio Kiyono Aerospatiale Matra CCR Lionel Dreux, Julien Boullie Alcatel (Lannion, Bell) Daniel Peron, Steven Criel Brocade Communications Robert Badal ECI Telecom Daniel Adar* EIA Cecilia Fleming* Fraunhofer Institute Michael Kurten Jet Propulsion Lab John Treichlew Hewlett Packard Paul Gregory Rockwell Collins Ron Hau Signals & Systems Engineering Tom Hawkins ST Micorelectronics Fabrice Boissiere, Pierre Saintot Sun Microsystems Victor Chang* Thomson-CSF Savenrio Lerose, Pascal Vaslin, Thierry Zak, Sylvie Lasserre Transfer Hans Klos, Wilco Hamhuis Xilinx, Inc. Susan Wu Independent, Consultant Hideki Fukuda* 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 June 30, 2000 (916) 356-9200 6-234927 9698213 July 21, 2000 (916) 356-9200 6-234828 2232822 August 11, 2000 (916) 356-9200 6-234930 7474775 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 The IBIS Summit Meeting was held in Los Angeles, California the day after the trade show portion of the Design Automation Conference (DATE 2000) at the Hyatt Regency Hotel. The EIA IBIS Open Forum sponsored the meeting, lunch, and refreshments through membership funding. About 31 people representing 17 organizations participated. Bob Ross welcomed the participants. Everyone introduced him/herself. Semiconductor vendors, EDA vendors and users of EDA tools and IBIS models were represented. (Also, thanks to Cecilia Fleming and Guy de Burgh for handling the administrative and registration details.) All of the presentations and meeting documentation will be uploaded at http://www.eda.org/pub/ibis/summits/jun00/ The notes below give only some of the content and discussion. IBIS REPORT Bob Ross, Mentor Graphics Bob Ross introduced the general topics of the meeting. They consisted of Business and election of officers Connector specification discussion Future activities and ideas Other discussions Bob then gave a general status report. The EIA IBIS Open Forum continues to be active since 1993. It has 31 official members and about 350 to 400 people on the e-mail reflectors. The accomplishments for the previous year include releasing ANSI/EIA-656-A (IBIS Version 3.2), the ibischk3 parser. Also, the Accuracy Handbook was uploaded and the Connector Specification was released to the IBIS Open Forum for further work. These projects were initiated by the IBIS Users Group. The current IBIS projects include working on the Connector Specification, producing an IBIS Version 4.0 upgrade, and also working on a future version of IBIS. In addition the Open Forum monitors and works with other committees regarding IMIC, EMI, and JEDEC activities. Bob briefly summaries some of the future work. Bob then discussed the impact of IBIS. About 35 semiconductor vendors supply IBIS models from company Web links, and others directly through sales channels for an estimated 2,000 IBIS models. About 10-12 commercial IBIS vendors exist, amounting to over 11,000 IBIS models. Users also produce IBIS models and internal IBIS specifications and guidelines. Approximately 10 EDA vendors (behavioral and Spice) read IBIS models. Free and commercial IBIS tools are available. IBIS IBIS is frequently referenced in publications. Bob concluded that IBIS is well established. VHDL-AMS AND VERILOG-AMS, A DUAL TUTORIAL Ken Bakalar, Mentor Graphics Ken Bakalar, an active member of the VHDL-AMS and pending Verilog-AMS standardization activities, presented a general overview based on a full tutorial that normally would take longer to deliver. The full tutorial will be uploaded and covers much more detail than can be presented here. Ken defined a "Digital Simulator", "Analog Simulator", and a "Mixed-Signal Simulator" (AMS) and its partitioning into analog and digital elements and the synchronization between simulators. Ken gave a time-line and genealogy of the AMS activities. Both V*-AMS languages have these features (described in detail in the presentation): Extended structural semantics Mixed-signal simulation Continuous modeling extensions Frequency domain support Simulation control VHDL-AMS has these extras: Handling of initial conditions and discontinuities Mixed-signal initialization well defined Sequential or equation-based notation Sound mathematical foundations based on differential algebraic equation theory Formal definition Verilog-AMS has these extras: Automatic converter insertion at discrete/continuous boundaries Automatic resolution of signal flow/conservative connections Many built-in special case mechanisms Equation formulation uses controlled source notation Verilog VPI extension included Informal definition - users's manual Ken presented a diode sample in each language. (People raised some questions on details, and there are some editorial errors in the examples.) The uploaded presentations describe more structural details of both VHDL-AMS and Verilog-AMS. Ken closed with two examples, one describing piecewise defined behavior and the other describing sample and hold. Several questions and discussions occurred during the presentation. One dealt with whether there existed a Spice to HDL and HDL to Spice path. (This was not clarified.) Ken responded to Arpad Muranyi that table based data could be handled. Ken responded to Chris Rokusek that partitioning of matrices for optimization could be done for ground plane analysis. Ian Dodd commented on possible convergence problems and that the initial value problem was not solved. Ken stated that there is no visibility of the time step, and this is good. Ken differentiated VHDL-AMS as concurrent (order does not matter) versus Verilog-AMS as sequential. MISCELLANEOUS BUSINESS Bob Ross reported that the official ANSI/EIA-656-A in Acrobat format for IBIS Version 3.2 can be found at: http://www.eia.org/eng/standards/default.htm Bob reported on several recent articles that reference IBIS models. "Ensuring Signal Integrity" by Jon Powell has an IBIS sidebar and appears in the June 2000 issue of Printed Circuit Design, pp. 12 -16 & 24. Also, "Signal Integrity Tips Ensure FPGA Designers Meet Critical Market Windows" by Lynne Green and Rick Ballantyne in the May 29, 2000 issue of Electronic Design, pp. 97-100 mention IBIS. A link to the article is: http://www.elecdesign.com/magazine/2000/may2900/desapps/1DESAPP1.shtml Bob reported that STMicroelectronics has Flash Memory IBIS Models at: http://www.eu.st.com/stonline/products/support/memory/flash/ibis.htm Stephen Peters raised the issue of SPAM mail on the IBIS reflectors. This was discussed briefly. The way to deal with it would be with a majordomo based list which allows only list members to send e-mail on the reflectors. The following officers received thank you recognition plaques presented by Bob Ross and Stephen Peters for their service and contributions during the 1999 - 2000 year: Chair, Bob Ross, Mentor Graphics Vice Chair, Stephen Peters, Intel Secretary, Guy de Burgh, Innoveda Postmaster, Matthew Flora, HyperLynx Web Master, Syed Huq, Cisco Systems Librarian, Jon Powell, Innoveda ELECTION OF IBIS OFFICERS FOR 2000 - 2001 Bob Ross then conducted an election for the 2000 - 2001 EIA IBIS Open Forum Officers, one position at a time, starting with Chair. Nominations for the various positions had been previously announced at the May 26, 2000 IBIS meeting, and Bob called for any additional nominations. For the uncontested positions, the vote was conducted by a show of hands. For the contested positions, the candidates gave brief statements. A roll call vote based on one vote per EIA IBIS Open Forum member company was conducted. During the election Stephen Peters withdrew for the Chair. position because of work commitments and an upcoming sabbatical. Michael Cohen was nominated from the floor for Vice Chair. The vote for Vice Chair. was Stephen 6, Mike 5, and 1 abstention. The Librarian position election was held between previously nominated candidates, Jon Powell and Mike LaBonte. The vote for Librarian was Mike 8, Jon 3, and 1 abstention. The following people have been nominated as officers for 2000 - 2001 Chair: Bob Ross, Mentor Graphics Vice Chair: Stephen Peters, Intel Secretary: Guy de Burgh, Innoveda Postmaster: John Angulo, HyperLynx Webmaster: Syed Huq, Cisco Systems Librarian: Mike LaBonte, Cadence IBIS CONNECTOR SPECIFICATION Kellee Crisafulli, HyperLynx Kellee gave reported on the Connector Specification progress. The goal is still to complete the Specification this year after incorporate the changes requested at the January 31, 2000 IBIS Summit Meeting and also after improving some syntax descriptions and explanations. The document will be issued in Word, Adobe and text formats. A Working Group has been meeting regularly, the last meeting on June 6, 2000. Kellee discussed ambiguous syntax changes. Both Lumped and Distributed formats are now supported, similar to the Electrical Board Description. However, this is being accomplished differently using a new [Derivation Method] keyword to indicate a Lumped or Distributed for the matrix section. Also, a multiplier Mult = xxx (versus Len = xxx) to provides scaling of both the discrete or distributed sections. There was some discussion regarding whether explicit units are needed and should be optionally added. The Swath matrix usage has been further clarified. Now the term "edge only" is used to designate edge rows or columns that are to be used only at the edges, and to be terminated by a given impedance when the Swath is positioned for an internal group of pins. This was discussed and illustrated. One problem was raised. A smaller x-y swath can be positioned within a larger X-Y grid such that only the top edge are aligned. It is ambiguous whether the left and right pins of the top edge swath should be treated as edge only pins. (Kellee thought that it should, but needs to clarify this.) Kellee listed other details. The file line lengths were set to a consistent 120 characters and a line continuation character is allowed for model sections and stubs. Kellee presented some examples showing the revised syntax. Kellee summarized the short term goals as Finalize the changes Vote on Verson 1.0 of .icm Ask for funds for parser development Update the examples Confirm the accuracy by comparing to real connector data, Spice data and IBIS Package model data. Future goals for Version 2.x are Add lossy modeling Add other topology support such as cross-over pins. IBIS FUTURES - AN UPDATE Stephen Peters, Intel Corp. After lunch, Stephen Peters introduce the IBIS Future discussion topic. The previous tutorial on VHDL-AMS and Verilog-AMS fell under this general topic. Stephen reported that the first meeting was a face-to-face meeting held in March 2000. The goal was to provide a path to a 'next generation' I/O buffer description language. So far the progress has been slow. Mike LaBonte will conducting Working Group teleconference meetings while Stephen is on a sabbatical. Stephen stated the general requirements: Keep the good stuff of IBIS Standardized description Protect intellectual property Document signal integrity parameters Continue support of board level (behavioral) simulators Expand the format and structure to fix problem areas Expandability and flexibility (versus fixed keywords) Enable accurate modeling of simultaneous switching outputs, power delivery, and package effects Support behavioral receivers Enable equation descriptions (including S-parameters) Stephen presented the Issues and Considerations: Nodal descriptions are a necessity Die interconnect (pad and pin) descriptions Power delivery and pin to pin coupling Connections for black boxes Macro language for creating new model prototypes Flexible and extendible and allows existing IBIS model to be reused Enables a wide variety of descriptions Public Key encryption a necessity?? Tool vendor specific encryption or Public/private key administered by the IBIS Committee Use XHML Syntax? In the discussion segments, people indicated that S-parameters could be regarded as a possible subset of the general notion of equation based descriptions. Some comments were made regarding the reliability of encrypted models. The encryption issue will be treated independently from the IBIS Futures Working Group discussions. People cited the advantages of building upon existing standards and formats versus inventing a new format and also on prototyping the future work. OVERVIEW OF XML Mike LaBonte, Cadence Design Systems Mike LaBonte gave an overview tutorial of XML. He gave these definitions: Meta-language: SGML Standard Generalized Markup Language XML eXtensible Markup Language (subset of SGML) Language: HTML Hypertext Markup Language VML Vector Markup Language Mike then illustrated XML and XML editing tools. The key points of XML are: XML is a simple meta language - a basis for creating languages Unrecognized elements are easily ignored, since opening tags are always balanced by a closing tag Tools for working with XML are common Part of XML is the Document Type Definition (DTD). Its key points are: Hand out a DTD as your file format specification XML tools will automatically validate XML content against DTD DTD reference can be a URL to the "master" DTD Mike discussed and illustrated an eXtensible Style Language (XSL). Its key points are: XML data can be converted to HTML, or any other format XSL processors are built into browsers Report views can be altered by modifying the XSL file, without changing the tool that produces the data Mike listed some XML projects for EDA: Silicon Integration Initiative (Si2) QuickData - web part searches Pinnacles Component Information Standard (PCIS) Timing Diagram Markup Language (TDML) E-Tools EdaXML - EDIF replacement ChipData iParts Miner - extract part data from PDF, etc. Mike illustrated XML display using Internet Explorer 5 (and planned for Netscape 6), collapsing sections to hide data, and editing with XML Notepad. A number of comments were made during the presentation. An XML version of IBIS would eliminate the need for an IBIS parser to check syntax. Only value checking would be needed. Other tools may work with or export markup language formats. Mike is submitting examples of IBIS Syntax as part of uploaded presentation. A MACRO LANGUAGE FOR IBIS Al Davis, HyperLynx Al Davis had presented some draft documents at the January 31, 2000 IBIS Summit Meeting. The macro language gets around the IBIS fixed syntax problem (and BIRDs) and also is compatible with nodal representation and with the familiar aspects of IBIS. It is backwards compatible with IBIS. The circuit topology can be defined in the language. Al illustrated this with a simple Vsource, Rsource variable voltage and variable resistance driver model. The language includes inheritance, correlation (typ/min/max) and conditionals. It contains some basic Spice elements (R, L, C, V, I, E, G) and some Spice extras. Also some Non-Spice driver, trigger and alarm elements and some programming (assert, define, export, if, inherit, local and select) elements can be added. For receiver modeling, Al added fixed delay (digital or analog), variable delay (digital or analog) and analog behavioral blocks (gain, filter, integrate). Other elements for compatibility with driver schedule and submodels include reshape (digital) and array of components. IMIC style transistors and transmission lines can be considered. Currently, the macro language is 100% with IBIS Version 3.2. More study is needed for receivers. Pad to pin details need to be addressed. So far, one meeting and one teleconference meeting have been held. More meetings are now scheduled. GENERAL DISCUSSION During and after the presentation, a general discussion occurred on all topics. A few comments are captured here. Arpad Muranyi commented that the nodal connectivity and building block approach is natural to the application. Al Davis commented that the macro approach could be an extension to Spice. Fred Balistreri commented that mixed mode simulation was still not a reality because of iteration problems. Someone comment that IMIC could serve as the starting point. It has the Spice like syntax, and IBIS data sheet information could be added. A macro language would serve all vendors. A set of primitives may be implemented differently (or not implemented) by different vendors. Milt Schwartz stressed that application engineers often do the model development. The device design engineers are not involved, and the reference Spice models are usually not available. So model developers should have an easy, familiar, simple language. John Angulo commented that Verilog-AMS and VHDL-AMS were verbose syntaxes. An advantage with moving forward with a macro language approach is that the Spice and IBIS syntaxes are familiar to the model developers. All of the approaches need to be prototyped. Michael Cohen is interested in working with someone (Ken Bakalar) on a VHDL-AMS implementation of IBIS. The XML implementation of IBIS can also be checked. FUTURE MEETINGS Bob Ross closed the discussion by noting that several teleconference meetings have been scheduled. The next teleconference meeting will be held on June 30, 2000 and conducted by Guy de Burgh since both Stephen Peters and Bob will be out. (They still may call in.) The next IBIS Summit Meeting is scheduled on Thursday, September 14, 2000 in Worcester, Massachusetts at the same time as the PCBEAST 2000 conference. Mike LaBonte will host the IBIS futures group teleconference Working Group meeting on Wednesday, June 14, 2000. The Connector Specification Working Group will continue meeting, but the next date has not been scheduled. NEXT MEETING: The next teleconference meeting will be on Friday, June 30, 2000 from 8:00 AM to 10:00 AM. Guy de Burgh will be conducting the meeting. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Mike LaBonte (978) 262-6496, Fax: (978) 446-6798 mikelabonte@cadence.com Senior Technologist, Cadence Design Systems 270 Billerica Road Chelmsford, MA 01824 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 angulo@hyperlynx.com Development Engineer, HyperLynx, Inc. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Jun 13 19:17:20 2000 Received: from itx03.internex.co.kr (itx03.internex.co.kr [203.239.35.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA17439 for ; Tue, 13 Jun 2000 19:17:17 -0700 (PDT) Received: from imsong (imsong.internex.co.kr [203.239.35.36]) by itx03.internex.co.kr (AIX4.2/UCB 8.7/8.7) with SMTP id KAA13322 for ; Wed, 14 Jun 2000 10:59:55 +0900 (KORST) Message-ID: <00fb01bfd5a6$5f01bca0$2423efcb@internex.co.kr> From: "Song In-myung" To: "IBIS Open Forum" Subject: Dimm socket Model.? Date: Wed, 14 Jun 2000 11:15:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: "Song In-myung" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by server.eda.org id TAA17440 Hello everyone. How are you today? I am finding the IBIS model of DIMM Socket. Does anyone have this? or can anyone make me find that? Thank you for your great help. Inmyung ================================================================ Assistance Manager(http://www.internex.co.kr/~imsong) 897-15 Haedong Bidg. Daechidong. Kangnamgu. Seoul. Korea. Internex Ltd.(http://www.internex.co.kr ; http://www.pcbkorea.com) CAD Division TEL : 822-553-2274 FAX : 822-554-8031 From owner-ibis Wed Jun 14 07:40:13 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA19874 for ; Wed, 14 Jun 2000 07:40:12 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id HAA26393 for ; Wed, 14 Jun 2000 07:38:08 -0700 (PDT) Received: from cadence.com (d15814010535 [158.140.105.35]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id KAA03743 for ; Wed, 14 Jun 2000 10:38:08 -0400 (EDT) Message-ID: <394798D0.585F24@cadence.com> Date: Wed, 14 Jun 2000 10:38:08 -0400 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IBIS Mailing list Subject: Re: Connector spec swathing References: <001601bfd55e$53d39300$aac2b58b@camarillo.viewlogic.com> <3946998C.FC6DDC3B@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as HAA26393 at Wed Jun 14 07:38:08 2000 I would like to add an illustration of Chris Reid's point, as I see it. Here is an ASCII picture of a connector. The pins marked as 'X' are those carrying the signals that the simulation product has determined MUST be characterized and simulated. The '0' pins are the other pins of the connector: 0 0 0 0 0 X O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 0 0 0 0 0 0 X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 0 0 0 0 0 Assume that the connector model uses a 3x3 swath with 1 left edge and 1 right edge (5x3 total matrix size). Here is one possible pattern for using the swath, where 'M' represents matrix middle pins, and 'E' represents pins in an edge column, which must be terminated by Cn_Z. The '?' pins are those that could be either an edge or a middle, depending on which nearby swath it is considered to be "in": 0 0 E M M X E 0 0 0 E M M ? ? M M E 0 0 0 0 0 0 E M X M E 0 0 0 E M X ? ? M M E 0 0 0 0 0 E M M M E 0 0 0 E M M ? ? X M E 0 0 0 0 There is no single swath that can contain the 2 pins on the right. But 2 swaths, each centered around one pin, will overlap. Most likely the simulator will have to make some choice that does not fulfill the intent of the model developer. Even the 2 pins on the left have some ambiguity; I chose the pin in the middle row as my center point, but the choice is not always obvious. On the subject of centering a swath around a pin, a swath with an even number of columns has four possible locations, giving four possible simulation results, depending on which is chosen. This is because the swath has no pin at the center, but has 4 pins equally close to the center. Since simulators have to handle a full matrix anyway, I would have to join Chris Rokusek in hoping for a solution that turns a connector model into a full matrix. Mike LaBonte Cadence Chris Reid wrote: > > Hello, > > Chris is absolutely correct. We need an unamiguous method of > building an arbitrary submatrix from the connector swath. At > ICX we wrote a program that translates SPICE connector models > into full matrix models which our tool can use. This is a > difficult process and needs significant input from the user. > There are many cases with ambiguities, sometimes without even > one clearly right answer let alone the case where there might > be more than one right answer. > > The problem is best illustrated by considering what the SI > tool must accoomplish. Given a particular situation to simulate > (which may include coupling to other nets) certain pins on each > component must be included in the simulation. If any two (or > more) of these pins are situated such that using the swath for > both of them results in an overlapping set of pins (but not > coincident) then what is the coupling matrix that should be used? > > Chris Reid > > Chris Rokusek wrote: > > > > Kellee & IBIS connector committee, > > > > The DAC IBIS meeting was one of the best I've attended...well done! > > > > I would like to request that the description of the "swath" matrix also > > describe how to properly construct a fully-coupled matrix from the swath > > matrix since there appears to be more than one "right" way to do it. > > > > It would also be nice if the parser itself could perform this algorithm so > > that a simulator may (if it so desires) just query the full matrix > > regardless of how it was specified (swath, full, sparse, ...). > > > > Best Regards, > > > > Chris Rokusek > > Innoveda From owner-ibis Wed Jun 14 08:41:38 2000 Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA20232 for ; Wed, 14 Jun 2000 08:41:38 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 5717E50803 for ; Wed, 14 Jun 2000 15:39:05 +0000 (GMT) Received: from smtp.molex.com ([150.150.15.100]) by molexinc-cp.molex.com; Wed, 14 Jun 2000 11:38:59 +0000 (EST) Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 00169AE7; Wed, 14 Jun 2000 10:14:34 -0500 Mime-Version: 1.0 Date: Wed, 14 Jun 2000 10:09:11 -0500 Message-ID: <00169AE7.CE21031@molex.com> Subject: Re[2]: Connector spec swathing To: Mike LaBonte , IBIS Mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part An important point in using a "swath". The initial swath matrix MUST be large enough (i.e. represent enough pins) such that the appropriate number of coupling effects can be observed. That being said... the swath was created to make a single large "matrix" out of a smaller "matrix". The goal being to automatically create a banded matrix. The swath really wasn't created to DIRECTLY pick a pin (or multiple random pins) out of a connector for simulations. (Although it might be possible, I just haven;'t thought it through). Would it be easier if the original matrix (assuming it is initially wide enough) is swathed to represent a banded matrix first ? Basically, using the small matrix, incorporating matrix symmetry, and disregarding a given number of coupling effects to create a banded matrix. The then resultant banded matrix would be a part of the simulation deck (not the original small matrix) Am I way out on this one? _gus: 630-527-4617 Also, for what it is worth... for this example, I would suggest that the starting PIN matrix would be at least 3 x 9. ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: Mike LaBonte Date: 6/14/00 10:38 AM I would like to add an illustration of Chris Reid's point, as I see it. Here is an ASCII picture of a connector. The pins marked as 'X' are those carrying the signals that the simulation product has determined MUST be characterized and simulated. The '0' pins are the other pins of the connector: 0 0 0 0 0 X O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 0 0 0 0 0 0 X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 0 0 0 0 0 Assume that the connector model uses a 3x3 swath with 1 left edge and 1 right edge (5x3 total matrix size). Here is one possible pattern for using the swath, where 'M' represents matrix middle pins, and 'E' represents pins in an edge column, which must be terminated by Cn_Z. The '?' pins are those that could be either an edge or a middle, depending on which nearby swath it is considered to be "in": 0 0 E M M X E 0 0 0 E M M ? ? M M E 0 0 0 0 0 0 E M X M E 0 0 0 E M X ? ? M M E 0 0 0 0 0 E M M M E 0 0 0 E M M ? ? X M E 0 0 0 0 There is no single swath that can contain the 2 pins on the right. But 2 swaths, each centered around one pin, will overlap. Most likely the simulator will have to make some choice that does not fulfill the intent of the model developer. Even the 2 pins on the left have some ambiguity; I chose the pin in the middle row as my center point, but the choice is not always obvious. On the subject of centering a swath around a pin, a swath with an even number of columns has four possible locations, giving four possible simulation results, depending on which is chosen. This is because the swath has no pin at the center, but has 4 pins equally close to the center. Since simulators have to handle a full matrix anyway, I would have to join Chris Rokusek in hoping for a solution that turns a connector model into a full matrix. Mike LaBonte Cadence From owner-ibis Wed Jun 14 09:15:59 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA20366 for ; Wed, 14 Jun 2000 09:15:58 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA29762; Wed, 14 Jun 2000 09:13:25 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA03592; Wed, 14 Jun 2000 09:13:23 -0700 (PDT) Message-ID: <3947AF20.40A54D06@mentor.com> Date: Wed, 14 Jun 2000 09:13:20 -0700 From: chris Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: apanella@molex.com CC: Mike LaBonte , IBIS Mailing list Subject: Re: Connector spec swathing References: <00169AE7.CE21031@molex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike, Thanks for your illustration of my point. Clearly we have exactly the same concern. Gus, Yes, including the larger matrix that is supposed to be expandable to a full banded matrix would be useful, but it should also include instructions on just how that smaller matrix is supposed to be used to get the full banded matrix. Thanks, Chris apanella@molex.com wrote: > > An important point in using a "swath". > > The initial swath matrix MUST be large enough (i.e. represent enough pins) such > that the appropriate number of coupling effects can be observed. > > That being said... the swath was created to make a single large "matrix" out of > a smaller "matrix". The goal being to automatically create a banded matrix. > > The swath really wasn't created to DIRECTLY pick a pin (or multiple random pins) > out of a connector for simulations. (Although it might be possible, I just > haven;'t thought it through). > > Would it be easier if the original matrix (assuming it is initially wide enough) > is swathed to represent a banded matrix first ? > > Basically, using the small matrix, incorporating matrix symmetry, and > disregarding a given number of coupling effects to create a banded matrix. > > The then resultant banded matrix would be a part of the simulation deck (not > the original small matrix) > > Am I way out on this one? > > _gus: 630-527-4617 > > Also, for what it is worth... for this example, I would suggest that the > starting PIN matrix would be at least 3 x 9. > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: Mike LaBonte > Date: 6/14/00 10:38 AM > > I would like to add an illustration of Chris Reid's point, as I see it. > Here is an ASCII picture of a connector. The pins marked as 'X' > are those carrying the signals that the simulation product has > determined MUST be characterized and simulated. The '0' pins are > the other pins of the connector: > > 0 0 0 0 0 X O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 X 0 0 0 0 0 0 0 X 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X 0 0 0 0 0 0 > > Assume that the connector model uses a 3x3 swath with 1 left edge > and 1 right edge (5x3 total matrix size). Here is one possible > pattern for using the swath, where 'M' represents matrix middle pins, > and 'E' represents pins in an edge column, which must be terminated > by Cn_Z. The '?' pins are those that could be either an edge or a > middle, depending on which nearby swath it is considered to be "in": > > 0 0 E M M X E 0 0 0 E M M ? ? M M E 0 0 0 0 > 0 0 E M X M E 0 0 0 E M X ? ? M M E 0 0 0 > 0 0 E M M M E 0 0 0 E M M ? ? X M E 0 0 0 0 > > There is no single swath that can contain the 2 pins on the right. > But 2 swaths, each centered around one pin, will overlap. Most likely > the simulator will have to make some choice that does not fulfill the > intent of the model developer. Even the 2 pins on the left have some > ambiguity; I chose the pin in the middle row as my center point, but > the choice is not always obvious. > > On the subject of centering a swath around a pin, a swath with an even > number of columns has four possible locations, giving four possible > simulation results, depending on which is chosen. This is because the > swath has no pin at the center, but has 4 pins equally close to the center. > > Since simulators have to handle a full matrix anyway, I would have to > join Chris Rokusek in hoping for a solution that turns a connector model > into a full matrix. > > Mike LaBonte > Cadence > From owner-ibis Wed Jun 14 09:52:59 2000 Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA20574 for ; Wed, 14 Jun 2000 09:52:58 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 408394FBB9 for ; Wed, 14 Jun 2000 16:50:25 +0000 (GMT) Received: from smtp.molex.com ([150.150.15.100]) by molexinc-cp.molex.com; Wed, 14 Jun 2000 12:50:17 +0000 (EST) Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 0016A0E7; Wed, 14 Jun 2000 11:32:46 -0500 Mime-Version: 1.0 Date: Wed, 14 Jun 2000 11:27:43 -0500 Message-ID: <0016A0E7.CE21031@molex.com> Subject: Re[2]: Connector spec swathing To: chris Cc: Mike LaBonte , IBIS Mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part So then, the recommendation would be to have the IBIS Connector Model Specification _explicitly_ state how each simulator will implement the expansion from the keywords and parameters already given in the specification. If the recommendation is acceptable (it is for me)... Would it be acceptable by the simulator companies? If not.. is there a different option? In the discussion of this topic in the subcommittee, I got the impression that the expansion method of matrices was somewhat seen as a proprietary technology. As such, I wanted to build in enough keywords and usage rules that would allow me to assign values that would _lessen_ the likelihood of incorrect simulator implementation (assuming of course that I correctly defined the model, swath size, and related keywords...) I will take this up at our next IBIS Connector Model subcommittee teleconference. _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: chris Date: 6/14/00 9:13 AM Mike, Thanks for your illustration of my point. Clearly we have exactly the same concern. Gus, Yes, including the larger matrix that is supposed to be expandable to a full banded matrix would be useful, but it should also include instructions on just how that smaller matrix is supposed to be used to get the full banded matrix. Thanks, Chris From owner-ibis Wed Jun 14 10:37:48 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA20757 for ; Wed, 14 Jun 2000 10:37:47 -0700 (PDT) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id KAA29579 for ; Wed, 14 Jun 2000 10:35:44 -0700 (PDT) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 14 Jun 2000 17:35:44 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3) with SMTP id KAA18158 for ; Wed, 14 Jun 2000 10:35:41 -0700 Message-ID: <00bb01bfd627$331c6230$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: "IBIS Mailing list" Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 14 Jun 2000 17:35:44 UT References: <0016A0E7.CE21031@molex.com> Subject: Re: Re[2]: Connector spec swathing Date: Wed, 14 Jun 2000 10:37:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Gus, (IMHO) I think this is another case of the users and the spec writers having different perspectives. The users assume that whomever wrote the spec must have had some idea in mind on how the swath would be converted to a full matrix, otherwise the spec hasn't been well thought out. (Meaning that if the spec writer doesn't know how to do it, what makes them think anyone does?) The users go on to think that as long as the spec writer has this underlying scheme, why not publish the scheme to reduce misunderstandings. The spec writer, on the other hand, is trying not to restrict the implementation to what they had in mind since someone else might have an equally clever, yet completely different way of doing it. This came up before on discussions of some of the BIRDS for specifying changes in delay values based upon slope and over shoot of input voltages. Bob Ross ended up saying that he would probably implement the scheme differently than the spec writer, but would like to know what the spec writer had in mind if for no other reason than to prove that it could be done. Keep up the good work, Matthew Flora ----- Original Message ----- From: To: "chris" Cc: "Mike LaBonte" ; "IBIS Mailing list" Sent: Wednesday, June 14, 2000 9:27 AM Subject: Re[2]: Connector spec swathing > > So then, the recommendation would be to have the IBIS Connector Model > Specification _explicitly_ state how each simulator will implement the expansion > from the keywords and parameters already given in the specification. > > If the recommendation is acceptable (it is for me)... Would it be acceptable by > the simulator companies? If not.. is there a different option? > > In the discussion of this topic in the subcommittee, I got the impression that > the expansion method of matrices was somewhat seen as a proprietary technology. > As such, I wanted to build in enough keywords and usage rules that would allow > me to assign values that would _lessen_ the likelihood of incorrect simulator > implementation (assuming of course that I correctly defined the model, swath > size, and related keywords...) > > I will take this up at our next IBIS Connector Model subcommittee > teleconference. > > _gus: 630-527-4617 From owner-ibis Wed Jun 14 13:14:12 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA21285 for ; Wed, 14 Jun 2000 13:14:11 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA24904; Wed, 14 Jun 2000 13:11:37 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA18464; Wed, 14 Jun 2000 13:11:36 -0700 (PDT) Message-ID: <3947E6F3.CFB4433@mentor.com> Date: Wed, 14 Jun 2000 13:11:31 -0700 From: Christopher Reid Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: apanella@molex.com CC: chris , Mike LaBonte , IBIS Mailing list Subject: Re: Connector spec swathing References: <0016A0E7.CE21031@molex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gus, I don't consider any of this proprietary. I think its more important that its unambiguous so there is confidence that the intention of the connector vendors is followed when using the models. Every simulator should use the same method. Thanks, Chris apanella@molex.com wrote: > > So then, the recommendation would be to have the IBIS Connector Model > Specification _explicitly_ state how each simulator will implement the expansion > from the keywords and parameters already given in the specification. > > If the recommendation is acceptable (it is for me)... Would it be acceptable by > the simulator companies? If not.. is there a different option? > > In the discussion of this topic in the subcommittee, I got the impression that > the expansion method of matrices was somewhat seen as a proprietary technology. > As such, I wanted to build in enough keywords and usage rules that would allow > me to assign values that would _lessen_ the likelihood of incorrect simulator > implementation (assuming of course that I correctly defined the model, swath > size, and related keywords...) > > I will take this up at our next IBIS Connector Model subcommittee > teleconference. > > _gus: 630-527-4617 > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: chris > Date: 6/14/00 9:13 AM > > Mike, > > Thanks for your illustration of my point. Clearly we have > exactly the same concern. > > Gus, > > Yes, including the larger matrix that is supposed to be expandable > to a full banded matrix would be useful, but it should also include > instructions on just how that smaller matrix is supposed to be used > to get the full banded matrix. > > Thanks, > > Chris > From owner-ibis Wed Jun 14 14:00:37 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA21423 for ; Wed, 14 Jun 2000 14:00:36 -0700 (PDT) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id NAA17611; Wed, 14 Jun 2000 13:57:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20000614134830.02e2cee0@pop.nwlink.com> Received: from KELLEE98 by ip210.c246.blk1.bel.nwlink.com via smtpd (for mail.nwlink.com [209.20.130.40]) with SMTP; 14 Jun 2000 20:57:05 UT X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2000 13:53:51 -0700 To: Christopher Reid , apanella@molex.com From: Kellee Crisafulli Subject: Re: Connector spec swathing Cc: chris , Mike LaBonte , IBIS Mailing list In-Reply-To: <3947E6F3.CFB4433@mentor.com> References: <0016A0E7.CE21031@molex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id OAA21424 Hi Chris, I am having great difficultly understanding why all the simulators should be forced to use the same method. This is an approximate approach in the first place. If one simulator wants to use a method that runs 100,000 times faster than another with a 1% accuracy reduction than it should be able to do that. I feel the data must be unambiguous. The method should be open to the simulator experts. I do think it reasonable to provide one example method either as a description or as code implemented in the IBIS parser. Perhaps a full matrix extraction would make the most sense but I can hardly imagine most simulators wanting to simulate a series of 10 matrices each 1000 by 1000 just to get 2 coupled signals simulated. I do not feel all simulators should use the same method. I feel most simulators may even want to use different methods depending on the simulation needs. At 01:11 PM 6/14/00 -0700, Christopher Reid wrote: >Gus, > >I don't consider any of this proprietary. I think its more important >that its unambiguous so there is confidence that the intention of the >connector vendors is followed when using the models. Every simulator >should use the same method. > >Thanks, > >Chris > >apanella@molex.com wrote: > > > > So then, the recommendation would be to have the IBIS Connector Model > > Specification _explicitly_ state how each simulator will implement the > expansion > > from the keywords and parameters already given in the specification. > > > > If the recommendation is acceptable (it is for me)... Would it be > acceptable by > > the simulator companies? If not.. is there a different option? > > > > In the discussion of this topic in the subcommittee, I got the > impression that > > the expansion method of matrices was somewhat seen as a proprietary > technology. > > As such, I wanted to build in enough keywords and usage rules that > would allow > > me to assign values that would _lessen_ the likelihood of incorrect > simulator > > implementation (assuming of course that I correctly defined the model, > swath > > size, and related keywords...) > > > > I will take this up at our next IBIS Connector Model subcommittee > > teleconference. > > > > _gus: 630-527-4617 > > > > ____________________Reply Separator____________________ > > Subject: Re: Connector spec swathing > > Author: chris > > Date: 6/14/00 9:13 AM > > > > Mike, > > > > Thanks for your illustration of my point. Clearly we have > > exactly the same concern. > > > > Gus, > > > > Yes, including the larger matrix that is supposed to be expandable > > to a full banded matrix would be useful, but it should also include > > instructions on just how that smaller matrix is supposed to be used > > to get the full banded matrix. > > > > Thanks, > > > > Chris > > --------------------------------------------------------- Have a great day.... Kellee Crisafulli HyperLynx, a division of Pads Software Inc. SI,EMC,X-talk and IBIS tools E-mail: web:   --------------------------------------------------------- From owner-ibis Wed Jun 14 14:04:18 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA21440 for ; Wed, 14 Jun 2000 14:04:17 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA29870; Wed, 14 Jun 2000 14:01:43 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA27837; Wed, 14 Jun 2000 14:01:41 -0700 (PDT) Message-ID: <3947F2B1.32833A03@mentor.com> Date: Wed, 14 Jun 2000 14:01:37 -0700 From: Christopher Reid Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Kellee Crisafulli CC: Christopher Reid , apanella@molex.com, Mike LaBonte , IBIS Mailing list Subject: Re: Connector spec swathing References: <0016A0E7.CE21031@molex.com> <4.3.2.7.2.20000614134830.02e2cee0@pop.nwlink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kellee, Your point is well taken. For example, the user may be given an option of choosing a time step. For larger time steps different approximations can be made. What I would like to see is an unambiguous definition of what is expected (a prescription of how to use these models.) Each vendor can then explain approximations that may be made that deviate from this expected use in one way or another. Thanks for the input. I'm modifying my position to agree with yours better. Chris Kellee Crisafulli wrote: > > Hi Chris, > > I am having great difficultly understanding why > all the simulators should be forced to use the same method. > > This is an approximate approach in the first place. If one > simulator wants to use a method that runs 100,000 times faster > than another with a 1% accuracy reduction than it should > be able to do that. > > I feel the data must be unambiguous. The method should be > open to the simulator experts. I do think it reasonable to > provide one example method either as a description or as > code implemented in the IBIS parser. Perhaps a full matrix > extraction would make the most sense but I can hardly imagine > most simulators wanting to simulate a series of 10 matrices > each 1000 by 1000 just to get 2 coupled signals simulated. > > I do not feel all simulators should use the same method. I > feel most simulators may even want to use different methods > depending on the simulation needs. > > At 01:11 PM 6/14/00 -0700, Christopher Reid wrote: > >Gus, > > > >I don't consider any of this proprietary. I think its more important > >that its unambiguous so there is confidence that the intention of the > >connector vendors is followed when using the models. Every simulator > >should use the same method. > > > >Thanks, > > > >Chris > > > >apanella@molex.com wrote: > > > > > > So then, the recommendation would be to have the IBIS Connector Model > > > Specification _explicitly_ state how each simulator will implement the > > expansion > > > from the keywords and parameters already given in the specification. > > > > > > If the recommendation is acceptable (it is for me)... Would it be > > acceptable by > > > the simulator companies? If not.. is there a different option? > > > > > > In the discussion of this topic in the subcommittee, I got the > > impression that > > > the expansion method of matrices was somewhat seen as a proprietary > > technology. > > > As such, I wanted to build in enough keywords and usage rules that > > would allow > > > me to assign values that would _lessen_ the likelihood of incorrect > > simulator > > > implementation (assuming of course that I correctly defined the model, > > swath > > > size, and related keywords...) > > > > > > I will take this up at our next IBIS Connector Model subcommittee > > > teleconference. > > > > > > _gus: 630-527-4617 > > > > > > ____________________Reply Separator____________________ > > > Subject: Re: Connector spec swathing > > > Author: chris > > > Date: 6/14/00 9:13 AM > > > > > > Mike, > > > > > > Thanks for your illustration of my point. Clearly we have > > > exactly the same concern. > > > > > > Gus, > > > > > > Yes, including the larger matrix that is supposed to be expandable > > > to a full banded matrix would be useful, but it should also include > > > instructions on just how that smaller matrix is supposed to be used > > > to get the full banded matrix. > > > > > > Thanks, > > > > > > Chris > > > > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools > E-mail: > web: > --------------------------------------------------------- From owner-ibis Wed Jun 14 14:23:00 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA21526 for ; Wed, 14 Jun 2000 14:22:59 -0700 (PDT) Received: from gda.Cadence.COM (gda.Cadence.COM [158.140.106.10]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id OAA04434; Wed, 14 Jun 2000 14:20:55 -0700 (PDT) Received: from cadence.com (d158140105198 [158.140.105.198]) by gda.Cadence.COM (8.8.8/8.8.5) with ESMTP id RAA18499; Wed, 14 Jun 2000 17:20:53 -0400 (EDT) Message-ID: <3947F722.3CC13C4B@cadence.com> Date: Wed, 14 Jun 2000 17:20:34 -0400 From: Ian Dodd Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Kellee Crisafulli CC: Christopher Reid , apanella@molex.com, Mike LaBonte , IBIS Mailing list Subject: Re: Connector spec swathing References: <0016A0E7.CE21031@molex.com> <4.3.2.7.2.20000614134830.02e2cee0@pop.nwlink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as OAA04434 at Wed Jun 14 14:20:55 2000 All, If there is no recommendation of how to create a simulation model from the connector "data sheet" how does the connector company do basic validation after they have created a model. Doing speed/accuracy tradeoffs is good, but I think we need some way to create a golden simulation so the results can be compared back to measurement. Ian Kellee Crisafulli wrote: > > Hi Chris, > > I am having great difficultly understanding why > all the simulators should be forced to use the same method. > > This is an approximate approach in the first place. If one > simulator wants to use a method that runs 100,000 times faster > than another with a 1% accuracy reduction than it should > be able to do that. > > I feel the data must be unambiguous. The method should be > open to the simulator experts. I do think it reasonable to > provide one example method either as a description or as > code implemented in the IBIS parser. Perhaps a full matrix > extraction would make the most sense but I can hardly imagine > most simulators wanting to simulate a series of 10 matrices > each 1000 by 1000 just to get 2 coupled signals simulated. > > I do not feel all simulators should use the same method. I > feel most simulators may even want to use different methods > depending on the simulation needs. > > At 01:11 PM 6/14/00 -0700, Christopher Reid wrote: > >Gus, > > > >I don't consider any of this proprietary. I think its more important > >that its unambiguous so there is confidence that the intention of the > >connector vendors is followed when using the models. Every simulator > >should use the same method. > > > >Thanks, > > > >Chris > > > >apanella@molex.com wrote: > > > > > > So then, the recommendation would be to have the IBIS Connector Model > > > Specification _explicitly_ state how each simulator will implement the > > expansion > > > from the keywords and parameters already given in the specification. > > > > > > If the recommendation is acceptable (it is for me)... Would it be > > acceptable by > > > the simulator companies? If not.. is there a different option? > > > > > > In the discussion of this topic in the subcommittee, I got the > > impression that > > > the expansion method of matrices was somewhat seen as a proprietary > > technology. > > > As such, I wanted to build in enough keywords and usage rules that > > would allow > > > me to assign values that would _lessen_ the likelihood of incorrect > > simulator > > > implementation (assuming of course that I correctly defined the model, > > swath > > > size, and related keywords...) > > > > > > I will take this up at our next IBIS Connector Model subcommittee > > > teleconference. > > > > > > _gus: 630-527-4617 > > > > > > ____________________Reply Separator____________________ > > > Subject: Re: Connector spec swathing > > > Author: chris > > > Date: 6/14/00 9:13 AM > > > > > > Mike, > > > > > > Thanks for your illustration of my point. Clearly we have > > > exactly the same concern. > > > > > > Gus, > > > > > > Yes, including the larger matrix that is supposed to be expandable > > > to a full banded matrix would be useful, but it should also include > > > instructions on just how that smaller matrix is supposed to be used > > > to get the full banded matrix. > > > > > > Thanks, > > > > > > Chris > > > > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools > E-mail: > web: > --------------------------------------------------------- From owner-ibis Wed Jun 14 14:27:15 2000 Received: from oliver.al.dynip.com (root@209-63-189-213.sea.jps.net [209.63.189.213]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA21546 for ; Wed, 14 Jun 2000 14:27:03 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by oliver.al.dynip.com (8.9.3/8.9.3) id OAA07602 for ibis@eda.org; Wed, 14 Jun 2000 14:24:17 -0700 From: Al Davis To: "IBIS Mailing list" Subject: Re: Re[2]: Connector spec swathing Date: Wed, 14 Jun 2000 14:11:21 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <0016A0E7.CE21031@molex.com> <00bb01bfd627$331c6230$9594a8c0@hyperlynx.com> In-Reply-To: <00bb01bfd627$331c6230$9594a8c0@hyperlynx.com> MIME-Version: 1.0 Message-Id: <00061414240601.01552@oliver.al.dynip.com> Content-Transfer-Encoding: 8bit Regarding the comments ... "The spec and parser should generate a full matrix ....." Matt and Bob hit it. The spec should show the clearest method of doing it, to show what it really means. The parser should be an example of it, that should work, and be designed for readability rather than efficiency. Then, the simulator maker should be able to do it any way that works and is interchangeable with the original, hopefully coming up with something better. In this case, a full matrix is a very inefficient way to do it. I would not want to be restricted to such inefficiency. However, if the full matrix method is given, I can use it to validate my "superior" method. Also, the "superior" method will probably be less clear to someone who just wants to know what the spec means. From owner-ibis Wed Jun 14 15:30:45 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA21812 for ; Wed, 14 Jun 2000 15:30:44 -0700 (PDT) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id PAA01575; Wed, 14 Jun 2000 15:27:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20000614152040.02df8e40@pop.nwlink.com> Received: from KELLEE98 by ip210.c246.blk1.bel.nwlink.com via smtpd (for mail.nwlink.com [209.20.130.40]) with SMTP; 14 Jun 2000 22:27:42 UT X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2000 15:24:12 -0700 To: Christopher Reid From: Kellee Crisafulli Subject: Re: Connector spec swathing Cc: Christopher Reid , apanella@molex.com, Mike LaBonte , IBIS Mailing list In-Reply-To: <3947F2B1.32833A03@mentor.com> References: <0016A0E7.CE21031@molex.com> <4.3.2.7.2.20000614134830.02e2cee0@pop.nwlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id PAA21813 Hi Chris, all, Seems like we are getting consensus that allowing any method is OK but we need an example method for clarity and something that can be used for validation. The "golden parser" seems a logical place to do this. Let's "make it so" (Picard, Startrek) best wishes.. Kellee At 02:01 PM 6/14/00 -0700, Christopher Reid wrote: >Kellee, > >Your point is well taken. For example, the user may be given >an option of choosing a time step. For larger time steps >different approximations can be made. > >What I would like to see is an unambiguous definition of what >is expected (a prescription of how to use these models.) Each >vendor can then explain approximations that may be made that >deviate from this expected use in one way or another. > >Thanks for the input. I'm modifying my position to agree >with yours better. > >Chris > > >Kellee Crisafulli wrote: > > > > Hi Chris, > > > > I am having great difficultly understanding why > > all the simulators should be forced to use the same method. > > > > This is an approximate approach in the first place. If one > > simulator wants to use a method that runs 100,000 times faster > > than another with a 1% accuracy reduction than it should > > be able to do that. > > > > I feel the data must be unambiguous. The method should be > > open to the simulator experts. I do think it reasonable to > > provide one example method either as a description or as > > code implemented in the IBIS parser. Perhaps a full matrix > > extraction would make the most sense but I can hardly imagine > > most simulators wanting to simulate a series of 10 matrices > > each 1000 by 1000 just to get 2 coupled signals simulated. > > > > I do not feel all simulators should use the same method. I > > feel most simulators may even want to use different methods > > depending on the simulation needs. > > > > At 01:11 PM 6/14/00 -0700, Christopher Reid wrote: > > >Gus, > > > > > >I don't consider any of this proprietary. I think its more important > > >that its unambiguous so there is confidence that the intention of the > > >connector vendors is followed when using the models. Every simulator > > >should use the same method. > > > > > >Thanks, > > > > > >Chris > > > > > >apanella@molex.com wrote: > > > > > > > > So then, the recommendation would be to have the IBIS Connector Model > > > > Specification _explicitly_ state how each simulator will implement the > > > expansion > > > > from the keywords and parameters already given in the specification. > > > > > > > > If the recommendation is acceptable (it is for me)... Would it be > > > acceptable by > > > > the simulator companies? If not.. is there a different option? > > > > > > > > In the discussion of this topic in the subcommittee, I got the > > > impression that > > > > the expansion method of matrices was somewhat seen as a proprietary > > > technology. > > > > As such, I wanted to build in enough keywords and usage rules that > > > would allow > > > > me to assign values that would _lessen_ the likelihood of incorrect > > > simulator > > > > implementation (assuming of course that I correctly defined the model, > > > swath > > > > size, and related keywords...) > > > > > > > > I will take this up at our next IBIS Connector Model subcommittee > > > > teleconference. > > > > > > > > _gus: 630-527-4617 > > > > > > > > ____________________Reply Separator____________________ > > > > Subject: Re: Connector spec swathing > > > > Author: chris > > > > Date: 6/14/00 9:13 AM > > > > > > > > Mike, > > > > > > > > Thanks for your illustration of my point. Clearly we have > > > > exactly the same concern. > > > > > > > > Gus, > > > > > > > > Yes, including the larger matrix that is supposed to be expandable > > > > to a full banded matrix would be useful, but it should also include > > > > instructions on just how that smaller matrix is supposed to be used > > > > to get the full banded matrix. > > > > > > > > Thanks, > > > > > > > > Chris > > > > > > > > --------------------------------------------------------- > > Have a great day.... > > Kellee Crisafulli > > HyperLynx, a division of Pads Software Inc. > > SI,EMC,X-talk and IBIS tools > > E-mail: > > web: > > --------------------------------------------------------- --------------------------------------------------------- Have a great day.... Kellee Crisafulli HyperLynx, a division of Pads Software Inc. SI,EMC,X-talk and IBIS tools E-mail: web:   --------------------------------------------------------- From owner-ibis Thu Jun 15 00:27:17 2000 Received: from mr2.hi-ho.ne.jp (gem.hi-ho.ne.jp [202.224.159.137]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA26617 for ; Thu, 15 Jun 2000 00:27:16 -0700 (PDT) Received: from apsimtech.com (pl022.nas144.s-kawasaki.nttpc.ne.jp [210.139.58.150]) by mr2.hi-ho.ne.jp (Hi-HO Mail Server) with ESMTP id <0FW6000TNPXTJT@mr2.hi-ho.ne.jp> for ibis@eda.org; Thu, 15 Jun 2000 16:25:08 +0900 (JST) Date: Thu, 15 Jun 2000 01:33:07 -0700 From: fred Subject: Re: Connector spec swathing To: Kellee Crisafulli Cc: Christopher Reid , apanella@molex.com, Mike LaBonte , IBIS Mailing list Message-id: <394894C3.9CA42E6@apsimtech.com> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <0016A0E7.CE21031@molex.com> <4.3.2.7.2.20000614134830.02e2cee0@pop.nwlink.com> I know the connector specification committee has spent much time and effort in comming up with the specification. However the current swat matrix approach seems overly complicated and technically less than desirable. Why not give the full matrix and let the simulation SI tool decide which part of the matrix to choose for simulation based on what pin and coupling is desired. We (simulation vendors) only need the data. We can decide how and when to use what. What we need is the committee to do is identify the connector pins to the matrix diagonal entrys. If the connector is very large in terms of number of pins then whether one gets a full or sparse matrix will depend on the field solver capabilities. This is not intended to be critical of the committee which has worked long and hard to come up with a spec in the first place while hence keeping everybody happy. Best Regards, Kellee Crisafulli wrote: > Hi Chris, > > I am having great difficultly understanding why > all the simulators should be forced to use the same method. > > This is an approximate approach in the first place. If one > simulator wants to use a method that runs 100,000 times faster > than another with a 1% accuracy reduction than it should > be able to do that. > > I feel the data must be unambiguous. The method should be > open to the simulator experts. I do think it reasonable to > provide one example method either as a description or as > code implemented in the IBIS parser. Perhaps a full matrix > extraction would make the most sense but I can hardly imagine > most simulators wanting to simulate a series of 10 matrices > each 1000 by 1000 just to get 2 coupled signals simulated. > > I do not feel all simulators should use the same method. I > feel most simulators may even want to use different methods > depending on the simulation needs. > > At 01:11 PM 6/14/00 -0700, Christopher Reid wrote: > >Gus, > > > >I don't consider any of this proprietary. I think its more important > >that its unambiguous so there is confidence that the intention of the > >connector vendors is followed when using the models. Every simulator > >should use the same method. > > > >Thanks, > > > >Chris > > > >apanella@molex.com wrote: > > > > > > So then, the recommendation would be to have the IBIS Connector Model > > > Specification _explicitly_ state how each simulator will implement the > > expansion > > > from the keywords and parameters already given in the specification. > > > > > > If the recommendation is acceptable (it is for me)... Would it be > > acceptable by > > > the simulator companies? If not.. is there a different option? > > > > > > In the discussion of this topic in the subcommittee, I got the > > impression that > > > the expansion method of matrices was somewhat seen as a proprietary > > technology. > > > As such, I wanted to build in enough keywords and usage rules that > > would allow > > > me to assign values that would _lessen_ the likelihood of incorrect > > simulator > > > implementation (assuming of course that I correctly defined the model, > > swath > > > size, and related keywords...) > > > > > > I will take this up at our next IBIS Connector Model subcommittee > > > teleconference. > > > > > > _gus: 630-527-4617 > > > > > > ____________________Reply Separator____________________ > > > Subject: Re: Connector spec swathing > > > Author: chris > > > Date: 6/14/00 9:13 AM > > > > > > Mike, > > > > > > Thanks for your illustration of my point. Clearly we have > > > exactly the same concern. > > > > > > Gus, > > > > > > Yes, including the larger matrix that is supposed to be expandable > > > to a full banded matrix would be useful, but it should also include > > > instructions on just how that smaller matrix is supposed to be used > > > to get the full banded matrix. > > > > > > Thanks, > > > > > > Chris > > > > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools > E-mail: > web: > --------------------------------------------------------- From owner-ibis Thu Jun 15 04:45:42 2000 Received: from paloalto-smrly2.gtei.net (paloalto-smrly2.gtei.net [131.119.246.6]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA28052 for ; Thu, 15 Jun 2000 04:45:42 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by paloalto-smrly2.gtei.net (Postfix) with SMTP id 1BEB23A8F for ; Thu, 15 Jun 2000 11:43:38 +0000 (GMT) Received: from smtp.molex.com ([150.150.15.100]) by molexinc-cp.molex.com; Thu, 15 Jun 2000 07:43:10 +0000 (EST) Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 0016D115; Thu, 15 Jun 2000 06:41:37 -0500 Mime-Version: 1.0 Date: Thu, 15 Jun 2000 06:37:10 -0500 Message-ID: <0016D115.CE21031@molex.com> Subject: Re[2]: Connector spec swathing To: fred Cc: Kellee Crisafulli , IBIS Mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Fred, I am sure that if you have this question, so do others... as such I have prepared a fairly lengthy reply. The "basic" answer to the question is... Find a FIELD simulator that can generate a 100 pin connector model from a connector with a general current path length of around 2.5cm. Make sure it is a true 3D simulator. OK... now find one that can do such using less than 8GB of RAM and 4 xxxx GHz. processors - This is pretty much what one might call a high end PC/Workstation. Maybe even not "typical" hardware. OK... Using what has been found above... have the problem solve in the FIELD simulator in less than a week. (BTW, a week is solve time, it does not include reports, empirical confirmation, or support documentation) OK... now put that full matrix model that is generated into a circuit simulator.... Setup the rest of the problem.... go away for the weekend... comeback Monday.... still not done... Comeback Wednesday... Ooopps found out that a termination resistor was misplaced... restart the simulation. The point is... connector companies would be perfectly happy with smaller models... But from what I have been told my customers which are the same as many SI simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 pins... (Yes, these are all real connector sizes today). As a work around for this problem.... we suggest the preverbal "critical net analysis". Which will still take 8 hours to solve using something in the order of a 40 pin connector model. Also, I as a connector manufacture make parts with different circuit sizes... sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 models... Lets say we just go up to 100 pins... that is 10 models... at 3 days AVERAGE per model (smaller models take less time)... that means one month of FIELD SIMULATION time... and we STILL can not support any thing over 100 pins. Not to mention that connector companies have about 40,000 different product lines.. lets say conservatively that only 1% of the 40,000 require models... That's 400.... a conservative estimate would be that there are 10 circuit sizes for each of those 400 connectors... as such 4,000 different models. OF EACH Type. There are three basic types Single Line models, MultiLine Models, and Cascaded Models... then there are TWO VERSIONS of each type... distributed and lumped... grand total 24,000 SPECIFIC models. But wait, Now model makers and simulators also have to database and revision control the models. Point being... an auto swath will give end uses access to more models with more pin options than they ever had before (to answer the customers requests). And GREATLY reduce the redundancies such that the 24,000 models above can be done in 1 model per connector family.. or 400 files. _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: fred Date: 6/15/00 1:33 AM I know the connector specification committee has spent much time and effort in comming up with the specification. However the current swat matrix approach seems overly complicated and technically less than desirable. Why not give the full matrix and let the simulation SI tool decide which part of the matrix to choose for simulation based on what pin and coupling is desired. We (simulation vendors) only need the data. We can decide how and when to use what. What we need is the committee to do is identify the connector pins to the matrix diagonal entrys. If the connector is very large in terms of number of pins then whether one gets a full or sparse matrix will depend on the field solver capabilities. This is not intended to be critical of the committee which has worked long and hard to come up with a spec in the first place while hence keeping everybody happy. Best Regards, Kellee Crisafulli wrote: > Hi Chris, From owner-ibis Thu Jun 15 04:47:27 2000 Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA28062 for ; Thu, 15 Jun 2000 04:47:26 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 06FE85011E; Thu, 15 Jun 2000 11:44:51 +0000 (GMT) Received: from ishome.lisle.molex.com ([150.150.15.101]) by molexinc-cp.molex.com; Thu, 15 Jun 2000 07:44:45 +0000 (EST) Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 00010FDB; Thu, 15 Jun 2000 06:40:46 -0500 Mime-Version: 1.0 Date: Thu, 15 Jun 2000 06:37:10 -0500 Message-ID: <00010FDB.C21030@molex.com> Subject: Re[2]: Connector spec swathing To: fred Cc: Kellee Crisafulli , IBIS Mailing list Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Fred, I am sure that if you have this question, so do others... as such I have prepared a fairly lengthy reply. The "basic" answer to the question is... Find a FIELD simulator that can generate a 100 pin connector model from a connector with a general current path length of around 2.5cm. Make sure it is a true 3D simulator. OK... now find one that can do such using less than 8GB of RAM and 4 xxxx GHz. processors - This is pretty much what one might call a high end PC/Workstation. Maybe even not "typical" hardware. OK... Using what has been found above... have the problem solve in the FIELD simulator in less than a week. (BTW, a week is solve time, it does not include reports, empirical confirmation, or support documentation) OK... now put that full matrix model that is generated into a circuit simulator.... Setup the rest of the problem.... go away for the weekend... comeback Monday.... still not done... Comeback Wednesday... Ooopps found out that a termination resistor was misplaced... restart the simulation. The point is... connector companies would be perfectly happy with smaller models... But from what I have been told my customers which are the same as many SI simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 pins... (Yes, these are all real connector sizes today). As a work around for this problem.... we suggest the preverbal "critical net analysis". Which will still take 8 hours to solve using something in the order of a 40 pin connector model. Also, I as a connector manufacture make parts with different circuit sizes... sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 models... Lets say we just go up to 100 pins... that is 10 models... at 3 days AVERAGE per model (smaller models take less time)... that means one month of FIELD SIMULATION time... and we STILL can not support any thing over 100 pins. Not to mention that connector companies have about 40,000 different product lines.. lets say conservatively that only 1% of the 40,000 require models... That's 400.... a conservative estimate would be that there are 10 circuit sizes for each of those 400 connectors... as such 4,000 different models. OF EACH Type. There are three basic types Single Line models, MultiLine Models, and Cascaded Models... then there are TWO VERSIONS of each type... distributed and lumped... grand total 24,000 SPECIFIC models. But wait, Now model makers and simulators also have to database and revision control the models. Point being... an auto swath will give end uses access to more models with more pin options than they ever had before (to answer the customers requests). And GREATLY reduce the redundancies such that the 24,000 models above can be done in 1 model per connector family.. or 400 files. _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: fred Date: 6/15/00 1:33 AM I know the connector specification committee has spent much time and effort in comming up with the specification. However the current swat matrix approach seems overly complicated and technically less than desirable. Why not give the full matrix and let the simulation SI tool decide which part of the matrix to choose for simulation based on what pin and coupling is desired. We (simulation vendors) only need the data. We can decide how and when to use what. What we need is the committee to do is identify the connector pins to the matrix diagonal entrys. If the connector is very large in terms of number of pins then whether one gets a full or sparse matrix will depend on the field solver capabilities. This is not intended to be critical of the committee which has worked long and hard to come up with a spec in the first place while hence keeping everybody happy. Best Regards, Kellee Crisafulli wrote: > Hi Chris, From owner-ibis Thu Jun 15 09:26:04 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA29354 for ; Thu, 15 Jun 2000 09:26:03 -0700 (PDT) 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 MAA02955 for ; Thu, 15 Jun 2000 12:23:29 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA06577 for ; Thu, 15 Jun 2000 12:23:27 -0400 (EDT) Received: from pcchrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id JAA18472 for ; Thu, 15 Jun 2000 09:23:21 -0700 (PDT) From: "Chris Rokusek" To: "IBIS Mailing list" Subject: RE: Re[2]: Connector spec swathing Date: Thu, 15 Jun 2000 09:27:55 -0700 Message-ID: <000b01bfd6e6$a8d90400$aac2b58b@camarillo.viewlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <0016D115.CE21031@molex.com> Gus, Given that some companies actually do possess the tools to create Full Matrix connectors (& packages) accurately and efficiently and given that simulators MUST come up with algorithms to reduce this full matrix (perhaps efficiently with an accuracy tradeoff), simulator companies are just trying to avoid extra work in having to write two algorithms that do very similar things--one to expand the swath to arbitrary pins and one to reduce the full matrix to arbitrary pins. Many of us prefer to solve the most general/accurate problem first (Full Matrix). I don't think we're saying "don't use the swath", I think all we're saying is provide us with a recommended algorithm (and perhaps build it into the parser) for expanding the swath into a full matrix so that each simulator can potentially get the same answer for the most general case. It seems like that would keep everybody happy. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Thursday, June 15, 2000 4:37 AM > To: fred > Cc: Kellee Crisafulli; IBIS Mailing list > Subject: Re[2]: Connector spec swathing > > > Fred, > > I am sure that if you have this question, so do others... as such I have > prepared a fairly lengthy reply. > > The "basic" answer to the question is... > > Find a FIELD simulator that can generate a 100 pin connector model from a > connector with a general current path length of around 2.5cm. > > Make sure it is a true 3D simulator. > > OK... now find one that can do such using less than 8GB of RAM > and 4 xxxx GHz. > processors > - This is pretty much what one might call a high end > PC/Workstation. Maybe > even not "typical" hardware. > > OK... Using what has been found above... have the problem solve > in the FIELD > simulator in less than a week. (BTW, a week is solve time, it > does not include > reports, empirical confirmation, or support documentation) > > OK... now put that full matrix model that is generated into a circuit > simulator.... Setup the rest of the problem.... go away for the > weekend... > comeback Monday.... still not done... Comeback Wednesday... > Ooopps found out > that a termination resistor was misplaced... restart the simulation. > > > The point is... connector companies would be perfectly happy with smaller > models... > > But from what I have been told my customers which are the same as many SI > simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 > pins... (Yes, > these are all real connector sizes today). > > > As a work around for this problem.... we suggest the preverbal > "critical net > analysis". Which will still take 8 hours to solve using something > in the order > of a 40 pin connector model. > > Also, I as a connector manufacture make parts with different > circuit sizes... > sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 > models... Lets say we just go up to 100 pins... that is 10 > models... at 3 days > AVERAGE per model (smaller models take less time)... that means > one month of > FIELD SIMULATION time... and we STILL can not support any thing > over 100 pins. > > > Not to mention that connector companies have about 40,000 > different product > lines.. lets say conservatively that only 1% of the 40,000 > require models... > That's 400.... a conservative estimate would be that there are 10 > circuit sizes > for each of those 400 connectors... as such 4,000 different > models. OF EACH > Type. There are three basic types Single Line models, MultiLine > Models, and > Cascaded Models... then there are TWO VERSIONS of each type... > distributed and > lumped... grand total 24,000 SPECIFIC models. > > But wait, Now model makers and simulators also have to database > and revision > control the models. > > Point being... an auto swath will give end uses access to more > models with more > pin options than they ever had before (to answer the customers > requests). And > GREATLY reduce the redundancies such that the 24,000 models above > can be done in > 1 model per connector family.. or 400 files. > > > _gus: 630-527-4617 > > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: fred > Date: 6/15/00 1:33 AM > > I know the connector specification committee has spent much time > and effort in > comming up with the specification. However the current swat > matrix approach > seems overly complicated and technically less than desirable. > Why not give the > > full matrix and let the simulation SI tool decide which part of > the matrix to > choose > for simulation based on what pin and coupling is desired. We (simulation > vendors) > only need the data. We can decide how and when to use what. What > we need is > the committee to do is identify the connector pins to the matrix diagonal > entrys. If > the connector is very large in terms of number of pins then > whether one gets a > full > or sparse matrix will depend on the field solver capabilities. This is not > intended to > be critical of the committee which has worked long and hard to > come up with a > spec > in the first place while hence keeping everybody happy. > > Best Regards, > > Kellee Crisafulli wrote: > > > Hi Chris, > From owner-ibis Thu Jun 15 10:06:52 2000 Received: from paloalto-smrly2.gtei.net (paloalto-smrly2.gtei.net [131.119.246.6]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA29492 for ; Thu, 15 Jun 2000 10:06:52 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by paloalto-smrly2.gtei.net (Postfix) with SMTP id 5007F3B6E; Thu, 15 Jun 2000 17:04:47 +0000 (GMT) Received: from ishome.lisle.molex.com ([150.150.15.101]) by molexinc-cp.molex.com; Thu, 15 Jun 2000 13:04:45 +0000 (EST) Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 0001130C; Thu, 15 Jun 2000 12:01:47 -0500 Mime-Version: 1.0 Date: Thu, 15 Jun 2000 11:56:05 -0500 Message-ID: <0001130C.C21030@molex.com> Subject: Re[2]: Connector spec swathing To: Ian Dodd , IBIS Mailing list Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part For what it is worth... I have been specifically trying to NOT do empirical confirmations for the ICM specification. Why? * Accuracy will very based on simulation algorithm. Different algorithms may produce different results. All simulators may not use the same algorithm. As such, confirmation to an empirical test will effectively qualify a simulator... not necessarily the model. We have well over 10,000 hours spent on methodologies and procedures for analytical to empirical transmission line model confirmations in SPICE to VNA to TDR to LCR to crosstalk to ...etc... I can not afford to do the same confirmation with each simulator on the market. * Empirical test need fixturing. "Golden fixturing" for correlation level work requires large amounts of design time... and extreme control over the manufacturing. This relates to large amounts of time and dollars required for PCB design and build. * Empirical test needs a test procedure for BOTH the simulation and the empirical test. Developing crosstalk, impedance, TDR, inductance, capacitance, ground bounce, jitter, etc... takes some time. And just try to get more than one person to agree on methodologies. As such, what I am proposing instead.... ** Generate "Golden Matrices" from a couple of different geometries. ** Berkeley SPICE models can be generated from a "Golden matrix" (or matrices). Let's call these golden models. ** These models can be run in Berkeley SPICE using Berkeley source and termination components. The Berkeley algorithms are well known/understood. ** Specific circuit configurations can be setup. Let's call these "Golden Test Simulations". ** From the "Golden Tests"... "Golden Waveforms" can be generated. In this scenario.... we are building "baseline information". Now... the same "Golden Matrices" used to generate the SPICE models can be DIRECTLY installed into an ICM. Now each individual simulator company, end user, other... can use the "Golden Matrx" and setup the same "Golden Test Simulations" and get results for a given simulator. These results can be compared to the "Golden Waveforms" as a GENERAL confirmation. In the proposed scenario, fixturing and test methodology is not part of the picture.... This, in my mind, will create an adequate confirmation that is straight forward and timely in it's implementation. _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: Ian Dodd Date: 6/14/00 5:20 PM All, If there is no recommendation of how to create a simulation model from the connector "data sheet" how does the connector company do basic validation after they have created a model. Doing speed/accuracy tradeoffs is good, but I think we need some way to create a golden simulation so the results can be compared back to measurement. Ian Kellee Crisafulli wrote: > > Hi Chris, > From owner-ibis Thu Jun 15 10:07:18 2000 Received: from paloalto-smrly2.gtei.net (paloalto-smrly2.gtei.net [131.119.246.6]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA29497 for ; Thu, 15 Jun 2000 10:07:18 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by paloalto-smrly2.gtei.net (Postfix) with SMTP id AA6923B8F for ; Thu, 15 Jun 2000 17:05:13 +0000 (GMT) Received: from smtp.molex.com ([150.150.15.100]) by molexinc-cp.molex.com; Thu, 15 Jun 2000 13:05:06 +0000 (EST) Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 0016E7C2; Thu, 15 Jun 2000 12:02:40 -0500 Mime-Version: 1.0 Date: Thu, 15 Jun 2000 11:56:05 -0500 Message-ID: <0016E7C2.CE21031@molex.com> Subject: Re[2]: Connector spec swathing To: Ian Dodd , IBIS Mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part For what it is worth... I have been specifically trying to NOT do empirical confirmations for the ICM specification. Why? * Accuracy will very based on simulation algorithm. Different algorithms may produce different results. All simulators may not use the same algorithm. As such, confirmation to an empirical test will effectively qualify a simulator... not necessarily the model. We have well over 10,000 hours spent on methodologies and procedures for analytical to empirical transmission line model confirmations in SPICE to VNA to TDR to LCR to crosstalk to ...etc... I can not afford to do the same confirmation with each simulator on the market. * Empirical test need fixturing. "Golden fixturing" for correlation level work requires large amounts of design time... and extreme control over the manufacturing. This relates to large amounts of time and dollars required for PCB design and build. * Empirical test needs a test procedure for BOTH the simulation and the empirical test. Developing crosstalk, impedance, TDR, inductance, capacitance, ground bounce, jitter, etc... takes some time. And just try to get more than one person to agree on methodologies. As such, what I am proposing instead.... ** Generate "Golden Matrices" from a couple of different geometries. ** Berkeley SPICE models can be generated from a "Golden matrix" (or matrices). Let's call these golden models. ** These models can be run in Berkeley SPICE using Berkeley source and termination components. The Berkeley algorithms are well known/understood. ** Specific circuit configurations can be setup. Let's call these "Golden Test Simulations". ** From the "Golden Tests"... "Golden Waveforms" can be generated. In this scenario.... we are building "baseline information". Now... the same "Golden Matrices" used to generate the SPICE models can be DIRECTLY installed into an ICM. Now each individual simulator company, end user, other... can use the "Golden Matrx" and setup the same "Golden Test Simulations" and get results for a given simulator. These results can be compared to the "Golden Waveforms" as a GENERAL confirmation. In the proposed scenario, fixturing and test methodology is not part of the picture.... This, in my mind, will create an adequate confirmation that is straight forward and timely in it's implementation. _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: Ian Dodd Date: 6/14/00 5:20 PM All, If there is no recommendation of how to create a simulation model from the connector "data sheet" how does the connector company do basic validation after they have created a model. Doing speed/accuracy tradeoffs is good, but I think we need some way to create a golden simulation so the results can be compared back to measurement. Ian Kellee Crisafulli wrote: > > Hi Chris, > From owner-ibis Thu Jun 15 10:11:20 2000 Received: from mail01-oak.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA29519 for ; Thu, 15 Jun 2000 10:11:19 -0700 (PDT) Received: from unknown-101-146.idt.com ([206.24.101.146]) by mail01-oak.pilot.net with ESMTP id KAA09081 for ; Thu, 15 Jun 2000 10:09:15 -0700 (PDT) Received: from mail.idt.com (localhost [127.0.0.1]) by unknown-101-146.idt.com with ESMTP id KAA03718 for ; Thu, 15 Jun 2000 10:09:13 -0700 (PDT) Received: from Eng.idt.com (firewall-user@supercop4.idt.com [157.165.5.10]) by mail.idt.com (8.8.5/8.7.5) with ESMTP id KAA08167 for ; Thu, 15 Jun 2000 10:09:01 -0700 (PDT) Received: from mig.Eng.idt.com (mig.Eng.idt.com [157.165.31.143]) by Eng.idt.com (8.8.5/8.6.12) with ESMTP id KAA29609 for ; Thu, 15 Jun 2000 10:09:11 -0700 (PDT) From: Roy Gao Received: (rgao@localhost) by mig.Eng.idt.com (8.6.12/8.6.12) id KAA04374 for ibis@eda.org; Thu, 15 Jun 2000 10:09:13 -0700 Date: Thu, 15 Jun 2000 10:09:13 -0700 Message-Id: <200006151709.KAA04374@mig.Eng.idt.com> To: ibis@eda.org Subject: unsubscribe From owner-ibis Thu Jun 15 11:30:12 2000 Received: from showboat.teradyne.com ([198.51.251.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA29818 for ; Thu, 15 Jun 2000 11:30:11 -0700 (PDT) Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id OAA18208; Thu, 15 Jun 2000 14:26:42 -0400 (EDT) Received: from notes.teradyne.com (jaypeak.corp.teradyne.com [131.101.17.23]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with SMTP id OAA18617; Thu, 15 Jun 2000 14:28:02 -0400 (EDT) Received: by notes.teradyne.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 852568FF.006588D8 ; Thu, 15 Jun 2000 14:29:01 -0400 X-Lotus-FromDomain: TERADYNE From: "Mikhail Khusid" To: "Chris Rokusek" cc: "IBIS Mailing list" Message-ID: <852568FF.006587EF.00@notes.teradyne.com> Date: Thu, 15 Jun 2000 14:28:49 -0400 Subject: RE: Re[2]: Connector spec swathing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Chris, Whether a connector company can make a full matrix model of a connector depends more on the connector than the tools. In fact, if a connector is complicated enough to warrant several L and C sections, and if a connector has many pins, providing a full matrix model can be very unpractical. As a representative of the connector company where a 570 pin connector is considered a small one, I can assure you that it's impossible for me to generate dozens of 570x570 matrices. Furthermore, I doubt that any simulator will be able to solve a problem with full matrices of that size. Doing a swath method allows me to generate reasonable size matrices, up to 30x30, which should respresent sufficient couplings inside the connector, and thus is an effective way to simulate the connector behavior in reasonable time. Lastly, I agree with Kellee that a standard should probably include a description of a "golden" way to generate a full matrix model out of a swath, however, I would welcome simulator companies attempts to avoid using this method for every connector. Michael Khusid Teradyne Connection Systems http://www.teradyne.com "Chris Rokusek" on 06/15/2000 12:27:55 PM To: "IBIS Mailing list" cc: (bcc: Mikhail Khusid/NNH/Teradyne) Subject: RE: Re[2]: Connector spec swathing Gus, Given that some companies actually do possess the tools to create Full Matrix connectors (& packages) accurately and efficiently and given that simulators MUST come up with algorithms to reduce this full matrix (perhaps efficiently with an accuracy tradeoff), simulator companies are just trying to avoid extra work in having to write two algorithms that do very similar things--one to expand the swath to arbitrary pins and one to reduce the full matrix to arbitrary pins. Many of us prefer to solve the most general/accurate problem first (Full Matrix). I don't think we're saying "don't use the swath", I think all we're saying is provide us with a recommended algorithm (and perhaps build it into the parser) for expanding the swath into a full matrix so that each simulator can potentially get the same answer for the most general case. It seems like that would keep everybody happy. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Thursday, June 15, 2000 4:37 AM > To: fred > Cc: Kellee Crisafulli; IBIS Mailing list > Subject: Re[2]: Connector spec swathing > > > Fred, > > I am sure that if you have this question, so do others... as such I have > prepared a fairly lengthy reply. > > The "basic" answer to the question is... > > Find a FIELD simulator that can generate a 100 pin connector model from a > connector with a general current path length of around 2.5cm. > > Make sure it is a true 3D simulator. > > OK... now find one that can do such using less than 8GB of RAM > and 4 xxxx GHz. > processors > - This is pretty much what one might call a high end > PC/Workstation. Maybe > even not "typical" hardware. > > OK... Using what has been found above... have the problem solve > in the FIELD > simulator in less than a week. (BTW, a week is solve time, it > does not include > reports, empirical confirmation, or support documentation) > > OK... now put that full matrix model that is generated into a circuit > simulator.... Setup the rest of the problem.... go away for the > weekend... > comeback Monday.... still not done... Comeback Wednesday... > Ooopps found out > that a termination resistor was misplaced... restart the simulation. > > > The point is... connector companies would be perfectly happy with smaller > models... > > But from what I have been told my customers which are the same as many SI > simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 > pins... (Yes, > these are all real connector sizes today). > > > As a work around for this problem.... we suggest the preverbal > "critical net > analysis". Which will still take 8 hours to solve using something > in the order > of a 40 pin connector model. > > Also, I as a connector manufacture make parts with different > circuit sizes... > sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 > models... Lets say we just go up to 100 pins... that is 10 > models... at 3 days > AVERAGE per model (smaller models take less time)... that means > one month of > FIELD SIMULATION time... and we STILL can not support any thing > over 100 pins. > > > Not to mention that connector companies have about 40,000 > different product > lines.. lets say conservatively that only 1% of the 40,000 > require models... > That's 400.... a conservative estimate would be that there are 10 > circuit sizes > for each of those 400 connectors... as such 4,000 different > models. OF EACH > Type. There are three basic types Single Line models, MultiLine > Models, and > Cascaded Models... then there are TWO VERSIONS of each type... > distributed and > lumped... grand total 24,000 SPECIFIC models. > > But wait, Now model makers and simulators also have to database > and revision > control the models. > > Point being... an auto swath will give end uses access to more > models with more > pin options than they ever had before (to answer the customers > requests). And > GREATLY reduce the redundancies such that the 24,000 models above > can be done in > 1 model per connector family.. or 400 files. > > > _gus: 630-527-4617 > > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: fred > Date: 6/15/00 1:33 AM > > I know the connector specification committee has spent much time > and effort in > comming up with the specification. However the current swat > matrix approach > seems overly complicated and technically less than desirable. > Why not give the > > full matrix and let the simulation SI tool decide which part of > the matrix to > choose > for simulation based on what pin and coupling is desired. We (simulation > vendors) > only need the data. We can decide how and when to use what. What > we need is > the committee to do is identify the connector pins to the matrix diagonal > entrys. If > the connector is very large in terms of number of pins then > whether one gets a > full > or sparse matrix will depend on the field solver capabilities. This is not > intended to > be critical of the committee which has worked long and hard to > come up with a > spec > in the first place while hence keeping everybody happy. > > Best Regards, > > Kellee Crisafulli wrote: > > > Hi Chris, > From owner-ibis Thu Jun 15 11:48:55 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA29888 for ; Thu, 15 Jun 2000 11:48:55 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA14088; Thu, 15 Jun 2000 11:46:20 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA25971; Thu, 15 Jun 2000 11:46:18 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3949247B.EB579E28@mentor.com> Date: Thu, 15 Jun 2000 11:46:19 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: Connector spec swathing References: <852568FF.006587EF.00@notes.teradyne.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: In response to a number of comments concerning algorithms for processing swath matrices, here is an algorithm to map the swath information into a larger swath or into the full-sized connector. The algorithm assumes that the internal connector coupling topology is uniform for the internal structure of the connector and that the left of center and right of center topologies of the connector are the same as the corresponding left of center and right of center topologies of the swath. Because the IBIS matrices symmetrical about the diagonal (circuit theory symmetry) the coupling topology is always from a given pin looking forward. The resulting connector matrix is banded to the same bandwidth as the swath matrix (which itself could have a bandwidth corresponding to its total number of pins or less, depending on its coupling topology). This approach could be also be used to map smaller Spice netlists for swath sections into larger Spice netlists covering more pins. (Also, this approach could be generalized into a matrix expansion language that accounts for non-uniform sections, missing pins, cutout sections, but based on a set of "consistent" swath matrices S1, S2, ... that describe the variations from the standard standard Swath S, but the details and requirements would have to be defined.) Bob Ross Mentor Graphics SWATH MATRIX PINS = S CONNECTOR MATRIX PINS = C I. - One Dimensional Column Mapping: (Swath Rows = Connector Rows) Center column (or left of center for even number of columns) | | S S S S S S S S S S .... S S S S S | | | | +---------------+ | | | +---------------+ | | | +---------------+ | | | | | | | | | ... | | | | C C C C C C C ... C C C C C C C C C C C ... C C C C .... C C C C C C C ... C C C C 1 1 2 ............. 2 3 3 <--- Mapping Notes: 1 - Direct Mapping of the Left Side Swath Coupling Topology 2 - Center Swath Coupling Topology Column mapped into each connector column, stepping one column at a time 3 - Direct Mapping of the Right Side Swath Coupling Topology II. - Two Dimensional Row and Column Mapping: (Swath Rows less than Connector Rows) Step 1. Create Temporary Swath with Same Number of Rows as Connector using Approach similar to I., but applied to Row Expansion (instead of Column Expansion). Step 2. Use Temporary Swath for Column Expansion using Approach I. From owner-ibis Thu Jun 15 11:55:46 2000 Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA29912 for ; Thu, 15 Jun 2000 11:55:46 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 69F16503A6 for ; Thu, 15 Jun 2000 18:53:07 +0000 (GMT) Received: from smtp.molex.com ([150.150.15.100]) by molexinc-cp.molex.com; Thu, 15 Jun 2000 14:53:00 +0000 (EST) Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 0016EE77; Thu, 15 Jun 2000 13:51:40 -0500 Mime-Version: 1.0 Date: Thu, 15 Jun 2000 13:49:12 -0500 Message-ID: <0016EE77.CE21031@molex.com> Subject: Re:RE: Re[2]: Connector spec swathing To: "IBIS Mailing list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Chris, My basic reply was to the comment that we should just create full matrices and be done with it... To this I disagree.. I agree that it would be nice to have an "example" (less stronger than "recommended") of a "swath implementation". I am not sure that there should be a downside to this activity... other than the time it would take to contribute to the common good. As with this issue and as with the specification to date, I would be willing to work with someone to make it happen. I think the sub-committee could take this on... but I wouldn't want to overstep my inference space. IBISCnn Subcommittee... I think we are good with making an example.... maybe??? Either way... let's put this issue to bed (To make an example or not make an example, that is the question :) ) at out next subcommittee teleconference. Chris, We may want to call upon you for your help with this activity. Would you be available? _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: RE: Re[2]: Connector spec swathing Author: "Chris Rokusek" Date: 6/15/00 9:27 AM Gus, Given that some companies actually do possess the tools to create Full Matrix connectors (& packages) accurately and efficiently and given that simulators MUST come up with algorithms to reduce this full matrix (perhaps efficiently with an accuracy tradeoff), simulator companies are just trying to avoid extra work in having to write two algorithms that do very similar things--one to expand the swath to arbitrary pins and one to reduce the full matrix to arbitrary pins. Many of us prefer to solve the most general/accurate problem first (Full Matrix). I don't think we're saying "don't use the swath", I think all we're saying is provide us with a recommended algorithm (and perhaps build it into the parser) for expanding the swath into a full matrix so that each simulator can potentially get the same answer for the most general case. It seems like that would keep everybody happy. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Thursday, June 15, 2000 4:37 AM > To: fred > Cc: Kellee Crisafulli; IBIS Mailing list > Subject: Re[2]: Connector spec swathing > > > Fred, > > I am sure that if you have this question, so do others... as such I have > prepared a fairly lengthy reply. > > The "basic" answer to the question is... > > Find a FIELD simulator that can generate a 100 pin connector model from a > connector with a general current path length of around 2.5cm. > > Make sure it is a true 3D simulator. > > OK... now find one that can do such using less than 8GB of RAM > and 4 xxxx GHz. > processors > - This is pretty much what one might call a high end > PC/Workstation. Maybe > even not "typical" hardware. > > OK... Using what has been found above... have the problem solve > in the FIELD > simulator in less than a week. (BTW, a week is solve time, it > does not include > reports, empirical confirmation, or support documentation) > > OK... now put that full matrix model that is generated into a circuit > simulator.... Setup the rest of the problem.... go away for the > weekend... > comeback Monday.... still not done... Comeback Wednesday... > Ooopps found out > that a termination resistor was misplaced... restart the simulation. > > > The point is... connector companies would be perfectly happy with smaller > models... > > But from what I have been told my customers which are the same as many SI > simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 > pins... (Yes, > these are all real connector sizes today). > > > As a work around for this problem.... we suggest the preverbal > "critical net > analysis". Which will still take 8 hours to solve using something > in the order > of a 40 pin connector model. > > Also, I as a connector manufacture make parts with different > circuit sizes... > sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 > models... Lets say we just go up to 100 pins... that is 10 > models... at 3 days > AVERAGE per model (smaller models take less time)... that means > one month of > FIELD SIMULATION time... and we STILL can not support any thing > over 100 pins. > > > Not to mention that connector companies have about 40,000 > different product > lines.. lets say conservatively that only 1% of the 40,000 > require models... > That's 400.... a conservative estimate would be that there are 10 > circuit sizes > for each of those 400 connectors... as such 4,000 different > models. OF EACH > Type. There are three basic types Single Line models, MultiLine > Models, and > Cascaded Models... then there are TWO VERSIONS of each type... > distributed and > lumped... grand total 24,000 SPECIFIC models. > > But wait, Now model makers and simulators also have to database > and revision > control the models. > > Point being... an auto swath will give end uses access to more > models with more > pin options than they ever had before (to answer the customers > requests). And > GREATLY reduce the redundancies such that the 24,000 models above > can be done in > 1 model per connector family.. or 400 files. > > > _gus: 630-527-4617 > > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: fred > Date: 6/15/00 1:33 AM > > I know the connector specification committee has spent much time > and effort in > comming up with the specification. However the current swat > matrix approach > seems overly complicated and technically less than desirable. > Why not give the > > full matrix and let the simulation SI tool decide which part of > the matrix to > choose > for simulation based on what pin and coupling is desired. We (simulation > vendors) > only need the data. We can decide how and when to use what. What > we need is > the committee to do is identify the connector pins to the matrix diagonal > entrys. If > the connector is very large in terms of number of pins then > whether one gets a > full > or sparse matrix will depend on the field solver capabilities. This is not > intended to > be critical of the committee which has worked long and hard to > come up with a > spec > in the first place while hence keeping everybody happy. > > Best Regards, > > Kellee Crisafulli wrote: > > > Hi Chris, > From owner-ibis Thu Jun 15 12:05:38 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA29932 for ; Thu, 15 Jun 2000 12:05:37 -0700 (PDT) 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 PAA07362 for ; Thu, 15 Jun 2000 15:00:18 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id PAA14669 for ; Thu, 15 Jun 2000 15:00:17 -0400 (EDT) Received: from pcchrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id MAA20357 for ; Thu, 15 Jun 2000 12:00:10 -0700 (PDT) From: "Chris Rokusek" To: "IBIS Mailing list" Subject: RE: Re[2]: Connector spec swathing Date: Thu, 15 Jun 2000 12:04:45 -0700 Message-ID: <000f01bfd6fc$9191fe30$aac2b58b@camarillo.viewlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <852568FF.006587EF.00@notes.teradyne.com> Mikkail, Did I say you should directly provide a full matrix? Absolutely not. My original request that started this whole thread is simply that the mapping from swath to full matrix to be clearly defined and perhaps provided by the parser. Repeated: I am not saying "Don't use the swath" !!! Chris Rokusek Innoveda > -----Original Message----- > From: Mikhail Khusid [mailto:Mikhail_Khusid@notes.teradyne.com] > Sent: Thursday, June 15, 2000 11:29 AM > To: Chris Rokusek > Cc: IBIS Mailing list > Subject: RE: Re[2]: Connector spec swathing > > > Chris, > > Whether a connector company can make a full matrix model of a connector > depends more on the connector than the tools. In fact, if a connector is > complicated enough to warrant several L and C sections, and if a connector > has many pins, providing a full matrix model can be very unpractical. > > As a representative of the connector company where a 570 pin connector > is considered a small one, I can assure you that it's impossible for me > to generate dozens of 570x570 matrices. Furthermore, I doubt that any > simulator will be able to solve a problem with full matrices of that size. > Doing a swath method allows me to generate reasonable size matrices, > up to 30x30, which should respresent sufficient couplings inside > the connector, and thus is an effective way to simulate the connector > behavior in reasonable time. > > Lastly, I agree with Kellee that a standard should probably include > a description of a "golden" way to generate a full matrix model > out of a swath, > however, I would welcome simulator companies attempts to avoid using > this method for every connector. > > Michael Khusid > Teradyne Connection Systems > http://www.teradyne.com > > > > > > > "Chris Rokusek" on 06/15/2000 12:27:55 PM > > To: "IBIS Mailing list" > cc: (bcc: Mikhail Khusid/NNH/Teradyne) > Subject: RE: Re[2]: Connector spec swathing > > > > > Gus, > > Given that some companies actually do possess the tools to create Full > Matrix connectors (& packages) accurately and efficiently and given that > simulators MUST come up with algorithms to reduce this full > matrix (perhaps > efficiently with an accuracy tradeoff), simulator companies are > just trying > to avoid extra work in having to write two algorithms that do very similar > things--one to expand the swath to arbitrary pins and one to > reduce the full > matrix to arbitrary pins. Many of us prefer to solve the most > general/accurate problem first (Full Matrix). > > I don't think we're saying "don't use the swath", I think all we're saying > is provide us with a recommended algorithm (and perhaps build it into the > parser) for expanding the swath into a full matrix so that each simulator > can potentially get the same answer for the most general case. It seems > like that would keep everybody happy. > > Chris Rokusek > Innoveda > From owner-ibis Thu Jun 15 13:29:38 2000 Received: from [12.26.64.34] (mail.erniairlight.com [12.26.64.34]) by server.eda.org (8.8.5/8.8.3) with SMTP id NAA00216 for ; Thu, 15 Jun 2000 13:29:36 -0700 (PDT) From: mnaegele@ernicomponents.com Received: from ERNI_1 by [12.26.64.34] via smtpd (for server.eda.org [171.64.101.101]) with SMTP; 15 Jun 2000 20:19:11 UT Received: from erni_west.ERNICOMP ([12.9.123.4]) by erni_1.ernicomponents.com (Lotus Domino Release 5.0.3) with ESMTP id 2000061516272229:3274 ; Thu, 15 Jun 2000 16:27:22 -0400 Subject: unsubscribe To: ibis@eda.org X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Thu, 15 Jun 2000 13:16:35 -0700 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ERNI_WEST/ERNICOMP(Release 5.0.2c |February 2, 2000) at 06/15/2000 01:16:36 PM, Itemize by SMTP Server on ERNI_1/ERNICOMP(Release 5.0.3 |March 21, 2000) at 06/15/2000 04:27:22 PM, Serialize by Router on ERNI_1/ERNICOMP(Release 5.0.3 |March 21, 2000) at 06/15/2000 04:27:31 PM From owner-ibis Thu Jun 15 13:28:55 2000 Received: from amdext2.amd.com (amdext2.amd.com [163.181.251.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA00211 for ; Thu, 15 Jun 2000 13:28:54 -0700 (PDT) From: morrie.altmejd@amd.com Received: from wsmail.amd.com ([163.181.250.5]) by amdext2.amd.com (8.9.3/8.9.3/AMD) with SMTP id PAA06498 for ; Thu, 15 Jun 2000 15:26:07 -0500 (CDT) Received: from 163.181.250.1 by wsmail.amd.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 15 Jun 2000 15:31:16 -0500 X-Server-Uuid: b85f21a3-cfd1-11d3-8401-00104bf46ab7 Received: from txexmta9.amd.com (txexmta9.amd.com [163.181.3.119]) by amdint2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id PAA05526 for ; Thu, 15 Jun 2000 15:26:02 -0500 (CDT) Received: by txexmta9.amd.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 15:26:02 -0500 Message-ID: <39073472CFF4D111A5AB00805F9FE4B6ECBB74@txexmta9.amd.com> To: ibis@eda.org Subject: unsubscribe Date: Thu, 15 Jun 2000 15:26:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 1557E29E4545-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From owner-ibis Thu Jun 15 14:50:46 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA00465 for ; Thu, 15 Jun 2000 14:50:45 -0700 (PDT) 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 RAA11142 for ; Thu, 15 Jun 2000 17:48:09 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id RAA22814 for ; Thu, 15 Jun 2000 17:48:08 -0400 (EDT) Received: from pcchrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id OAA21722 for ; Thu, 15 Jun 2000 14:48:01 -0700 (PDT) From: "Chris Rokusek" To: "IBIS Mailing list" Subject: RE: RE: Re[2]: Connector spec swathing Date: Thu, 15 Jun 2000 14:52:36 -0700 Message-ID: <001301bfd714$04c377a0$aac2b58b@camarillo.viewlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <0016EE77.CE21031@molex.com> Gus, > Chris, > We may want to call upon you for your help with this activity. > Would you be > available? I'll help where I can... Bob's example is a good starting point for uniform internal coupling but as he states it could be generalized further for non-uniform internal coupling (as well as the other generalizations he mentions if they are allowed by the spec). My assumption is that the Connector Spec does not restrict a swath to have uniform internal coupling. Now if uniform coupling is the norm then I guess we're ready to party. BTW: Does Molex/Amp/Teradyne already have a app note describing swath expansion beyond Bob's posting? Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Thursday, June 15, 2000 11:49 AM > To: IBIS Mailing list > Subject: Re:RE: Re[2]: Connector spec swathing > > > Chris, > > My basic reply was to the comment that we should just create full > matrices and > be done with it... To this I disagree.. > > I agree that it would be nice to have an "example" (less stronger than > "recommended") of a "swath implementation". I am not sure that > there should be > a downside to this activity... other than the time it would take > to contribute > to the common good. > > As with this issue and as with the specification to date, I would > be willing to > work with someone to make it happen. I think the sub-committee > could take this > on... but I wouldn't want to overstep my inference space. > > IBISCnn Subcommittee... I think we are good with making an example.... > maybe??? Either way... let's put this issue to bed (To make an > example or not > make an example, that is the question :) ) at out next subcommittee > teleconference. > > Chris, > We may want to call upon you for your help with this activity. > Would you be > available? > > > _gus: 630-527-4617 > From owner-ibis Thu Jun 15 18:14:51 2000 Received: from smtp.holtek.com.tw ([203.74.180.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA00866 for ; Thu, 15 Jun 2000 18:14:38 -0700 (PDT) Received: from ims.holtek.com.tw (ims.holtek.com.tw [172.26.83.140]) by smtp.holtek.com.tw (8.8.8+Sun/8.8.8) with ESMTP id JAA09105 for ; Fri, 16 Jun 2000 09:11:12 +0800 (CST) Received: by ims.holtek.com.tw with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 09:20:59 +0800 Message-ID: <0193CA87AA27D311AC7E0000E85E1B4AC02F1E@exchsnch.holtek.com.tw> From: =?big5?B?uK2q+KtD?= To: ibis@eda.org Subject: unsubscribe Date: Fri, 16 Jun 2000 09:17:29 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD731.2088A7A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD731.2088A7A0 Content-Type: text/plain; charset="big5" ------_=_NextPart_001_01BFD731.2088A7A0 Content-Type: text/html; charset="big5" unsubscribe ------_=_NextPart_001_01BFD731.2088A7A0-- From owner-ibis Fri Jun 16 02:53:43 2000 Received: from mr2.hi-ho.ne.jp (gem.hi-ho.ne.jp [202.224.159.137]) by server.eda.org (8.8.5/8.8.3) with ESMTP id CAA02153 for ; Fri, 16 Jun 2000 02:53:41 -0700 (PDT) Received: from apsimtech.com (pl047.nas122.s-kawasaki.nttpc.ne.jp [210.165.196.47]) by mr2.hi-ho.ne.jp (Hi-HO Mail Server) with ESMTP id <0FW80055WRDSSZ@mr2.hi-ho.ne.jp> for ibis@eda.org; Fri, 16 Jun 2000 18:51:30 +0900 (JST) Date: Fri, 16 Jun 2000 03:58:58 -0700 From: fred Subject: Re: Connector spec swathing To: apanella@molex.com Cc: ibis@eda.org Message-id: <394A0871.9900EB3@apsimtech.com> MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <0016D115.CE21031@molex.com> You are confusing modeling and simulation. I'm not suggesting that you model the full connector if its large. Rather, if you model only a portion then I prefer that you tell me that and give me that answer rather than bogus something. If you feel that the connector is repetative then put together the model such that I get a full matrix type or sparse matrix. This means I should have representative coupling between any two or three pins as you may feel necessary. But I need the full model. Verification of the model is entirely a different animal and I cannot see how the swat helps with that process at all. IF you give me the full model I may not attempt to simulate the whole thing. You are only giving me information. Its up to me to use that wisely. For example if I choose to simulate through connector pin number 5, I as a user may wish to consider only coupling to pin 7 and pin 3. I can make that decision during simulation coupling setup. The important thing is that I can get decent accurate data for the pins I wish to consider during simulation. If you give me the full model I will then PICK the data I wish to simulate from the full data you gave me. However giving me a swat ensures that for some pins I will lose some coupling. It also ensures confusion and abiguity. Please note that the swat does not help your modeling. It's only a way to present the data. So the issue of modeling the full connector versus giving me a full matrix is a seperate one. We're talking about how to present the data not field solver algorithms. Best Regards, apanella@molex.com wrote: > Fred, > > I am sure that if you have this question, so do others... as such I have > prepared a fairly lengthy reply. > > The "basic" answer to the question is... > > Find a FIELD simulator that can generate a 100 pin connector model from a > connector with a general current path length of around 2.5cm. > > Make sure it is a true 3D simulator. > > OK... now find one that can do such using less than 8GB of RAM and 4 xxxx GHz. > processors > - This is pretty much what one might call a high end PC/Workstation. Maybe > even not "typical" hardware. > > OK... Using what has been found above... have the problem solve in the FIELD > simulator in less than a week. (BTW, a week is solve time, it does not include > reports, empirical confirmation, or support documentation) > > OK... now put that full matrix model that is generated into a circuit > simulator.... Setup the rest of the problem.... go away for the weekend... > comeback Monday.... still not done... Comeback Wednesday... Ooopps found out > that a termination resistor was misplaced... restart the simulation. > > The point is... connector companies would be perfectly happy with smaller > models... > > But from what I have been told my customers which are the same as many SI > simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 pins... (Yes, > these are all real connector sizes today). > > As a work around for this problem.... we suggest the preverbal "critical net > analysis". Which will still take 8 hours to solve using something in the order > of a 40 pin connector model. > > Also, I as a connector manufacture make parts with different circuit sizes... > sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 > models... Lets say we just go up to 100 pins... that is 10 models... at 3 days > AVERAGE per model (smaller models take less time)... that means one month of > FIELD SIMULATION time... and we STILL can not support any thing over 100 pins. > > Not to mention that connector companies have about 40,000 different product > lines.. lets say conservatively that only 1% of the 40,000 require models... > That's 400.... a conservative estimate would be that there are 10 circuit sizes > for each of those 400 connectors... as such 4,000 different models. OF EACH > Type. There are three basic types Single Line models, MultiLine Models, and > Cascaded Models... then there are TWO VERSIONS of each type... distributed and > lumped... grand total 24,000 SPECIFIC models. > > But wait, Now model makers and simulators also have to database and revision > control the models. > > Point being... an auto swath will give end uses access to more models with more > pin options than they ever had before (to answer the customers requests). And > GREATLY reduce the redundancies such that the 24,000 models above can be done in > 1 model per connector family.. or 400 files. > > _gus: 630-527-4617 > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: fred > Date: 6/15/00 1:33 AM > > I know the connector specification committee has spent much time and effort in > comming up with the specification. However the current swat matrix approach > seems overly complicated and technically less than desirable. Why not give the > > full matrix and let the simulation SI tool decide which part of the matrix to > choose > for simulation based on what pin and coupling is desired. We (simulation > vendors) > only need the data. We can decide how and when to use what. What we need is > the committee to do is identify the connector pins to the matrix diagonal > entrys. If > the connector is very large in terms of number of pins then whether one gets a > full > or sparse matrix will depend on the field solver capabilities. This is not > intended to > be critical of the committee which has worked long and hard to come up with a > spec > in the first place while hence keeping everybody happy. > > Best Regards, > > Kellee Crisafulli wrote: > > > Hi Chris, From owner-ibis Fri Jun 16 05:24:48 2000 Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA02673 for ; Fri, 16 Jun 2000 05:24:47 -0700 (PDT) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 08:27:49 -0400 Message-ID: <276737EB1EC5D311AB950090273BEFDD9E4510@elway.lss.emc.com> From: "zanella, fabrizio" To: "'Mikhail Khusid'" , Chris Rokusek Cc: IBIS Mailing list Subject: RE: Re[2]: Connector spec swathing Date: Fri, 16 Jun 2000 08:18:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I agree with Mikhail. I actually push the connector vendors for smaller matrices, for 30X30 connector matrices cause very long run times in HSPICE, even using Ultra 60 Sparcs with 500MB of RAM. It's very unreasonable to expect larger than 30X30 connector LRC matrices. Regards, Fabrizio Zanella Hardware Engineering EMC Corporation 508-435-2075, x14645 FAX: 508-497-8027 fzanella@emc.com -----Original Message----- From: Mikhail Khusid [mailto:Mikhail_Khusid@notes.teradyne.com] Sent: Thursday, June 15, 2000 2:29 PM To: Chris Rokusek Cc: IBIS Mailing list Subject: RE: Re[2]: Connector spec swathing Chris, Whether a connector company can make a full matrix model of a connector depends more on the connector than the tools. In fact, if a connector is complicated enough to warrant several L and C sections, and if a connector has many pins, providing a full matrix model can be very unpractical. As a representative of the connector company where a 570 pin connector is considered a small one, I can assure you that it's impossible for me to generate dozens of 570x570 matrices. Furthermore, I doubt that any simulator will be able to solve a problem with full matrices of that size. Doing a swath method allows me to generate reasonable size matrices, up to 30x30, which should respresent sufficient couplings inside the connector, and thus is an effective way to simulate the connector behavior in reasonable time. Lastly, I agree with Kellee that a standard should probably include a description of a "golden" way to generate a full matrix model out of a swath, however, I would welcome simulator companies attempts to avoid using this method for every connector. Michael Khusid Teradyne Connection Systems http://www.teradyne.com "Chris Rokusek" on 06/15/2000 12:27:55 PM To: "IBIS Mailing list" cc: (bcc: Mikhail Khusid/NNH/Teradyne) Subject: RE: Re[2]: Connector spec swathing Gus, Given that some companies actually do possess the tools to create Full Matrix connectors (& packages) accurately and efficiently and given that simulators MUST come up with algorithms to reduce this full matrix (perhaps efficiently with an accuracy tradeoff), simulator companies are just trying to avoid extra work in having to write two algorithms that do very similar things--one to expand the swath to arbitrary pins and one to reduce the full matrix to arbitrary pins. Many of us prefer to solve the most general/accurate problem first (Full Matrix). I don't think we're saying "don't use the swath", I think all we're saying is provide us with a recommended algorithm (and perhaps build it into the parser) for expanding the swath into a full matrix so that each simulator can potentially get the same answer for the most general case. It seems like that would keep everybody happy. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Thursday, June 15, 2000 4:37 AM > To: fred > Cc: Kellee Crisafulli; IBIS Mailing list > Subject: Re[2]: Connector spec swathing > > > Fred, > > I am sure that if you have this question, so do others... as such I have > prepared a fairly lengthy reply. > > The "basic" answer to the question is... > > Find a FIELD simulator that can generate a 100 pin connector model from a > connector with a general current path length of around 2.5cm. > > Make sure it is a true 3D simulator. > > OK... now find one that can do such using less than 8GB of RAM > and 4 xxxx GHz. > processors > - This is pretty much what one might call a high end > PC/Workstation. Maybe > even not "typical" hardware. > > OK... Using what has been found above... have the problem solve > in the FIELD > simulator in less than a week. (BTW, a week is solve time, it > does not include > reports, empirical confirmation, or support documentation) > > OK... now put that full matrix model that is generated into a circuit > simulator.... Setup the rest of the problem.... go away for the > weekend... > comeback Monday.... still not done... Comeback Wednesday... > Ooopps found out > that a termination resistor was misplaced... restart the simulation. > > > The point is... connector companies would be perfectly happy with smaller > models... > > But from what I have been told my customers which are the same as many SI > simulators NEED to be able to model 50, 100, 200, 500, 1000, 5000 > pins... (Yes, > these are all real connector sizes today). > > > As a work around for this problem.... we suggest the preverbal > "critical net > analysis". Which will still take 8 hours to solve using something > in the order > of a 40 pin connector model. > > Also, I as a connector manufacture make parts with different > circuit sizes... > sometime from 10 to 1000 in 10 pin increments... OK... there we have 100 > models... Lets say we just go up to 100 pins... that is 10 > models... at 3 days > AVERAGE per model (smaller models take less time)... that means > one month of > FIELD SIMULATION time... and we STILL can not support any thing > over 100 pins. > > > Not to mention that connector companies have about 40,000 > different product > lines.. lets say conservatively that only 1% of the 40,000 > require models... > That's 400.... a conservative estimate would be that there are 10 > circuit sizes > for each of those 400 connectors... as such 4,000 different > models. OF EACH > Type. There are three basic types Single Line models, MultiLine > Models, and > Cascaded Models... then there are TWO VERSIONS of each type... > distributed and > lumped... grand total 24,000 SPECIFIC models. > > But wait, Now model makers and simulators also have to database > and revision > control the models. > > Point being... an auto swath will give end uses access to more > models with more > pin options than they ever had before (to answer the customers > requests). And > GREATLY reduce the redundancies such that the 24,000 models above > can be done in > 1 model per connector family.. or 400 files. > > > _gus: 630-527-4617 > > > ____________________Reply Separator____________________ > Subject: Re: Connector spec swathing > Author: fred > Date: 6/15/00 1:33 AM > > I know the connector specification committee has spent much time > and effort in > comming up with the specification. However the current swat > matrix approach > seems overly complicated and technically less than desirable. > Why not give the > > full matrix and let the simulation SI tool decide which part of > the matrix to > choose > for simulation based on what pin and coupling is desired. We (simulation > vendors) > only need the data. We can decide how and when to use what. What > we need is > the committee to do is identify the connector pins to the matrix diagonal > entrys. If > the connector is very large in terms of number of pins then > whether one gets a > full > or sparse matrix will depend on the field solver capabilities. This is not > intended to > be critical of the committee which has worked long and hard to > come up with a > spec > in the first place while hence keeping everybody happy. > > Best Regards, > > Kellee Crisafulli wrote: > > > Hi Chris, > From owner-ibis Fri Jun 16 05:40:25 2000 Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA02743 for ; Fri, 16 Jun 2000 05:40:25 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 17384508FF; Fri, 16 Jun 2000 12:37:49 +0000 (GMT) Received: from ishome.lisle.molex.com ([150.150.15.101]) by molexinc-cp.molex.com; Fri, 16 Jun 2000 08:37:41 +0000 (EST) Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 00011A5C; Fri, 16 Jun 2000 07:34:55 -0500 Mime-Version: 1.0 Date: Fri, 16 Jun 2000 07:30:09 -0500 Message-ID: <00011A5C.C21030@molex.com> Subject: Re[2]: Connector spec swathing To: fred Cc: ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part The swath... allows automatic building of a "banded" matrix from a smaller matrix. The goal of the keywords around the swath are present such that the person that creates the model can give enough information to a simulator to build the banded matrix from the smaller matrix. How does the swath help...??? * Let's say I manufacture a connector line that has 50, 100, 500, 750, 1000 pins in a "5 by X" PHYSICAL configuration. I now need to have 5 models to support this connector line. Instead... with a SWATH, I can create a 50 pin model... then all the other variations can be derived from that model. This is done by using the smallest (50 pin, 5 x 10) matrix to generate a bigger matrix. In this example.... The benefits are as follows *** 1 file instead of five *** The single file only needs about 10 extra lines to cover the 5 combinations *** The single file could just as easily cover 100 combinations (or 100 models) ~~~AN example to show the benefits.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Considering there is somewhere between 10 to 50 connector sizes per connector family and there are at least 100 Connector families per connector company, You might also see how the model database may be easier to manage and update. Original case: 10 to 50 models per family x 100 Connector families yields 1000 to 5000 model files x Lets just say 5 connector companies (we know that there are at least 500 Connector companies out there) yields 5000 to 25000 separate models OK... NOW.. Same example... but SWATHED.. 10 to 50 models per family x 100 Connector families yields 10 to 50 model files x Lets just say 5 connector companies (we know that there are at least 500 Connector companies out there) yields 50 to 250 separate models. Assuming that a banded matrix is correct, I know which option I would rather work with.... ** as a SIMULATOR company (SI Simulation, SPICE or non-SPICE) ** or as a MODEL MAKER (Connector Company) ** or as a MODEL USER (the person who uses the SI Tool and the Connector company models).... The Drawbacks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The draw back to simulators... they need to bang out some code that creates a matrix from a small matrix as limited by the keywords. From what I have been told, this is not very difficult The draw back to Connector companies. We need to make sure we appropriately use the supplied swath keywords The drawback to Connector Company Customers and Simulator Company Customers... ????? _gus: 630-527-4617 ____________________Reply Separator____________________ Subject: Re: Connector spec swathing Author: fred Date: 6/16/00 3:58 AM You are confusing modeling and simulation. I'm not suggesting that you model the full connector if its large. Rather, if you model only a portion then I prefer that you tell me that and give me that answer rather than bogus something. If you feel that the connector is repetative then put together the model such that I get a full matrix type or sparse matrix. This means I should have representative coupling between any two or three pins as you may feel necessary. But I need the full model. Verification of the model is entirely a different animal and I cannot see how the swat helps with that process at all. IF you give me the full model I may not attempt to simulate the whole thing. You are only giving me information. Its up to me to use that wisely. For example if I choose to simulate through connector pin number 5, I as a user may wish to consider only coupling to pin 7 and pin 3. I can make that decision during simulation coupling setup. The important thing is that I can get decent accurate data for the pins I wish to consider during simulation. If you give me the full model I will then PICK the data I wish to simulate from the full data you gave me. However giving me a swat ensures that for some pins I will lose some coupling. It also ensures confusion and abiguity. Please note that the swat does not help your modeling. It's only a way to present the data. So the issue of modeling the full connector versus giving me a full matrix is a seperate one. We're talking about how to present the data not field solver algorithms. Best Regards, From owner-ibis Fri Jun 16 09:56:35 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA03589 for ; Fri, 16 Jun 2000 09:56:34 -0700 (PDT) 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 MAA26564 for ; Fri, 16 Jun 2000 12:53:59 -0400 (EDT) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA23754 for ; Fri, 16 Jun 2000 12:53:58 -0400 (EDT) Received: from pcchrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id JAA26862 for ; Fri, 16 Jun 2000 09:53:52 -0700 (PDT) From: "Chris Rokusek" To: Subject: RE: Re[2]: Connector spec swathing Date: Fri, 16 Jun 2000 09:58:27 -0700 Message-ID: <001701bfd7b4$1724b530$aac2b58b@camarillo.viewlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <00011A5C.C21030@molex.com> Gus, (Hoping we are one step towards closure!!) You wrote... > The draw back to simulators... they need to bang out some code that creates a > matrix from a small matrix as limited by the keywords. From what I have been > told, this is not very difficult This is the procedure I (and Fred?) are concerned about. It may not be difficult but it sure seems ambiguous for cases not covered by Bob's posting. If this mapping is described in detail or implemented within the parser then I believe we will all be happy. The data files contain swaths but we can query against a full matrix--which doesn't mean we're going to SIMULATE the full matrix it just means we can reduce it to the pins we're interested in. Fred is right--there is confusion between on this thread between data presentation and simulation. Just because we want a full matrix doesn't mean we're going to SIMULATE a full matrix. Fred is also NOT saying "don't use the swath." Perhaps the confusion is that you think we're saying that the Full Matrix should be explicitly described in the file. No, we're saying USE the swath, but define the expansion rigorously or build it into the parser. When we say we want the Full Matrix, we're NOT saying it should be spelled out explicitly in the file--we're saying we must be able to perform the swath mapping correctly for all possible cases. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Friday, June 16, 2000 5:30 AM > To: fred > Cc: ibis@eda.org > Subject: Re[2]: Connector spec swathing > > > > > The swath... allows automatic building of a "banded" matrix from a smaller > matrix. > > The goal of the keywords around the swath are present such that > the person that > creates the model can give enough information to a simulator to > build the banded > matrix from the smaller matrix. > > How does the swath help...??? > > * Let's say I manufacture a connector line that has 50, 100, > 500, 750, 1000 > pins in a "5 by X" PHYSICAL configuration. I now need to have 5 models to > support this connector line. Instead... with a SWATH, I can > create a 50 pin > model... then all the other variations can be derived from that > model. This is > done by using the smallest (50 pin, 5 x 10) matrix to generate a > bigger matrix. > > In this example.... The benefits are as follows > *** 1 file instead of five > *** The single file only needs about 10 extra lines to cover the > 5 combinations > *** The single file could just as easily cover 100 combinations > (or 100 models) > > > ~~~AN example to show the benefits.. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Considering there is somewhere between 10 to 50 connector sizes > per connector > family and there are at least 100 Connector families per > connector company, You > might also see how the model database may be easier to manage and update. > > Original case: > 10 to 50 models per family x 100 Connector families > > yields 1000 to 5000 model files x Lets just say 5 connector > companies (we > know that there are at least 500 Connector companies out there) > > yields 5000 to 25000 separate models > > > OK... NOW.. Same example... but SWATHED.. > > 10 to 50 models per family x 100 Connector families > > yields 10 to 50 model files x Lets just say 5 connector > companies (we know > that there are at least 500 Connector companies out there) > > yields 50 to 250 separate models. > > > Assuming that a banded matrix is correct, I know which option I > would rather > work with.... > ** as a SIMULATOR company (SI Simulation, SPICE or non-SPICE) > ** or as a MODEL MAKER (Connector Company) > ** or as a MODEL USER (the person who uses the SI Tool and the > Connector company > models).... > > > > The Drawbacks > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The draw back to simulators... they need to bang out some code > that creates a > matrix from a small matrix as limited by the keywords. From what > I have been > told, this is not very difficult > > The draw back to Connector companies. > We need to make sure we appropriately use the supplied swath keywords > > The drawback to Connector Company Customers and Simulator Company > Customers... > ????? > > > _gus: 630-527-4617 From owner-ibis Fri Jun 16 12:24:38 2000 Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA04022 for ; Fri, 16 Jun 2000 12:24:38 -0700 (PDT) From: apanella@molex.com Received: from molexinc-cp.molex.com (molexinc-cp.molex.com [204.167.149.71]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 8AEAD516FA for ; Fri, 16 Jun 2000 19:21:54 +0000 (GMT) Received: from ishome.lisle.molex.com ([150.150.15.101]) by molexinc-cp.molex.com; Fri, 16 Jun 2000 15:21:48 +0000 (EST) Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 00011DD6; Fri, 16 Jun 2000 14:17:56 -0500 Mime-Version: 1.0 Date: Fri, 16 Jun 2000 14:11:55 -0500 Message-ID: <00011DD6.C21030@molex.com> Subject: Connector spec swathing.. to the Subcommittee meeting. To: ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Chris.. I 've read ... reread... and reread Fred's message... The only thing I see is references to providing a "full matrix" Quoting the Fred's messages: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Why not give the full matrix and let the simulation SI tool decide which part of the matrix to choose for simulation based on what pin and coupling is desired." "I'm not suggesting that you model the full connector if its large. Rather, if you model only a portion then I prefer that you tell me that and give me that answer rather than bogus something." "If you feel that the connector is repetitive then put together the model such that I get a full matrix type or sparse matrix." " If you give me the full model I will then PICK the data I wish to simulate from the full data you gave me. However giving me a swat ensures that for some pins I will lose some coupling. It also ensures confusion and abiguity." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To me this sounds like "No Swath..". !!!!! I apologize to all if I incorrectly interpreted these statements and wasted a lot of bandwidth describing the potential (maybe not apparent) advantages of the swath concept!!!! ALSO IMPORTANT: Chris, Since your first message... I understood that you just want a defined an algorithm for doing the swath... In the "for what it is worth" category.... Right now, the specification is written such that a specific model could be a "full matrix" OR "swath". .... (And for what it is worth... there is nothing stating that a model must contain one or the other or both... nor is there anything that states that a simulator needs to support one or the other or both.). I will make sure that our next IBIS Connector Model Subcommittee that we resolve the issue of the "level of detail" that is needed for the swath algorithm. I understand both sides of the argument on whether or not to include a specific swath algorithm. I think some people want to leave the algorithm "more" open... while others want the algorithm "more defined". As such, I think our options are: a) Keep the definition as it is... (i.e. OPEN) b) Provide a "TYPICAL" algorithm c) Provide a "RECOMMENDED" algorithm d) provide a "SPECIFIC" algorithm e) REMOVE swath. I would guess that most of the people concerned want "c" or "d". I am happy with a, b, c, or d.... but think "b or above" is a pretty good idea. At this point, I think most of us believe that "e" is unacceptable. I would encourage any one who really wants "d" to provide a "first pass" example as soon as possible such that we can start the review and incorporation process. As I know the present keywords and methodology, I would be willing to commit time to help with the development. I can be contacted directly at: 630-527-4617 .... for any further discussions. _gus: ___________Reply Separator____________________ Subject: RE: Re[2]: Connector spec swathing Author: "Chris Rokusek" Date: 6/16/00 9:58 AM Gus, (Hoping we are one step towards closure!!) You wrote... > The draw back to simulators... they need to bang out some code that creates a > matrix from a small matrix as limited by the keywords. From what I have been > told, this is not very difficult This is the procedure I (and Fred?) are concerned about. It may not be difficult but it sure seems ambiguous for cases not covered by Bob's posting. If this mapping is described in detail or implemented within the parser then I believe we will all be happy. The data files contain swaths but we can query against a full matrix--which doesn't mean we're going to SIMULATE the full matrix it just means we can reduce it to the pins we're interested in. Fred is right--there is confusion between on this thread between data presentation and simulation. Just because we want a full matrix doesn't mean we're going to SIMULATE a full matrix. Fred is also NOT saying "don't use the swath." Perhaps the confusion is that you think we're saying that the Full Matrix should be explicitly described in the file. No, we're saying USE the swath, but define the expansion rigorously or build it into the parser. When we say we want the Full Matrix, we're NOT saying it should be spelled out explicitly in the file--we're saying we must be able to perform the swath mapping correctly for all possible cases. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [mailto:apanella@molex.com] > Sent: Friday, June 16, 2000 5:30 AM > To: fred > Cc: ibis@eda.org > Subject: Re[2]: Connector spec swathing > >SNIP> From owner-ibis Mon Jun 19 00:11:37 2000 Received: from mahe.dev.decision.fr ([194.149.167.167]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA13450 for ; Mon, 19 Jun 2000 00:11:31 -0700 (PDT) Received: from xcell.com (maxime.com.decision.fr [192.168.2.32]) by mahe.dev.decision.fr (8.9.1/8.9.1) with ESMTP id JAA00784 for ; Mon, 19 Jun 2000 09:10:02 +0200 Message-ID: <394DC74A.6FF6020A@xcell.com> Date: Mon, 19 Jun 2000 09:10:02 +0200 From: jean francois sourisseau Organization: DECISION Europe X-Mailer: Mozilla 4.5 [fr] (Win95; I) X-Accept-Language: fr MIME-Version: 1.0 To: ibis@eda.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From owner-ibis Mon Jun 19 07:18:48 2000 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA14855 for ; Mon, 19 Jun 2000 07:18:48 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.8.8/8.6.11) id HAA11096 for ; Mon, 19 Jun 2000 07:16:40 -0700 (PDT) Received: from nsc.nsc.com(139.187.81.1) by natsemi-bh.nsc.com via smap (4.1) id xma010773; Mon, 19 Jun 00 07:15:35 -0700 Received: from taux01.nsc.com (taux01.nsc.com [139.187.251.4]) by nsc.nsc.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15930 for ; Mon, 19 Jun 2000 07:15:00 -0700 (PDT) Received: from taux01.nsc.com (tasu41 [139.187.237.36]) by taux01.nsc.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA07909 for ; Mon, 19 Jun 2000 17:14:15 +0300 (IDT) Sender: idanra@taux01.nsc.com Message-ID: <394E2AB8.8ADDD462@taux01.nsc.com> Date: Mon, 19 Jun 2000 17:14:17 +0300 From: Idan Rahat Organization: NSTA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From owner-ibis Mon Jun 19 10:25:54 2000 Received: from mail-dns1-nj.dialogic.com (mail-dns1-nj.dialogic.com [146.152.228.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA15914 for ; Mon, 19 Jun 2000 10:25:53 -0700 (PDT) Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id RAA13548 for ; Mon, 19 Jun 2000 17:26:02 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19360 for ; Mon, 19 Jun 2000 13:23:14 -0400 (EDT) Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 13:23:05 -0400 Message-ID: <6B0F0A1F0F44D1118BB000A024620EB5024A3D47@exchange2nj.dialogic.com> From: "Gerbehy, Jay" To: "'ibis@eda.org'" Subject: ibis2spice template.mdl for HSPICE Date: Mon, 19 Jun 2000 13:23:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Looking for an HSPICE template file for Intusoft's ibis2spice converter. Thanks Jay Gerbehy gerbehyj@dialogic.com From owner-ibis Mon Jun 19 11:03:45 2000 Received: from InterJet.apsimtech.com (appliedsim-sdsl784k-gw.mv.best.net [206.184.220.92]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA16168 for ; Mon, 19 Jun 2000 11:03:44 -0700 (PDT) Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id KAA06262; Mon, 19 Jun 2000 10:56:02 -0700 (PDT) Received: from apsim3.apsimtech.com(192.168.1.103), claiming to be "apsimtech.com" via SMTP by InterJet.apsimtech.com, id smtpd006260; Mon Jun 19 17:56:00 2000 Sender: fred@apsimtech.com Message-ID: <394E5D24.5325AFC9@apsimtech.com> Date: Mon, 19 Jun 2000 10:49:24 -0700 From: Fred Balistreri Organization: Apsim X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: apanella@molex.com CC: ibis@eda.org Subject: Re: Connector spec swathing.. to the Subcommittee meeting. References: <00011DD6.C21030@molex.com> Content-Type: multipart/alternative; boundary="------------8039B71349378CBD9EBBE905" --------------8039B71349378CBD9EBBE905 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The preference for me is c or d. This is not a vote just an opinion. Best Regards, apanella@molex.com wrote: > Chris.. > > I 've read ... reread... and reread Fred's message... > The only thing I see is references to providing a "full matrix" > > Quoting the Fred's messages: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Why not give the full matrix and let the simulation SI tool decide which part > of the matrix to choose for simulation based on what pin and coupling is > desired." > > "I'm not suggesting that you model the full connector if its large. Rather, if > you model only a portion then I prefer that you tell me that and give me that > answer rather than bogus something." > > "If you feel that the connector is repetitive then put together the model such > that I get a full matrix type or sparse matrix." > > " If you give me the full model I will then PICK the data I wish to simulate > from the full data you gave me. However giving me a swat > ensures that for some pins I will lose some coupling. It also ensures confusion > and abiguity." > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > To me this sounds like "No Swath..". > > !!!!! I apologize to all if I incorrectly interpreted these statements and > wasted a lot of bandwidth describing the potential (maybe not apparent) > advantages of the swath concept!!!! > > ALSO IMPORTANT: > Chris, Since your first message... I understood that you just want a defined > an algorithm for doing the swath... > > In the "for what it is worth" category.... > Right now, the specification is written such that a specific model could be a > "full matrix" OR "swath". .... (And for what it is worth... there is nothing > stating that a model must contain one or the other or both... nor is there > anything that states that a simulator needs to support one or the other or > both.). > > I will make sure that our next IBIS Connector Model Subcommittee that we resolve > the issue of the "level of detail" that is needed for the swath algorithm. > > I understand both sides of the argument on whether or not to include a specific > swath algorithm. I think some people want to leave the algorithm "more" > open... while others want the algorithm "more defined". > As such, I think our options are: > > a) Keep the definition as it is... (i.e. OPEN) > b) Provide a "TYPICAL" algorithm > c) Provide a "RECOMMENDED" algorithm > d) provide a "SPECIFIC" algorithm > e) REMOVE swath. > > I would guess that most of the people concerned want "c" or "d". I am happy > with a, b, c, or d.... but think "b or above" is a pretty good idea. > At this point, I think most of us believe that "e" is unacceptable. > > I would encourage any one who really wants "d" to provide a "first pass" example > as soon as possible such that we can start the review and incorporation process. > As I know the present keywords and methodology, I would be willing to commit > time to help with the development. > > I can be contacted directly at: > 630-527-4617 > .... for any further discussions. > > _gus: > > ___________Reply Separator____________________ > Subject: RE: Re[2]: Connector spec swathing > Author: "Chris Rokusek" > Date: 6/16/00 9:58 AM > > Gus, > > (Hoping we are one step towards closure!!) > > You wrote... > > > The draw back to simulators... they need to bang out some code that > creates a > > matrix from a small matrix as limited by the keywords. From what I have > been > > told, this is not very difficult > > This is the procedure I (and Fred?) are concerned about. It may not be > difficult but it sure seems ambiguous for cases not covered by Bob's > posting. If this mapping is described in detail or implemented within the > parser then I believe we will all be happy. The data files contain swaths > but we can query against a full matrix--which doesn't mean we're going to > SIMULATE the full matrix it just means we can reduce it to the pins we're > interested in. Fred is right--there is confusion between on this thread > between data presentation and simulation. Just because we want a full > matrix doesn't mean we're going to SIMULATE a full matrix. > > Fred is also NOT saying "don't use the swath." > > Perhaps the confusion is that you think we're saying that the Full Matrix > should be explicitly described in the file. No, we're saying USE the swath, > but define the expansion rigorously or build it into the parser. When we > say we want the Full Matrix, we're NOT saying it should be spelled out > explicitly in the file--we're saying we must be able to perform the swath > mapping correctly for all possible cases. > > Chris Rokusek > Innoveda > > > -----Original Message----- > > From: apanella@molex.com [mailto:apanella@molex.com] > > Sent: Friday, June 16, 2000 5:30 AM > > To: fred > > Cc: ibis@eda.org > > Subject: Re[2]: Connector spec swathing > > > >SNIP> -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com --------------8039B71349378CBD9EBBE905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The preference for me is c or d.  This is not a vote just an opinion.

Best Regards,

apanella@molex.com wrote:

Chris..

I 've read ... reread... and reread Fred's message...
The only thing I see is references to providing a "full matrix"

Quoting the Fred's messages:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Why not give the full matrix and let the simulation SI tool decide which part
of the matrix to choose for simulation based on what pin and coupling is
desired."

"I'm not suggesting that you model the full connector if its large. Rather, if
you model only a portion then I prefer that you tell me that and give me that
answer rather than bogus something."

"If you feel that the connector is repetitive then put together the model such
that I get a full matrix type or sparse matrix."

" If you give me the full model I will then PICK the data I wish to simulate
from the full data you gave me.  However giving me a swat
ensures that for some pins I will lose some coupling.  It also ensures confusion
and abiguity."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To me this sounds like "No Swath..".

!!!!! I apologize to all if I incorrectly interpreted these statements and
wasted a lot of bandwidth describing the potential  (maybe not apparent)
advantages of the swath concept!!!!

ALSO IMPORTANT:
Chris,  Since your first message...  I understood that you just want a defined
an algorithm for doing the swath...

In the "for what it is worth" category....
Right now, the specification is written such that a specific model could be a
"full matrix" OR "swath".  .... (And for what it is worth... there is nothing
stating that a model must contain one or the other or both... nor is there
anything that states that a simulator needs to support one or the other or
both.).

I will make sure that our next IBIS Connector Model Subcommittee that we resolve
the issue of the "level of detail" that is needed for the swath algorithm.

I understand both sides of the argument on whether or not to include a specific
swath algorithm.   I think some people want to leave the algorithm "more"
open... while others want the algorithm "more defined".
As such, I think our options are:

a) Keep the definition as it is...  (i.e. OPEN)
b) Provide a "TYPICAL" algorithm
c) Provide a  "RECOMMENDED" algorithm
d) provide a "SPECIFIC" algorithm
e) REMOVE swath.

I would guess that most of the people concerned want "c" or "d".  I am happy
with a, b, c, or d.... but think "b or above" is a pretty good idea.
At this point, I think most of us believe that "e" is unacceptable.

I would encourage any one who really wants "d" to provide a "first pass" example
as soon as possible such that we can start the review and incorporation process.
 As I know the present keywords and methodology, I would be willing to commit
time to  help  with the development.

I can be contacted directly at:
630-527-4617
           ....  for any further discussions.

_gus:

___________Reply Separator____________________
Subject:    RE: Re[2]: Connector spec swathing
Author: "Chris Rokusek" <crokusek@innoveda.com>
Date:       6/16/00 9:58 AM

Gus,

(Hoping we are one step towards closure!!)

You wrote...

> The draw back to simulators... they need to bang out some code that
creates a
> matrix from a small matrix as limited by the keywords.  From what I have
been
> told,  this is not very difficult

This is the procedure I (and Fred?) are concerned about.  It may not be
difficult but it sure seems ambiguous for cases not covered by Bob's
posting.  If this mapping is described in detail or implemented within the
parser then I believe we will all be happy.  The data files contain swaths
but we can query against a full matrix--which doesn't mean we're going to
SIMULATE the full matrix it just means we can reduce it to the pins we're
interested in.  Fred is right--there is confusion between on this thread
between data presentation and simulation.  Just because we want a full
matrix doesn't mean we're going to SIMULATE a full matrix.

Fred is also NOT saying "don't use the swath."

Perhaps the confusion is that you think we're saying that the Full Matrix
should be explicitly described in the file.  No, we're saying USE the swath,
but define the expansion rigorously or build it into the parser.  When we
say we want the Full Matrix, we're NOT saying it should be spelled out
explicitly in the file--we're saying we must be able to perform the swath
mapping correctly for all possible cases.

Chris Rokusek
Innoveda

> -----Original Message-----
> From: apanella@molex.com [mailto:apanella@molex.com]
> Sent: Friday, June 16, 2000 5:30 AM
> To: fred
> Cc: ibis@eda.org
> Subject: Re[2]: Connector spec swathing
>
>SNIP>

-- 
Fred Balistreri
fred@apsimtech.com

http://www.apsimtech.com
  --------------8039B71349378CBD9EBBE905-- From owner-ibis Mon Jun 19 12:25:30 2000 Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA16476 for ; Mon, 19 Jun 2000 12:25:29 -0700 (PDT) From: kulwant.brar@philips.com Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id VAA19333 for ; Mon, 19 Jun 2000 21:23:21 +0200 (MEST) (envelope-from kulwant.brar@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma019331; Mon, 19 Jun 00 21:23:21 +0200 Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id VAA03837 for ; Mon, 19 Jun 2000 21:23:20 +0200 (MET DST) Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via AMEC id 0056910005609728; Mon, 19 Jun 2000 14:21:58 -0500 To: Subject: UNSUBSCRIBE Message-ID: <0056910005609728000002L182*@MHS> Date: Mon, 19 Jun 2000 14:21:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 06/19/00 14:23:01" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id MAA16477 UNSUBSCRIBE From owner-ibis Mon Jun 19 12:29:38 2000 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA16488 for ; Mon, 19 Jun 2000 12:29:37 -0700 (PDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id MAA21091 for ; Mon, 19 Jun 2000 12:27:31 -0700 (PDT) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 19 Jun 2000 19:27:31 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 12:27:29 -0700 Message-ID: <0F48E339D693D211AC4100A0C95D875902B0B596@fmsmsx69.fm.intel.com> From: "Anderson, Robert G" To: ibis@eda.org Subject: UNSUBSCRIBE Date: Mon, 19 Jun 2000 12:27:26 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" UNSUBSCRIBE - From owner-ibis Mon Jun 19 14:40:53 2000 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA16823 for ; Mon, 19 Jun 2000 14:40:52 -0700 (PDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id OAA26439; Mon, 19 Jun 2000 14:38:20 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 19 Jun 2000 21:38:19 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 14:38:17 -0700 Message-ID: <0F48E339D693D211AC4100A0C95D875902B0B595@fmsmsx69.fm.intel.com> From: "Anderson, Robert G" To: "'Fred Balistreri'" , apanella@molex.com Cc: ibis@eda.org Subject: RE: Connector spec swathing.. to the Subcommittee meeting. Date: Mon, 19 Jun 2000 12:24:31 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Can someone please tell me how to unsubscribe from this list, properly? I've been unsuccessful on 3 tries. Regards, Robert -----Original Message----- From: Fred Balistreri [mailto:fred@apsimtech.com] Sent: Monday, June 19, 2000 10:49 AM To: apanella@molex.com Cc: ibis@eda.org Subject: Re: Connector spec swathing.. to the Subcommittee meeting. The preference for me is c or d. This is not a vote just an opinion. Best Regards, apanella@molex.com wrote: Chris.. I 've read ... reread... and reread Fred's message... The only thing I see is references to providing a "full matrix" Quoting the Fred's messages: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Why not give the full matrix and let the simulation SI tool decide which part of the matrix to choose for simulation based on what pin and coupling is desired." "I'm not suggesting that you model the full connector if its large. Rather, if you model only a portion then I prefer that you tell me that and give me that answer rather than bogus something." "If you feel that the connector is repetitive then put together the model such that I get a full matrix type or sparse matrix." " If you give me the full model I will then PICK the data I wish to simulate from the full data you gave me. However giving me a swat ensures that for some pins I will lose some coupling. It also ensures confusion and abiguity." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To me this sounds like "No Swath..". !!!!! I apologize to all if I incorrectly interpreted these statements and wasted a lot of bandwidth describing the potential (maybe not apparent) advantages of the swath concept!!!! ALSO IMPORTANT: Chris, Since your first message... I understood that you just want a defined an algorithm for doing the swath... In the "for what it is worth" category.... Right now, the specification is written such that a specific model could be a "full matrix" OR "swath". .... (And for what it is worth... there is nothing stating that a model must contain one or the other or both... nor is there anything that states that a simulator needs to support one or the other or both.). I will make sure that our next IBIS Connector Model Subcommittee that we resolve the issue of the "level of detail" that is needed for the swath algorithm. I understand both sides of the argument on whether or not to include a specific swath algorithm. I think some people want to leave the algorithm "more" open... while others want the algorithm "more defined". As such, I think our options are: a) Keep the definition as it is... (i.e. OPEN) b) Provide a "TYPICAL" algorithm c) Provide a "RECOMMENDED" algorithm d) provide a "SPECIFIC" algorithm e) REMOVE swath. I would guess that most of the people concerned want "c" or "d". I am happy with a, b, c, or d.... but think "b or above" is a pretty good idea. At this point, I think most of us believe that "e" is unacceptable. I would encourage any one who really wants "d" to provide a "first pass" example as soon as possible such that we can start the review and incorporation process. As I know the present keywords and methodology, I would be willing to commit time to help with the development. I can be contacted directly at: 630-527-4617 .... for any further discussions. _gus: ___________Reply Separator____________________ Subject: RE: Re[2]: Connector spec swathing Author: "Chris Rokusek" Date: 6/16/00 9:58 AM Gus, (Hoping we are one step towards closure!!) You wrote... > The draw back to simulators... they need to bang out some code that creates a > matrix from a small matrix as limited by the keywords. From what I have been > told, this is not very difficult This is the procedure I (and Fred?) are concerned about. It may not be difficult but it sure seems ambiguous for cases not covered by Bob's posting. If this mapping is described in detail or implemented within the parser then I believe we will all be happy. The data files contain swaths but we can query against a full matrix--which doesn't mean we're going to SIMULATE the full matrix it just means we can reduce it to the pins we're interested in. Fred is right--there is confusion between on this thread between data presentation and simulation. Just because we want a full matrix doesn't mean we're going to SIMULATE a full matrix. Fred is also NOT saying "don't use the swath." Perhaps the confusion is that you think we're saying that the Full Matrix should be explicitly described in the file. No, we're saying USE the swath, but define the expansion rigorously or build it into the parser. When we say we want the Full Matrix, we're NOT saying it should be spelled out explicitly in the file--we're saying we must be able to perform the swath mapping correctly for all possible cases. Chris Rokusek Innoveda > -----Original Message----- > From: apanella@molex.com [ mailto:apanella@molex.com ] > Sent: Friday, June 16, 2000 5:30 AM > To: fred > Cc: ibis@eda.org > Subject: Re[2]: Connector spec swathing > >SNIP> -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Mon Jun 19 17:25:51 2000 Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA17210 for ; Mon, 19 Jun 2000 17:25:51 -0700 (PDT) Received: from cisco.com (dhcp-171-69-57-34.cisco.com [171.69.57.34]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA22306 for ; Mon, 19 Jun 2000 17:23:16 -0700 (PDT) Message-ID: <394EB98A.35A3719F@cisco.com> Date: Mon, 19 Jun 2000 17:23:38 -0700 From: Ajit Kulkarni Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: unscubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe akulkarn@cisco.com From owner-ibis Tue Jun 20 06:47:12 2000 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA20088 for ; Tue, 20 Jun 2000 06:47:11 -0700 (PDT) From: BIong@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 09:45:46 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF0B6601@panda.chrysalis-its.com> To: ibis@eda.org Subject: ibis model formatting Date: Tue, 20 Jun 2000 09:45:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDABD.D5A6C014" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDABD.D5A6C014 Content-Type: text/plain; charset="iso-8859-1" Hi, I'm new to this website. The reason I came across to this site is because I was looking for a tool to convert my current model created in Spice to ibis. Does anyone out there know how to do it or have a model of this device (StrongARM Processor SA110 by Digital now owned by Intel) in ibis format. Thanks for posting my question to the others. Regards Benjamin Iong Hardware Engineer Chrysalis-ITS Inc. Fax: (613) 723-5069 Tel: (613) 723-5076 ext.410 biong@chrysalis-its.com ------_=_NextPart_001_01BFDABD.D5A6C014 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ibis model formatting

Hi, I'm new to this = website. The reason I came across to this site is because I was looking = for a tool to convert my current model created in Spice to ibis. Does = anyone out there know how to do it or have a model of this device = (StrongARM Processor SA110 by Digital now owned by Intel) in ibis = format.

Thanks for posting my = question to the others.

Regards

 Benjamin Iong
 Hardware Engineer
 Chrysalis-ITS Inc.
 Fax: (613) 723-5069
 Tel:  (613) 723-5076 ext.410
 biong@chrysalis-its.com

------_=_NextPart_001_01BFDABD.D5A6C014-- From owner-ibis Tue Jun 20 08:51:46 2000 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA20735 for ; Tue, 20 Jun 2000 08:51:46 -0700 (PDT) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id IAA05313; Tue, 20 Jun 2000 08:49:10 -0700 (PDT) Message-Id: <200006201549.IAA05313@jasper.cisco.com> Date: Tue, 20 Jun 2000 08:49:10 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: Re: ibis model formatting To: ibis@eda.org, BIong@chrysalis-its.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KbV0FVeKVnqkJyahosPn4Q== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc For Spice-to-IBIS conversion: 1) Go to www.eia.org/eig/ibis/ibis.htm 2) Select 'FREE Tools' 3) Download s2ibis2 and also the s2ibis2_fix version. Executables are available for various OS and platforms. The documentations in /doc and examples under /examples dir explains how the conversion can be done. If you have specific questions, you can post them on this reflector. Regards, Syed Cisco Systems, Inc > From: BIong@chrysalis-its.com > To: ibis@eda.org > Subject: ibis model formatting > Date: Tue, 20 Jun 2000 09:45:32 -0400 > MIME-Version: 1.0 > X-SMTP-HELO: server.eda.org > X-SMTP-MAIL-FROM: owner-ibis@server.eda.org > X-SMAP-Received-From: outside > X-SMTP-PEER-INFO: server.eda.org [171.64.101.101] > > Hi, I'm new to this website. The reason I came across to this site is > because I was looking for a tool to convert my current model created in > Spice to ibis. Does anyone out there know how to do it or have a model of > this device (StrongARM Processor SA110 by Digital now owned by Intel) in > ibis format. > > Thanks for posting my question to the others. > > Regards > > Benjamin Iong > Hardware Engineer > Chrysalis-ITS Inc. > Fax: (613) 723-5069 > Tel: (613) 723-5076 ext.410 > biong@chrysalis-its.com > From owner-ibis Tue Jun 20 09:11:01 2000 Received: from lightyear.aud.alcatel.com (lightyear.tpd.usa.alcatel.com [143.209.138.43]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA20805 for ; Tue, 20 Jun 2000 09:10:56 -0700 (PDT) Received: from perseus.aud.alcatel.com by lightyear.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA11706; Tue, 20 Jun 2000 11:09:00 -0500 (CDT) Received: from aud.alcatel.com (perseus [128.251.240.197]) by perseus.aud.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id LAA23395 for ; Tue, 20 Jun 2000 11:08:21 -0500 (CDT) Sender: Hitendra.Patel@aud.alcatel.com Message-ID: <394F96F4.5A2C9C8D@aud.alcatel.com> Date: Tue, 20 Jun 2000 11:08:20 -0500 From: Hitendra R Patel Organization: Alcatel USA, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: UNSUBSCRIBE References: <0056910005609728000002L182*@MHS> Content-Type: multipart/mixed; boundary="------------1B1CCEF5A519DAA84F08DB29" This is a multi-part message in MIME format. --------------1B1CCEF5A519DAA84F08DB29 Content-Type: multipart/alternative; boundary="------------271E844BC37191B768CBAAEA" --------------271E844BC37191B768CBAAEA Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit UNSUBSCRIBE -- Regards, Hitendra :~) (972)996-2909 --------------271E844BC37191B768CBAAEA Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit 
UNSUBSCRIBE



-- 
Regards,
Hitendra :~)
(972)996-2909

 



--------------271E844BC37191B768CBAAEA--

--------------1B1CCEF5A519DAA84F08DB29
Content-Type: text/x-vcard; charset=EUC-KR;
 name="patehr.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Hitendra R Patel
Content-Disposition: attachment;
 filename="patehr.vcf"

begin:vcard 
n:Patel;Hitendra
tel;fax:(972) 996-7119
tel;work:(972) 996-2909
x-mozilla-html:FALSE
org:ALCATEL NETWORK SYSTEMS;Optical Gateway Products
version:2.1
email;internet:patehr@aud.alcatel.com
title:TSM/Hardware Engineer
adr;quoted-printable:;;1225 N. ALMA RD.=0D=0A;RICHARDSON;TEXAS;75081;
x-mozilla-cpt:;-23440
fn:Hitendra Patel
end:vcard

--------------1B1CCEF5A519DAA84F08DB29--

From owner-ibis  Tue Jun 20 16:48:40 2000
Received: from bm0-0.e-dialog.com (root@bm0-0.e-dialog.com [64.28.75.167]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA23096 for ; Tue, 20 Jun 2000 16:48:40 -0700 (PDT)
Received: from e-dialog.com (mf0-s0.e-dialog.com [10.200.3.110])
	by bm0-0.e-dialog.com (8.9.3/8.8.7) with SMTP id TAA09213
	for ibis@vhdl.org; Tue, 20 Jun 2000 19:46:33 -0400
Date: Tue, 20 Jun 2000 19:46:33 -0400
Message-Id: <200006202346.TAA09213@bm0-0.e-dialog.com>
Content-Type: multipart/alternative; boundary="-_-_-_-_-_1234567890"
Content-Transfer-Encoding: binary
Mime-Version: 1.0
From: "TestMart" 
To: ibis@vhdl.org
Subject: test equipment online
X-Mailer: EDMAIL 5.02.00
X-Types: 010

This is a multi-part message in MIME format...

---_-_-_-_-_1234567890
Content-Type: text/plain
Content-Disposition: inline

TEST EQUIPMENT ONLINE

Research and compare general-purpose test equipment 
from popular manufacturers on one neutral site.  
Compare detailed product specs and prices side-by-side, 
then buy, sell, rent or lease equipment on the Web, 24/7, 
at TestMart. 
http://www.testmart.com/estore/productstmp.cfm?33.

TestMart is free.  Visit and gain access to product specs, 
reference directories, equipment prices, and secure online 
commerce. Buy, lease or rent new, pre-owned and refurbished 
test and measurement equipment.

SITE FEATURES:
* DETAILED specifications on 15,000 products 
  in over 120 categories
* UNBIASED product data for hundreds of 
  manufactures on one site
* Powerful SEARCH and COMPARE capabilities
* SECURE online commerce
* NEWS and analysis of trends in the T&M 
  industry

Click on over today and find what youve been missing: 
http://www.testmart.com/index.cfm?33  

Register and be eligible to win an Atomic Clock.

Phone: (888) 665-2765
e-mail: info@TestMart.com mailto:info@TestMart.com

____________________________________________________ 
For the first time ever DESIGN, MFG, AND RESEARCH ENGINEERS
& SCIENTISTS will be able to share important product and 
service information available over the internet.  To remove 
your name from the list, reply to this email with REMOVE in 
the subject fie

[[15639]]


---_-_-_-_-_1234567890--
From owner-ibis  Wed Jun 21 15:46:14 2000
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA28819 for ; Wed, 21 Jun 2000 15:46:14 -0700 (PDT)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id PAA07913; Wed, 21 Jun 2000 15:43:36 -0700 (PDT)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id PAA08577; Wed, 21 Jun 2000 15:43:35 -0700 (PDT)
Sender: bob_ross@mentorg.com
Message-ID: <39514517.7EB84E6@mentor.com>
Date: Wed, 21 Jun 2000 15:43:35 -0700
From: Bob Ross 
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org
CC: bob_ross@mentorg.com
Subject: IBIS Bugs 41-44 for IBISCHK3.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

BUGS 41 - 44 may be discussed at the IBIS Meeting on
June 30, 2000.  Per discussion at the May 26, 2000
meeting BUGs 41 and 42 needed to be distributed to
the IBIS committee for review.

BUGS 43 and 44 were recently submitted and need to
be classified.

For those interested, the link to where the bugs are
stored are located at:

  http://www.eda.org/pub/ibis/bugs/ibischk/

I am giving the links for downloading rather than
sending them out directly on the reflectors since
many people may not be interested in this level of
detail.

The bugdir.txt document summarizes the BUGs that
have been processed.  BUGs 36-40 have been processed,
but have not been fully implemented in a released
version of ibischk3.  

Bob Ross
Mentor Graphics
From owner-ibis  Fri Jun 23 15:22:52 2000
Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA08365 for ; Fri, 23 Jun 2000 15:22:51 -0700 (PDT)
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 SAA07245
	for ; Fri, 23 Jun 2000 18:20:12 -0400 (EDT)
Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20])
	by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id SAA20788
	for ; Fri, 23 Jun 2000 18:20:10 -0400 (EDT)
Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id PAA25746
	for ; Fri, 23 Jun 2000 15:19:56 -0700 (PDT)
Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4)
	id PAA22828; Fri, 23 Jun 2000 15:20:05 -0700
Date: Fri, 23 Jun 2000 15:20:05 -0700
From: guy@camarillo.viewlogic.com (Guy de Burgh)
Message-Id: <200006232220.PAA22828@f22.viewlogic.com>
To: ibis@eda.org
Subject: IBIS Open Forum Meeting Agenda


                     IBIS Open Forum Meeting Agenda 
                               for 6/30/00

                 Bridge Number    Reservation #   Passcode
                 (916) 356-9200   6-234927        9698213

(Guy de Burgh will be conducting the meeting.)

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                         de Burgh

     - Intros of New IBIS Participants, Meeting Quorum       de Burgh
     - Membership Update and Treasurers Report               de Burgh/Fleming
     - Review of Previous Meeting's Minutes (and ARs)        de Burgh
     - Miscellany/Announcements                              All
     - Press & Web Page Updates                              Huq, All
     - New Models Available, Library Update                  LaBonte, All
     - Opens for New Issues                                  All

8:15 Administrative and Project Discussions

     International/External Progress
     - IEC 62014-1 (IBIS Version 3.2)                        Fleming
     - pr EIAJ ED-5302 Standard for I/O Interface Model      
          for Integrated Circuits (IMIC)                     de Burgh
     - IEC PWI 93-1 Models of Integrated Circuits for EMI 
       Behavioral Simulation (formerly designated as
       IEC 93/67/NP IBIS and EMC Simulation)                 Perrin
     - JEDEC JC-16 Modeling and Testing                      Sessions
    
     DAC 2000 IBIS Summit Meeting Review                     de Burgh

     PCB EAST 2000 IBIS Summit Planning                      de Burgh

     DesignCon 2001 Preliminary IBIS Summit Planning         de Burgh

     IBIS Model Review Committee                             Flora

     New Administrative Issues                               All

8:45 Technical Discussion (some topics may be deferred)

     Connector Proposal Review                           Panella/Crisafulli

     IBIS Futures Group Report (IBIS-X, API, BIRDxx)         LaBonte

     ibischk3 Bug Tracking                                   Ross
     - BUG34 - No Error Reported for Missing V/I Tables      Flora
               in Output Buffers

     - BUG41 - Issue Warning Instead of Error for Common     de Burgh/Nolan
               Differential Pin
          
     - BUG42 - Warning Message for Outputs with Thresholds   de Burgh
               Needed

     - BUG43 -Error for Zero or Negative dV/dt Ramp Data     de Burgh
              Needed  (to be classified)

     - BUG44 - Warning for Parasitic Resistance Set Too      de Burgh
               High at 1000 Ohm (to be classified)

     BIRD61.1 - Enhanced Characterization of Receivers       de Burgh

     BIRD64.1 - Package Model Selector                       Muranyi

     BIRD65 - C_comp Refinements                             Muranyi

     BIRD66 - [Model Spec] Vref Addition                     de Burgh

     New Technical Issues                                    All

9:50 Wrap Up and Next Meetings Plans                         de Burgh

9:55 Sign Off

From owner-ibis  Sun Jun 25 17:37:42 2000
Received: from itx03.internex.co.kr (itx03.internex.co.kr [203.239.35.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA13307; Sun, 25 Jun 2000 17:37:39 -0700 (PDT)
Received: from imsong (imsong.internex.co.kr [203.239.35.36]) by itx03.internex.co.kr (AIX4.2/UCB 8.7/8.7) with SMTP id JAA18456; Mon, 26 Jun 2000 09:19:44 +0900 (KORST)
Message-ID: <000601bfdf06$6117a2c0$2423efcb@internex.co.kr>
From: "Song In-myung" 
To: "Signal Integrity news group" ,
        "IBIS Information" ,
        "IBIS Open Forum" 
Subject: About Impedance.
Date: Mon, 26 Jun 2000 09:34:57 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Disposition-Notification-To: "Song In-myung" 
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by server.eda.org id RAA13308

Hello everyone.

Did you have fun in weekend?

Is there any method of getting the input/output impedance value from IBIS model?
I think that these values are very important to match the transmission line impedance.
Is my thought correct?

How can I simulate the backbone, mainboard, or backplane of communication system?
For example, if any board has only connectors which are the signal and power pathes to 
subboard, how can I simulate and verify the signal integrity?
Should I use the EBD model of all subboards and connector model?
If then, how can I get the EBD model and connector's IBIS model?

Please help me.
You are a great help.

    Inmyung 

================================================================
Assistance Manager(http://www.internex.co.kr/~imsong)
897-15 Haedong Bidg. Daechidong. Kangnamgu. Seoul. Korea.
Internex Ltd.(http://www.internex.co.kr ; http://www.pcbkorea.com)
CAD Division
TEL : 822-553-2274
FAX : 822-554-8031
From owner-ibis  Mon Jun 26 06:38:46 2000
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA15604 for ; Mon, 26 Jun 2000 06:38:45 -0700 (PDT)
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345)
	id F0ABB4CD; Mon, 26 Jun 2000 09:36:05 -0400 (EDT)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id E79A04A5
	for ; Mon, 26 Jun 2000 09:36:05 -0400 (EDT)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id ; Mon, 26 Jun 2000 09:36:05 -0400
Message-ID: <212CC57E84B8D111AD780000F84AA04909484085@mroexc2.tay.dec.com>
From: "Ingraham, Andrew" 
To: Signal Integrity news group ,
        IBIS Open Forum 
Subject: RE: [SI-LIST] : About Impedance.
Date: Mon, 26 Jun 2000 09:35:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

>Is there any method of getting the input/output impedance value from IBIS
model?
 
It is fairly easy to get the low frequency impedance from the I-V curves by
inspection.  But be aware that the impedance of most buffers is a nonlinear
function of voltage or current.  There is no standard.  You could pick the
small-signal output impedance (negligible load current, voltage at the
rails), or the impedance at Vdd/2, or at Voh(min) and Vol(max), or Vih(min)
and Vil(max), or anything else.  And it generally differs between driving
low and driving high.

For output impedance, look at the [Pulldown] and [Pullup] curves; the clamp
curves are usually (but not necessarily!) negligible between Vdd and Gnd.
For driving low, look up the voltage you pick on the [Pulldown] curve, find
the Typ/Min/Max currents, and calculate Vout/Iout for each.  For driving
high, it's the same except you use the [Pullup] curve and you would use
Vdd-Vout, where Vout is the output voltage you pick.

Or you may prefer to find and average the output impedance over a range of
output voltages.

For input impedance, use the [GND Clamp] and [Power Clamp] curves and
combine them.  The [Power Clamp] is Vdd-relative so you need to adjust the
voltage axis before adding it to the [GND Clamp] curve.

These are large signal impedances.  If you prefer to know the small-signal
impedance around some operating point (say, around Vdd/2), look up a few
points next to that operating point and calculate deltaV/deltaI.  Which one
you use depends in part on the IC and its application.

The complex package impedance can be added to the low frequency impedance
from the I-V curves.  The simple package model is not very representative at
higher frequencies.

Depending on your simulator, you may also find the impedance vs. frequency,
voltage, or whatever, by simulating a small test "circuit".  Connect a
voltage source to the input or output pin.  Measure current.

>I think that these values are very important to match the transmission line
impedance.
>Is my thought correct?
 
Maybe.  However, impedance control might not very good on-chip, so to get
better accuracy, off-chip resistors might be used.  In digital circuits,
most inputs don't match transmission line impedances at all, so external
resistors would be used, if you require a matched impedance there.

Andy

From owner-ibis  Wed Jun 28 18:19:01 2000
Received: from g23.relcom.ru (g23.relcom.ru [193.125.152.117]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA27505 for ; Wed, 28 Jun 2000 18:19:00 -0700 (PDT)
Received: from d217.z194-58-100.relcom.ru (d217.z194-58-100.relcom.ru [194.58.100.217]) by g23.relcom.ru (8.8.8/Relcom-2A) with SMTP
	 id FAA05526  for ;Thu, 29 Jun 2000 05:00:22 +0400 (MSD)
Message-ID: <000401bfe165$7aa08570$d9643ac2@gena>
From: "Gennadiy" 
To: 
Subject: Question
Date: Thu, 29 Jun 2000 04:59:49 +0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Dear Colleagues,
For developing my program ICS (IBIS Circuit Simulator), which is intended
for frequency-domain signal integrity and crosstalk analyses, I need
specifications of touchstone files with S-, Y- and other matrix-parameters.
Do you know how I can get them?
Thanks in advance,
Gennadiy


From owner-ibis  Thu Jun 29 23:01:27 2000
Received: from zukengw.zuken.co.jp (zukengw.zuken.co.jp [202.33.240.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA02726 for ; Thu, 29 Jun 2000 23:01:25 -0700 (PDT)
Received: from zuken.co.jp (m5w114 [160.249.234.114])
	by zukengw.zuken.co.jp (8.9.3/3.7W) with ESMTP id OAA08765
	for ; Fri, 30 Jun 2000 14:58:43 +0900 (JST)
Received: from east4.zuken.co.jp (m5w100 [160.249.234.100])
	by zuken.co.jp (8.8.8/3.6Wbeta7) with ESMTP id OAA12922;
	Fri, 30 Jun 2000 14:58:40 +0900 (JST)
Received: from di35 (s3e35 [160.249.231.35])
	by east4.zuken.co.jp (8.8.8/3.7W) with ESMTP id OAA07603;
	Fri, 30 Jun 2000 14:58:38 +0900 (JST)
To: ibis@eda.org
Subject: about IBIS Golden Parser V3.x source code
From: Shin-ichi Hama 
Message-Id: <200006301455.BFB34958.BNBI@zuken.co.jp>
X-Mailer: Winbiff [Version 2.30PL4]
Date: Fri, 30 Jun 2000 14:55:56 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Dear EIA IBIS Community,

My name is Shin-ichi Hama of Zuken Inc. Japan.

I would like to obtain a license to use IBIS Golden Parser V3.x source code 
for building in to our software.

Do you allow to use this source code for a commercial use?

Please give me all the details necessary (i.e. remittance) to obtain the lic
ense of using the souce code.

Please ask me by email if you have any questions to this issue.



Best regards,

Shin-ichi Hama


-----------------------------------------------------------
        Shin-ichi Hama (hama@zuken.co.jp)
   
   ZUKEN Incorporated
   2-25-1 Edahigashi Tsuzuki-ku Yokohama 224-8585 JAPAN

   PHONE : 045-942-7787
   FAX   : 045-942-1915
-----------------------------------------------------------