From mbs@eos.ncsu.edu Wed Nov 1 08:28:08 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07053; Wed, 1 Nov 95 08:28:08 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA03828; Wed, 1 Nov 1995 11:20:42 -0500 From: mbs@eos.ncsu.edu Message-Id: <9511011620.AA03828@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: New IBIS Model Date: Wed, 01 Nov 95 11:20:40 EST Intel has just released the ibis model for the Pentium(R) Pro processor. It can be found in the directory vhdl.org://pub/ibis/models/intel/pentpro The current ibis model directory is below. Michael Steer Intel Corporation IBIS Files on vhdl.org as of 11/1/95 Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes -------------------------------------------------------------------------------- 82371fb.ibs chipset PIIX 08-09-95 R1.21 V1.1 Triton (NDA only)** 82371mb.ibs chipset MPIIX 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82374eb.ibs chipset ESC 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82374sb.ibs chipset ESC 08-09-95 R1.03 V1.1 PCI-EISA Bridge** 82375eb.ibs chipset PCEB 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82375sb.ibs chipset PCEB 08-09-95 R1.01 V1.1 PCI-EISA Bridge** 82378ib.ibs chipset SIO 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82378zb.ibs chipset SIO 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82379ab.ibs chipset SIO.A 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82423tx.ibs chipset DPU 08-09-95 R2.13 V1.1 Saturn** 82424zx.ibs chipset CDC 08-09-95 R2.13 V1.1 Saturn** 82425ex.ibs chipset PSC 08-09-95 R0.94 V1.1 Aries** 82426ex.ibs chipset IB 08-09-95 R0.94 V1.1 Aries** 82433lx.ibs chipset LBX 08-09-95 R2.13 V1.1 Mercury** 82433nx.ibs chipset LBX 08-09-95 R2.01 V1.1 Neptune** 82434lx.ibs chipset PCMC 08-09-95 R2.13 V1.1 Mercury** 82434nx.ibs chipset PCMC 08-09-95 R2.01 V1.1 Neptune** 82437fx.ibs chipset TSC 08-09-95 R1.21 V1.1 Triton (NDA only)** 82437mx.ibs chipset MTSC 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82437vx.ibs chipset TVX 08-09-95 R1.00 V1.1 Triton VX (NDA only)** 82438fx.ibs chipset TDP 08-09-95 R1.21 V1.1 Triton (NDA only)** 82438mx.ibs chipset MTDP 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82438vx.ibs chipset TDX 08-09-95 R1.00 V1.1 Triton (NDA only)** dx4pga.ibs cpu DX4 05-04-94 R2.0 V1.1 IntelDX4(TM) uP pp66sem.ibs pentium PP66 10-16-94 R3.0 V1.1 66MHz Pentium* pp100sem.ibs pentium PP100 10-15-94 R3.0 V1.1 100MHz Pentium* pentpro.ibs pentpro 11-1-95 R2.0 V2.1 Pentieum Pro Processor pentpro.pak pentpro 11-1-95 Packagae data for pentpro.ibs * Translated from an Intel Simplified Electrical Model. ** submitted by Name of Person Submitting: Arpad Muranyi Address: 1900 Prairie City Road Folsom, CA 95630 Affiliation: Intel Corporation E-Mail: arpad_muranyi@ccm.fm.intel.com Telephone Number: (916) 356-2558 Fax Number: (916) 356-3162 (NDA only) Non disclosure agreement required to obtain model. Contact submitter. National Semiconductor Corporation - Advanced Systems & Interface Product Group IBIS Files on vhdl.org as of 11/1/95 Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- ds26c31.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Drvr ds26c32.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Recvr 90c031tm.ibs interface 6/8/95 1.0 2.1 LVDS Quad Diff Line Drvr (NDA only) ** 90c032tm.ibs interface 6/8/95 1.0 2.1 LVDS Quad Diff Line Recvr (NDA only) ** 38c86av.ibs cbtl 9-18-95 1.0 1.1 CMOS BTL 9-Bit Latching Data Transceiver lct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524n.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr c2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2527v.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clk Drvr 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) pc87306.ibs superI_O 9-5-95 1.1 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int -------------------------------------------------------------------------------- g612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead g612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead gp612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead gp612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead dp8440vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver dp8441vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver ** submitted by Syed B. Huq Interface Applications Engineer National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com (NDA only) Non disclosure agreement required to obtain model. Contact submitter. From mbs@eos.ncsu.edu Wed Nov 1 08:36:37 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07166; Wed, 1 Nov 95 08:36:37 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA03847; Wed, 1 Nov 1995 11:29:11 -0500 From: mbs@eos.ncsu.edu Message-Id: <9511011629.AA03847@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS Date: Wed, 01 Nov 95 11:29:11 EST With regards to the various versions of S2IBIS . . . S2IBIS v2.091, the automatic Spice to IBIS translator from NC State University that is also the basis for several commerical distributions was verified to run with the following simulators SPECTRA from Cadence Design Systems (This was the baseline simulator used.) HSPICE PSPICE Berkely Spice versions 2 and 3 The previous version of S2IBIS, v 1.2, does not support all of these simulators and has known bugs. So far, S2IBIS v2.091 has no known bugs. The are executables for the SUN, HP and Decstation platforms. A windows version has not been posted. If anyone does develop such a version please consider posting it on vhdl.org. More information about S2IBIS can be found by anonymous ftp'ing to vhdl.org cd to the directory /pub/ibis/s2ibis/s2ibis_v2.091 Michael Steer IBIS Librarian From bob@icx.com Wed Nov 1 14:21:15 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09681; Wed, 1 Nov 95 14:21:15 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 1 Nov 95 14:13 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 1 Nov 95 14:16 PST Message-Id: Date: Wed, 1 Nov 95 14:16 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Minutes 10/27/95 DATE: November 1, 1995 SUBJECT: 10/27/95 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS: AT&T Global Info Solutions Dave Moxley* Cadence Design Sandeep Khanna, C. Kumar Contec CAE, Ltd. Dileep Divekar HyperLynx Kellee Crisafulli IBM Jay Diepenbrock INCASES Werner Rissiek, Olaf Rethmeier* Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, Derrick Duehren Interconnectix, Inc. Bob Ross* Meta-Software Les Spruiell, Mei Wong, You-Pang Wei, John Sliney Motorola Ron Werner National Semiconductor Syed Huq*, Atul Agarwal, Cheng-Yang Kao NEC Hiroshi Matsumoto, Eldar Yazbashevz Quad Design Jon Powell*, Chris Myles, Chris Rokusek* Quantic Labs Mike Ventham Tanner Research, Inc. Scott Wedge, Ed Miller, Peter Parrish Texas Instruments Roger Cline, Ben Andresen Thomson-CSF/SCTF Jean LeBrun UniCAD Canada Ltd. Stephen Lum VLSI Technology Dick Ulmer, Sung Oh* Zuken-Redac John Berrie OTHER PARTICIPANTS: ARPA Randy Harr Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadlab Ralf Bruning CFI Ron Christopher* Digital Equipment Corp. Barry Katz EIA Patti Rusher* High Design Technology Michael Smith, Dr. Ing. Cosso Hewlett Packard Tom Langdorf, Karl Kachigan, Henry Wu Integrated Silicon Systems Eric Bracken Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz LSI Logic Corp. Satish Pratadneni Mentor Graphics Ravender Goyal, Greg Doyle Micron Technology Brian Johnson MicroSim Arthur Wong North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Univ. of Illinois, Urbana Raj Mittra Zeelan Technology George Opsahl, Hiro Moriyasu (Independent) Bob Ward In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 12/1/95 (916) 356-9200 2-34986 8556351 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 None. Will Hobbs chaired the first 35 minutes of the meeting, and Jon Powell chaired the rest of the meeting. EIA MEMBERSHIP AND TREASURER'S REPORT The treasury is still about $8725.54, although one charge against the account is pending. Patti Rusher indicated that TI plans to purchase the ibischk2 source code. MINUTES REPORT, MISC. None. MISCELLANY/ANNOUNCEMENTS Bob Ross reported that there have been updates in the contents of vhdl.org under the /pub/ibis directory including all of the birds under birds, frequently asked questions under faq, ibischk2 executables under ibischk2, and meeting minutes in text form for all years. Also roster.txt has been moved to roster/roster.txt, and pressrel.dir has been changed to pressrel. Jon Powell reported that H.A.S. Electronics, Inc. at haselect@aol.com has advertised IBIS models. PRESS UPDATES Will Hobbs reported that the October 16, 1995 front page EE Times Article on the P6 referred to I/O models (IBIS models) described in the P6 Users manual. NEW MODELS None reported. [P6 Models not requiring NDA will be available November 1.] OPENS FOR NEW ISSUES Ground Bounce per some recent reflector discussion. EIA IBIS RATIFICATION Patti Rusher reported that EIA-656 was OFFICIALLY RATIFIED October 26, 1996 by EDAC. It is being forwarded to ANSI, hopefully for ratification by the end of the year. During an EDA standards roadmap presentations, Don Cottrel referenced IBIS and also raised some requests for additions to better position IBIS. EIA PRESS RELEASE AR - Patti Rusher voluteered to send a draft of the EIA press release for review. It will indicate EDA industry council interest in IBIS. WEB UPDATE (AND EIA) The delay in bringing up IBIS under //www.eia.org/eng is because of legal/ security/copyright concerns about what EIA can present on the Web Site. This is applicable to all Standards, not just IBIS, This also relates to funding from the sale of published documents copyrighted by EIA. This should be resolved within two weeks. Patti Rusher is pushing for a rapid resolution so that at least some of the IBIS material can be presented soon. Jon Powell has logos from eight companies to go on the Web page. Only logos from EIA member companies will be used. This is an additional benefit to become an EIA-IBIS member. AR - Patti Rusher send to Jon Powell the list of member companies who have supplied the required permission letters to use the logo. FACE TO FACE MEETING Syed Huq reported that the majority of respondents favored Monday, January 29 before SuperCon96. He will schedule rooms and make arrangements for National Semiconductor to host the meeting. A possible celebration dinner for EIA-656 completion may be planned that evening for those staying over. MODEL USAGE TRACKING Syed Huq reaffirmed the need and interest to track model usage. Stephen Peters and Syed will seek help within their own organizations because it is an internal issue regarding access through company Web pages. Perhaps their solution will work on vhdl.org. This raised a discussion on pointers to company home pages from EIA. This is feasable and planned. So the possiblity exists that many companies may have IBIS models available under their control and also include the mechanisms to get the NDA models. One possiblility suggested by Jon Powell is an interface which requests the user name before allowing access to certain directories containing the IBIS models. Kellee Crisafulli reported contact and interest by Xilinx to post models. The decision is still being reviewed by management. Sung Oh reported that VLSI wants to remain in control of distibution of their IBIS models. People contact the sales force to get models. GOLDEN PARSER UPDATE Bob Ross has posted the executables created by Jon Powell for ibischk2 on vhdl.org under /pub/ibis/ibischk2. Currently it is a flat directory with all executables appended by the associated workstation. The original posting was corrupted, but the correct versions are now in place. So if you had any problems, check that you have the current executable. Report any problems. Compiler information will be embedded in the executables, similar to the ibis_chk executables for Version 1.1. Jon Powell will take care of creating these after some time to check that there are no new problems. They will then be designated ibischk2 and put under the appropriate workstation directory similar to ibis_chk. The verion number will be version 2.1.10 since these are IBIS version 2.1 (and below) executables. SPICE TO IBIS VERSION 2.1 Bob Ross reported on the comment by Celso Faia of Unicad that a DOS Windows version is needed. Kellee Crisafulli reported that he has been unable to get Version 2.1 compiled, has been in touch with Michael Steer, and may get some internal resources to help. COOKBOOK Bob Ross reported no progress. Since Stephen Peters of Intel is going to do an internal update, he may be the key resource to get this done. Similarly Syed Huq may have some inputs, especially for models from measurements. So Kellee and Bob are turning this over to Stephen and Syed. However, we will all be available to review and give inputs. Since this can be an extra time work project, there is no date committment. So it is taken off the Agenda. BIRD30.2 - PIN PROGRAMMABLE BUFFER STRENGTHS Arpad Muranyi discussed BIRD30.2 with a text revision. Some discussion including its relationship to DCL (Delay Calculation Language) standardization with respect to dynamically selectable buffers was initiated by Ron Christopher. Several ideas to select models including ordering were discussed. The concensus was that the actual selection basis was too complicated to come to an agreement at this time. The description syntax could be standardized, but proposals would have to be developed and considered. The current proposal allows manual selection through a graphical user interface (GUI) with no standardization on descriptions. Jon Powell stated that this could work for One device considerations, but the concern is that it would be a very combersome process for working with a large board with many IBIS model files from several vendors. BIRD30.2 was approved by the Vote. Proposals the improve upon BIRD30.2 would be considered. BIRD28.3+ PACKAGE MODEL ENHANCEMENT Stephen Peters reported on C. Kumar's proposed extension recently sent on the reflector. The proposed extension would have to add a pin ordering file and a Matrix name to allow a more general set of coupling relationships. The primary concern was that it may be too close to an MCM discription without including some physical information. This topic is still open for discussion, and the proposed improvement by Kumar in BIRD format could eventually emerge as a new bird to amend approved BIRD28.3 EGG6 - TTL and CMOS Jon Powell reported that he is still investigating three suggestions including one provided by Arpad Muranyi to automatically detect whether a device is TTL or CMOS. He is pessimistic, but needs validation of his position. EGG7 - CONNECTOR AND CABLE MODEL Bob Ross summarized the proposed Connector model extension which involves no change of the IBIS Specification. It provides an interpretation of the existing package model formats from the default model though the Version 2.1 Matrix models up to BIRD28.3 extensions. Involvement by a connector manufacturer such as AMP would be helpful to test the practicality of this approach. Several names were suggested and Bob will follow up. The CABLE model would require new syntax and complication, but it could then handle more complicated interconnection schemes with connection from, say, pin 1 of board 1 to connection or pin 2 of board 2. PHYSICAL PACKAGE DISCUSSION Kellee Chrissafulli is nearing completion of a proposal for such an extension. EGG8 is reserved for this. GROUND BOUNCE Bob Ross reported on recent Email from Michael Gutzmann, and this was briefly discussed in the remaining time. One concern was whether there were additional parameters or layout which would contribute to significant inaccuracies beyond what the proposed improvement would cover. What accuracy can be achieved and what accuracy currently exists? How are the real skew effects handled? This topic remains open for discussion and proposals. NEXT MEETING: It is set on Friday, December 1, 1995 (Moved from November 17 because several people would be out). ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Server Chipset System Validation Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com 10220 SW Nimbus Ave, K4, Portland, OR 97223 To become a voting member of the EIA IBIS Open Forum, send email to ibis-info@vhdl.org for instructions. If you want to join the e-mail reflector (ibis@vhdl.org), send e-mail to the IBIS secretary at ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From kellee@washington.nwlink.com Wed Nov 1 16:35:36 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10442; Wed, 1 Nov 95 16:35:36 PST Received: (from kellee@localhost) by washington.nwlink.com (8.6.12/8.6.12) id QAA02122; Wed, 1 Nov 1995 16:28:16 -0800 Date: Wed, 1 Nov 1995 16:28:16 -0800 Message-Id: <199511020028.QAA02122@washington.nwlink.com> X-Sender: kellee@hyperlynx.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: Kellee Crisafulli Subject: Egg ? Proposed new physical format for SIMM's MCM's etc I am resending this egg because it didn't seem to go out the first time. If you already received it, ignore this copy. Proposed IBIS physical package Format (.IBP) Version 0.15 10-29-95 Versions: 0.1 7-30-95 0.15 10-29-95 Introduction This is a first draft of a proposal to allow physical package models of IC's, MCM's and circuit boards such as SIMM memory modules to be described in combination with the existing IBIS model specification. The .IBP file is a higher level of abstraction above the .IBS file. For example if this format is used to represent a SIMM module then the the .IBS components contained within it can be modified to support memory devices from Toshibia, NEC, TI etc by simply changing the references to the .IBIS files. Like wise if the .IBP file is used to represent an MCM model the .IBS file would represent the bare die. If the .IBP file is used to represent the package of an IC model than the .IBS file would again be the bare die information only. This format allows layered metal conductors and dielectric layers to be specified as well as interconnections between layers. The advantages of this format over other existing standards are: - Simple compared to most existing PCB standards. - Allows layers to be specified - Allows component values to be specified - Allows IC types to be specified in IBIS format Translators: To create translators to this format RSI could be contracted to create a writer and make available translators from all of the 30+ PCB file formats they support into this format. Most CAE companies are probably already familar with RSI. If you have comments please contact Kellee Crisafulli: Internet: kellee@hyperlynx.com voice 206-869-2320 fax 206-881-1008 Overview of a .IBP File's Format: {VERSION=number [comment]} {SUBSTRATE_OUTLINE (outline information) [comment] ... (outline information) } {STACKUP (layer information) [comment] ... (layer information) } {DEVICES (device information) [comment] (device information) ... (device information) } {PADSTACK=name (pad information) [comment] (pad information) ... (pad information) } {PADSTACK=name (pad information) (pad information) ... (pad information) } ...more padstacks... {NET=name (segment/arc/via/pin information) [comment] (segment/arc/via/pin information) ... (segment/arc/via/pin information) } {NET=name (segment/arc/via/pin information) (segment/arc/via/pin information) ... (segment/arc/via/pin information) } ...more nets... {NET=name (segment/arc/via/pin information) (segment/arc/via/pin information) ... (segment/arc/via/pin information) } {END} Notes on Detailed Syntax of .IBP File This file follows the specifications created for the IBIS file in that: - It is an ASCII human readable specification - It uses the same units and scaling notation as the IBIS specification - It uses a similar format Differences with the IBIS specification are: - Line length is allowed to be 180 characters Italicized fields are to be filled in with appropriate values. Square brackets [ ] denote optional parameters. Subrecord fields [lines beginning with ')'] can come in any order, but the specified order is recommended for readability. All subrecords must be on a single line. This is true in spite of the fact that, for readability, some subrecords in this document are shown on multiple lines. Curly braces { } can be separated from keywords and record ends by white space; the right brace can be on the same line as the last subrecord or on the next line. Parentheses ( ) can be separated from keywords and subrecord ends by white space; must be on the same line as the subrecord. Comments must be separated by at least one white space from the preceding text. Lines can be terminated by CR, LF, CR-LF, or LF-CR. White space is defined as space, horizontal tab, vertical tab, linefeed, form feed, or carriage return. White space is NOT allowed after or in a name field. Keyword VERSION Format: {VERSION=number [comment]} o VERSION specifies the version of the file format o number specifies the .IBP-file version number o required record; must be the first non-blank line in file o only one VERSION record allowed per file Example Records for VERSION: example 1: {VERSION=1.0} example 2: {VERSION=1.0 written from ABC's PCB layout package} Keyword SUBSTRATE_OUTLINE Format: {SUBSTRATE_OUTLINE [comment] (PERIMETER_SEGMENT X1=position Y1=position X2=position Y2=position) [comment] ...more perimeter segments... (PERIMETER_ARC X1=position Y1=position X2=position Y2=position XC=position YC=position R=radius) [comment] ...more perimeter arcs... } o SUBSTRATE_OUTLINE identifies the board or substrate edge. This is useful for display purposes, and to calculate impedances of conductors near the edge the board. o optional record; if missing, the SUBSTRATE_OUTLINE outline is assumed to be rectangular, and is determined as the position of the most-extreme component pins or traces present. o the SUBSTRATE_OUTLINE record can also be used to specify holes and other cut-outs in the interior of the package substrate. For example mounting holes, or alignment holes like those used for SIMM modules o PERIMETER_SEGMENT record reports information for straight segments of the board's perimeter o units throughout subrecord are as specified in the UNITS record o X1, Y1, X2, or Y2 position is the x or y position of end 1 or end 2 of the segment o PERIMETER_ARC record reports information for arcs on the board's perimeter o Arc's are drawn clockwise from X1,Y1 to X2,Y2 o units throughout subrecord are as specified in the UNITS record o X1, Y1, X2, or Y2 position is the x or y position of end 1 or end 2 of the arc o XC or YC position is the position of the center of the arc o R radius is the radius of the arc o each PERIMETER_SEGMENT record must be on a single line o only one SUBSTRATE record allowed per file Example Records for SUBSTRATE_OUTLINE: example 1: {SUBSTRATE_OUTLINE rectangular board with edge connector (PERIMETER_SEGMENT X1=0.0 Y1=0.0 X2=12.0 Y2=0.0) (PERIMETER_SEGMENT X1=12.0 Y1=0.0 X2=12.0 Y2=-5.0) (PERIMETER_SEGMENT X1=12.0 Y1=-5.0 X2=3.0 Y2=-5.0) (PERIMETER_SEGMENT X1=3.0 Y1=-5.0 X2=3.0 Y2=-5.5) connector segment (PERIMETER_SEGMENT X1=3.0 Y1=-5.5 X2=0.5 Y2=-5.5) connector segment (PERIMETER_SEGMENT X1=0.5 Y1=-5.5 X2=0.5 Y2=-5.0) connector segment (PERIMETER_SEGMENT X1=0.5 Y1=-5.0 X2=0.0 Y2=-5.0) (PERIMETER_SEGMENT X1=0.0 Y1=-5.0 X2=0.0 Y2=0.0) } Keyword STACKUP Format: {STACKUP [comment] (SIGNAL T=thickness [P=plating_thickness] [C=constant] L=layer_name [M=material_name]) [comment] ...more signal layers... (DIELECTRIC T=thickness [C=constant] [L=layer_name] [M=material_name]) [comment] ...more dielectric layers... (PLANE T=thickness [C=constant] [L=layer_name] [M=material_name]) [comment] ...more plane layers... } o STACKUP identifies the stackup-specification record o optional record; if missing, stackup is built as layer names encountered in NET and PADSTACK subrecords; first layer encountered becomes top layer, next becomes second-from-top, etc. o subrecords can be mixed in any order that correctly describes the PACKAGE's top-to-bottom construction; the first SIGNAL or PLANE layer will be numbered 1 (top), the next 2 (second from the top), and so forth o SIGNAL record reports information for signal layers o units throughout subrecord are as specified in the UNITS record o thickness specifies how thick the metal is o optional plating_thickness specifies how thick the metal plating is; if missing, assumed to be 0.0 o optional constant specifies resistivity; if missing, assumed to be 1.724e-8 (copper) o layer_name specifies a name for the layer; maximum of 20 characters; layers reported in NET subrecords are matched to these names o optional material_name specifies a name for the trace material; maximum of 20 characters o DIELECTRIC record reports information for dielectric layers o units throughout subrecord are as specified in the UNITS record o thickness specifies how thick the dielectric is o optional constant specifies the dielectric constant; if missing, assumed to be 4.8 (FR-4) o optional layer_name specifies a name for the layer; maximum of 20 characters o optional material_name specifies a name for the dielectric material; maximum of 20 characters o PLANE record reports information for power-plane layers o units throughout subrecord are as specified in the UNITS record o thickness specifies how thick the metal is o optional constant specifies resistivity; if missing, assumed to be 1.724e-8 (copper) o optional layer_name specifies a name for the layer; maximum of 20 characters; layers reported in NET subrecords are matched to these names o optional material_name specifies a name for the plane material; maximum of 20 characters o each SIGNAL, PLANE, or DIELECTRIC record must be on a single line o only one STACKUP record allowed per file Example Records for STACKUP: example 1: {STACKUP 4-layer PACKAGE; units for this example are English, weight (SIGNAL T=0.0014 P=0.0014 L=TOP) 1-oz base and plating; resistivity = 0.0 (DIELECTRIC T=0.02 C=4.8) (PLANE T=0.0014 L=2) by default plating=0.0 and resistivity = copper (DIELECTRIC T=0.01 C=4.8) (PLANE T=0.0014 L=3) by default plating=0.0 and resistivity = copper (DIELECTRIC T=0.02 C=4.8) (SIGNAL T=0.0014 P=0.0014 L=BOTTOM) } example 2: {STACKUP same example, except this one includes resistivities and some layer and material names (SIGNAL T=14e-3 P=14e-3 C=0.017u L=TOP) 1-oz base and plating; resistivity = copper's (DIELECTRIC T=0.02 C=4.8 M=FR4) (PLANE T=14e-3 C=0.017u L=Vcc) (DIELECTRIC T=0.01 C=4.8 M=FR4) (PLANE T=14e-3 C=0.017u L=GND) (DIELECTRIC T=0.02 C=4.8 M=FR4) (SIGNAL T=14e-3 P=14e-3 C=0.017u L=BOTTOM) } Keyword DEVICES Format: {DEVICES [comment] (IC REF=reference_designator NAME=name.IBS L=layer_name [comment] ...more ICs... (R REF=reference_designator VAL=value L=layer_name) [comment] ...more resistors... (C REF=reference_designator VAL=value L=layer_name) [comment] ...more capacitors... (J REF=reference_designator NAME=name L=layer_name) [comment] ...more connectors... } o DEVICES identifies the device-specification record o required record o any non-zero number of these subrecords may follow: IC, R, C, J IC subrecord o IC record reports information for ICs (drivers and receivers) o reference_designator specifies the IC's reference designator o name specifies the IBIS model file name. Only file name and extension are provide. File path information must not be included. o layer_name is the name of the layer which the device is on R subrecord o R record reports information for resistors o reference_designator specifies the resistor's reference designator o value specifies the resistor's value, in ohms o layer_name is the name of the layer which the device is on C subrecord o C record reports information for capacitors o reference_designator specifies the capacitor's reference designator o value specifies the capacitor's value, in Farads o layer_name is the name of the layer which the device is on J subrecord o J record reports information for connectors o reference_designator specifies the connector's reference designator o value specifies the connector's name (e.g. ABC 11345AG68) vendor specific name o layer_name is the name of the layer which the device is on Note: The special layer name EDGE is used to specify that the connector is an edge connector or wraps around both sides of the board or substrate. o Each device-type record must be on a single line. o Only one DEVICES record is allowed per file. o Future versions may choose to add more passive devices. For the initial release, only capacitors and resistors may be specified. This should cover most small modules and MCM's. The number of component types that could be added in the future could include dozens of component types. To keep the specification simple for the first release other componet types are not allowed. Example Records for DEVICES: example 1: {DEVICES (IC REF=U13 NAME=XC_4010.IBS L=TOP) Xilinx LCA; on top layer (IC REF=U20 NAME=82374.IBS L=8) Intel chip on layer 8 (back side of substrat) (R REF=R15 VAL=1K L=TOP) resistance = 1000 ohms (C REF=C1 VAL=22p L=8) capacitance = 22 pF (R REF=R15 VAL=5n) inductance = 0.005 uH (J REF=J2 NAME=Amp_HDI100 L=TOP) Amp HDI 100 pin connector } Keyword PADSTACK Format: {PADSTACK=padstack_name, [drill_size] (layer_name, pad_shape, pad_sx, pad_sy, pad_angle, [thermal_clear_shape], [thermal_clear_sx], [thermal_clear_sy], [thermal_clear_angle], [pad_type]) [comment] ...more padstack elements... (layer_name, pad_shape, pad_sx, pad_sy, pad_angle, [thermal_clear_shape], [thermal_clear_sx], [thermal_clear_sy], [thermal_clear_angle], [pad_type]) [comment] } o PADSTACK identifies the padstack-specification record o at least one padstack-element subrecord must follow o a comment is not allowed on the PADSTACK line, owing to the fixed-position nature of this record; comments are allowed on ensuing lines with padstack-element subrecords o padstack_name is a unique a name for this padstack; maximum of 32 characters and cannot contain white space o optional drill_size is the diameter of the padstack's drill hole, if any; if there is no drill hole, may omit this parameter; drill_size is the diameter of the drill hole before plating (hole plating is specified by the STACKUP record and is the same as the outside-layer plating thickness) o NOTE: The format of the PADSTACK record differs somewhat from the other records in the .IBP file, in that PADSTACK is fixed-position rather than keyword-based. This means that all parameters must come in the specified order (optional parameters are always at the end of a line). This change (to a fixed-position format) has been introduced to shorten the length of the .IBP file. Padstack-element subrecord o padstack-element record reports information for individual pads in a padstack o units throughout subrecord are as specified in the UNITS record o layer_name is name of the layer which the pad is on; valid values are: user_name MDEF ADEF where user_name is any user-created name that does not violate .IBP-file syntax MDEF is a special, reserved layer name indicating that all layers have this default metal pad unless otherwise specified with an explicit padstack-element subrecord ADEF is a special, reserved layer name indicating that all plane layers defined in the STACKUP record will have this default anti-pad unless otherwise specified with an explicit padstack-element subrecord (an 'anti-pad' defines the size and shape of a non-conducting hole in a plane layer through which a via passes) o if layer_name does not match a name already in the PACKAGE's stackup, a new layer with name layer_name will be created o pad_shape is the shape of the pad; valid values are: 0, 1, 2 where '0' means oval or round (pad_sx = pad_sy if round) '1' means rectangular or square (pad_sx = pad_sy if square) '2' means oblong (oblong shape is a rectangle with rounded corners) o pad_sx or pad_sy is the x or y dimension of the pad o pad_angle is the counter-clockwise rotation angle of the pad in degrees; rotation angle can range from 0.0 to +/-359.999; valid angular resolution is 0.001 degree; 0 (without a decimal point) is the recommended way of specifying 'no rotation' o thermal_clear_shape (required only if pad_type is T, thermal relief) is the shape of the clear area around a thermal-relief pad; valid values are: 0, 1 , 2 where '0' means oval or round (thermal_clear_sx = thermal_clear_sy if round) '1' means rectangular or square (thermal_clear_sx = thermal_clear_sy if square) '2' means oblong (oblong shape is a rectangle with rounded corners) o thermal_clear_sx or thermal_clear_sy (required only if pad_type is T, thermal relief) is the x or y dimension of the clear area around a thermal-relief pad o thermal_clear_angle (required only if pad_type is T, thermal relief) is the counter-clockwise rotation angle of the clear area around a thermal-relief pad, in degrees; rotation angle can range from 0.0 to +/-359.999; valid angular resolution is 0.001 degree; 0 (without a decimal point) is the recommended way of specifying 'no rotation' o if any one of thermal_clear_sx, thermal_clear_sy, or thermal_clear_angle is specified, all three must be specified and the pad_type must be specified as T o optional pad_type specifies whether the pad is a normal metal pad, an anti-pad, or a thermal relief; if missing and three x/y/angle parameters specified, the pad is assumed to be a normal metal pad; if missing and six x/y/angle parameters specified, the pad is assumed to be a thermal-relief pad; valid values are: M A T where 'M' means normal metal pad (used for signal vias and component pads) 'A' means anti-pad (used to define non-conducting hole through a plane layer) 'T' means a thermal-relief pad (used to connect a pad to a plane layer) o NOTE: Anti-pads are not required; a padstack not using anti-pads can simply omit information about plane layers. Example Records for PADSTACK: example 1: rectangular surface-mount pad on the top layer; spaces after commas are not required {PADSTACK=SMT001 (TOP, 1, 0.04, 0.08, 0) } example 2: round surface-mount pad on bottom layer; PACKAGE has 16 layers and layer names are numeric {PADSTACK=PSTK-054 (16,0,0.04,0.04,0) } example 3: oblong surface-mount pad on bottom layer, at 45-degree angle {PADSTACK=SMT003 (BOTTOM, 2, 0.04, 0.06, 45.0) } example 4: through-hole, 60-mil-diameter round pads on all layers with a 30-mil-diameter drill hole {PADSTACK=STD1, 0.03 (MDEF, 0, 0.06, 0.06, 0) } example 5: through-hole, 60-mil-diameter round pads on all layers except layer 1; layer 1 has a 60-mil-wide square pad; drill hole is 30 mils in diameter {PADSTACK=STD1, 0.03 (1, 1, 0.06, 0.06, 0) (MDEF, 0, 0.06, 0.06, 0) } example 6: through-hole padstack; 60-mil-wide square pad on layers 1 and 8; 60-mil-diameter round pads on layers 2 and 7; no pads on layers 3 and 6; 60-mil-diameter round thermal-relief pad with 100-mil-diameter round clear area on layer 4;100-mil-diameter round anti-pad on layer 5 {PADSTACK=STD1, 0.03 (1, 1, 0.06, 0.06, 0) (2, 0, 0.06, 0.06, 0, M) pad type 'M' not required (4, 0, 0.06, 0.06, 0, 0, 0.10, 0.10, 0, T) thermal pad (5, 0, 0.10, 0.10, 0, A) anti-pad (7, 0, 0.06, 0.06, 0) (8, 1, 0.06, 0.06, 0) } Keyword NET Format: {NET=name [comment] (SEG X1=position Y1=position X2=position Y2=position W=width L=layer_name) [comment] ...more segments... (ARC X1=position Y1=position X2=position Y2=position XC=position YC=position R=radius W=width L=layer_name) [comment] ...more arcs... (VIA X=position Y=position [L1=layer_name] [L2=layer_name] P=padstack_name) [comment] ...more vias... (PIN X=position Y=position R=reference_designator.pin_name P=padstack_name [F=function]) [comment] ...more pins... } o NET identifies a net-specification record o name is the net's name o any non-zero number of these subrecords may follow: SEG, ARC, VIA, and PIN SEG subrecord o SEG record reports information for straight metal trace segments o units throughout subrecord are as specified in the UNITS record o X1, Y1, X2, or Y2 position is the x or y position of end 1 or end 2 of the segment o width is the segment's width o layer_name is name of the layer which the segment is on; if layer_name does not match a name already in the PACKAGE's stackup, a new layer with name layer_name will be created Example Records: example 1: a simple trace segment; 10 mils wide; on layer "top" (SEG X1=1.0 Y1=0.5 X2=1.0 Y2=1.8 W=0.01 L=top) example 2: a 45-degree trace segment; 15 mils wide; on layer 3; note lack of case-sensitivity (seg x1=1 y1=1 x2=2 y2=2 w=15e-3 l=3) How to draws a segment: ARC subrecord o ARC record reports information for curved metal trace segments o units throughout subrecord are as specified in the UNITS record o X1, Y1, X2, or Y2 position is the x or y position of end 1 or end 2 of the arc o XC or YC position is the x or y position of the center of the arc o R radius is the radius of the arc o width is the arc's metal width o layer_name is name of the layer which the arc is on; if layer_name does not match a name already in the PACKAGE's stackup, a new layer with name layer_name will be created o The arc is drawn clockwise from X1,Y1 to X2,Y2 Example Records: example 1: a curved trace segment; radius of a half inch; 10 mils wide; on layer "top" (ARC X1=1.0 Y1=1.0 X2=1.0 Y2=2.0 XC=1.0 YC=1.5 R=0.5 W=0.01 L=top) VIA subrecord o VIA record reports information for vias; use for vias where no component pin is present; if there is a component pin, use a PIN record instead o units throughout subrecord are as specified in the UNITS record o X or Y position is the x or y position of the via o optional L1 layer_name is the name of the layer the via starts on; if missing, assumed to be the top layer; if layer_name does not match a name already in the PACKAGE's stackup, a new layer with name layer_name will be created o optional L2 layer_name is the name of the layer the via ends on; if missing, assumed to be the bottom layer; if layer_name does not match a name already in the PACKAGE's stackup, a new layer with name layer_name will be created o padstack_name is the name of the padstack associated with the via; must match the name of a padstack reported in a PADSTACK record Example Records: example 1: a via between layers TOP and BOT; pads defined in padstack STD1 (VIA X=2.35 Y=4.05 L1=TOP L2=BOT P=STD1) example 2: same as example 1, except layers are missing, so assumed to be top and bottom (VIA X=2.35 Y=4.05 P=STD1) example 3: a via connecting two trace segments on top layer and layer "foo" (VIA X=5 Y=6.95 L2=foo P=STCK002) PIN subrecord o PIN record reports information for a component pin o units throughout subrecord are as specified in the UNITS record o X or Y position is the x or y position of the component pin o reference_designator.pin_name is the reference designator and pin name of the component pin o padstack_name is the name of the padstack associated with the pin; must match the name of a padstack reported in a PADSTACK record Example Records: example 1: pin 4 on U3, with surface-mount pad defined by padstack SMD1 (PIN X=7.55 Y=9.15 R=U3.4 P=SMD1) example 2: pin 2 of resistor R2 (PIN X=0.05 Y=1 R=R2.2 P=FOO) o as many of each net subrecord (SEG, ARC, VIA, and PIN) per NET record as needed are allowed; subrecords can come in any order o as many NET records per file as needed are allowed Example Records for NET: example 1: a complete trace, with 4 segments; 3 vias connecting the segments; an IC pin at one end {NET=clock (VIA X=1.0 Y=1.0 L1=TOP L2=BOT P=PS002) (SEG X1=1.0 Y1=1.0 X2=1.95 Y2=1.0 W=.01 L=TOP) segment 1 (VIA X=1.95 Y=1.0 L1=TOP L2=2 P=PS002) connecting via (SEG X1=1.95 Y1=1.0 X2=1.95 Y2=1.2 W=.008 L=2) segment 2 (VIA X=1.95 Y=1.2 L1=2 L2=6 P=PS002) connecting via (SEG X1=1.95 Y1=1.2 X2=2.65 Y2=1.2 W=.008 L=6) segment 3 (VIA X=2.65 Y=1.24 L1=TOP L2=BOT P=PS002) connecting via (SEG X1=2.65 Y1=1.2 X2=4 Y2=2.2 W=.01 L=BOT) segment 4 (PIN X=4 Y=2.2 R=U17.4 P=PS005) surface-mount IC pin } Keyword END Format: {END} o END identifies the end of the PCB-layout data A Complete .IBP File with Two Nets: {VERSION=1.10} {SUBSTRATE_OUTLINE (PERIMETER_SEGMENT X1=0.0cm Y1=0.0c X2=8.0c Y2=0.0c) (PERIMETER_SEGMENT X1=8.0cm Y1=0.0c X2=8.0c Y2=8.0c) (PERIMETER_SEGMENT X1=8.0c Y1=8.0c X2=0.0c Y2=8.0c) (PERIMETER_SEGMENT X1=0.0c Y1=8.0c X2=0.0c Y2=0.0c) } {STACKUP (SIGNAL T=35u P=35u L=TOP) 35 micro meters thick -> 1 oz copper (DIELECTRIC T=254u) 254micro meters thick -> 10 mili inches (SIGNAL T=35u L=2) (DIELECTRIC T=254u) (PLANE T=35u L=VCC) (DIELECTRIC T=254u) (PLANE T=35u L=GND) (DIELECTRIC T=254u) (SIGNAL T=35u L=3) (DIELECTRIC T=254u) (SIGNAL T=35u P=35u L=BOTTOM) } {DEVICES (IC REF=U15 NAME=74ACT240.IBS L=BOTTOM) (IC REF=U222 NAME=LCA3000.IBS L=TOP) (IC REF=U17 NAME=F161.IBS L=TOP) (R REF=R15 NAME=68 L=BOTTOM) (R REF=R29 NAME=100 L=BOTTOM) } {PADSTACK=THR001, 0.03 (MDEF, 0, 0.06, 0.06, 0) } {PADSTACK=SMD001 (TOP, 1, 0.04, 0.06, 0) } {NET=IBIS_1 (PIN X=1.250c Y=0.950c R=U15.18 P=SMD001) (SEG X1=1.250c Y1=0.950c X2=1.350c Y2=1.050c W=0.015c L=TOP) (SEG X1=1.350c Y1=1.050c X2=1.600c Y2=1.050c W=0.015c L=TOP) (VIA X=1.600 Y=1.050 L1=TOP L2=BOTTOM P=THR001) (SEG X1=1.600 Y1=1.050 X2=1.650 Y2=1.100 W=0.015 L=BOTTOM) (VIA X=1.650 Y=1.100 P=THR001) (SEG X1=1.650 Y1=1.100 X2=1.650 Y2=1.150 W=0.015 L=TOP) (PIN X=1.650 Y=1.150 R=R15.2 P=SMD001) (SEG X1=1.650 Y1=1.150 X2=2.050 Y2=1.150 W=0.015 L=TOP) (SEG X1=2.050 Y1=1.150 X2=2.050 Y2=1.050 W=0.015 L=TOP) (VIA X=2.050 Y=1.050 L1=TOP L2=BOTTOM P=THR001) (SEG X1=2.050 Y1=1.050 X2=2.050 Y2=2.500 W=0.015 L=2) (VIA X=2.050 Y=2.500 L1=TOP L2=BOTTOM P=THR001) (SEG X1=2.050 Y1=2.500 X2=2.150 Y2=2.600 W=0.015 L=TOP) (PIN X=2.150 Y=2.600 R=U222.85 P=SMD001) } {NET=IBIS_2 (PIN X=4.600 Y=0.600 R=U17.2 P=THR001) (SEG X1=4.600 Y1=0.600 X2=4.550 Y2=0.550 W=0.015 L=2) (SEG X1=4.550 Y1=0.550 X2=4.200 Y2=0.550 W=0.015 L=2) (SEG X1=4.200 Y1=0.550 X2=4.150 Y2=0.600 W=0.015 L=2) (SEG X1=4.150 Y1=0.600 X2=4.150 Y2=1.350 W=0.015 L=2) (VIA X=4.150 Y=1.350 L1=TOP L2=BOTTOM P=THR001) (SEG X1=4.150 Y1=1.350 X2=4.150 Y2=1.500 W=0.015 L=TOP) (SEG X1=4.150 Y1=1.500 X2=4.100 Y2=1.550 W=0.015 L=TOP) (SEG X1=4.100 Y1=1.550 X2=2.350 Y2=1.550 W=0.015 L=TOP) (SEG X1=2.350 Y1=1.550 X2=2.300 Y2=1.500 W=0.015 L=TOP) (PIN X=2.300 Y=1.500 R=R29.1 P=THR001) } {END} Have a great day...Kellee Crisafulli, HyperLynx Inc. From Arpad_Muranyi@ccm.fm.intel.com Thu Nov 2 09:22:05 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22196; Thu, 2 Nov 95 09:22:05 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tB3Dm-000UlMC; Thu, 2 Nov 95 09:14 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tB3Dk-000twgC; Thu, 2 Nov 95 09:14 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Thu, 02 Nov 95 09:14:32 PST Date: Thu, 02 Nov 95 08:19:00 PST From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Subject: Re: IBIS Minutes 10/27/95 Text item: Jon, Reading the minutes, I see your concern about large boards. However, I don't think that this can only be done through interactive user interface. The simulator tool could have a macro, or an external buffer selection response file, or simulation configuration file, or something like that, through which the "user responses" (buffer selections other than defaults) are all available (predetermined). With this method you have an option to do it completely invisibly (as in a batch job which runs overnight), as well as through interactive user interface (as in experimenting and what if simulations). Arpad ================================================================================ BIRD30.2 - PIN PROGRAMMABLE BUFFER STRENGTHS Arpad Muranyi discussed BIRD30.2 with a text revision. Some discussion including its relationship to DCL (Delay Calculation Language) standardization with respect to dynamically selectable buffers was initiated by Ron Christopher. Several ideas to select models including ordering were discussed. The concensus was that the actual selection basis was too complicated to come to an agreement at this time. The description syntax could be standardized, but proposals would have to be developed and considered. The current proposal allows manual selection through a graphical user interface (GUI) with no standardization on descriptions. Jon Powell stated that this could work for One device considerations, but the concern is that it would be a very combersome process for working with a large board with many IBIS model files from several vendors. BIRD30.2 was approved by the Vote. Proposals the improve upon BIRD30.2 would be considered. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS Minutes 10/27/95 To: ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Wed, 1 Nov 95 14:16 PST Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 1 Nov 95 14:16 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 1 Nov 95 14:13 PST Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09681; Wed, 1 Nov 95 14:21:15 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 1 Nov 95 14: 19:52 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tAuTm-000twVC; Wed, 1 Nov 95 23:54 PST From iniewski@procyon.pmc-sierra.bc.ca Thu Nov 2 10:32:10 1995 Return-Path: Received: from procyon (procyon.pmc-sierra.bc.ca) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22622; Thu, 2 Nov 95 10:32:10 PST Received: by procyon (5.57/Ultrix3.0-C) id AA19809; Thu, 2 Nov 95 10:23:07 -0800 Message-Id: Date: 2 Nov 1995 10:28:11 -0800 From: "iniewski" Subject: unsubscribe To: "ib is" X-Mailer: Mail*Link SMTP-QM 3.0.2 unsubscribe From Will_Hobbs@ccm.jf.intel.com Mon Nov 6 17:17:58 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15664; Mon, 6 Nov 95 17:17:58 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCcYS-000V22C; Mon, 6 Nov 95 17:10 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCcPl-000txMC; Mon, 6 Nov 95 17:01 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Mon, 06 Nov 95 17:01:25 PST Date: Mon, 06 Nov 95 16:57:00 PST From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: January Face to Face IBISians, At our January summit, I would like to suggest an organization to the meeting: we've generally mixed the presentations between model providers, EDA vendors, and others. I'd like to make the divisions a bit more crisp, so we can pursue some common themes that various groups might have. I suggest we divide the meeting into the following sections: 1. Semiconductor Vendors and their plans and concerns, such as: - Model generation - Model guarantee - Test issues - ... 2. Other Model Providers (same issues) 3. Users and their concerns - Obtaining models they need - Trusting the models - Getting the information in the model that is critical (what do they use/need the models for and when?) - ... 4. EDA vendors and their plans and concerns Finally, leave room for several open session topics. Any comments or amplifications to this? Will Hobbs Chair, EIA IBIS Committee Intel Corp. From Will_Hobbs@ccm.jf.intel.com Tue Nov 7 09:54:55 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27478; Tue, 7 Nov 95 09:54:55 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCs7K-000Uk9C; Tue, 7 Nov 95 09:47 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCs7I-000twYC; Tue, 7 Nov 95 09:47 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Tue, 07 Nov 95 09:47:24 PST Date: Tue, 07 Nov 95 09:42:00 PST From: Will Hobbs Message-Id: To: Arpad_Muranyi@ccm.fm.intel.com Cc: ibis@vhdl.org Subject: Re[2]: January Face to Face Text item: Arpad, Thanks. It is a fifth category, and should be addressed. I posted my question/suggestion to call attention to the fact that a whole class of issues never addressed by the forum, the IC vendors' test problem, needs addressing and could benefit from mutual discussion. I hope you don't mind that I posted this reply to the reflector. >Will >Which category would "what goes into IBIS3 and when will it happen" belong to? >I feel we will need some time for those topics also. Arpad =============================================================================== IBISians, At our January summit, I would like to suggest an organization to the meeting: we've generally mixed the presentations between model providers, EDA vendors, and others. I'd like to make the divisions a bit more crisp, so we can pursue some common themes that various groups might have. I suggest we divide the meeting into the following sections: 1. Semiconductor Vendors and their plans and concerns, such as: - Model generation - Model guarantee - Test issues - ... 2. Other Model Providers (same issues) 3. Users and their concerns - Obtaining models they need - Trusting the models - Getting the information in the model that is critical (what do they use/need the models for and when?) - ... 4. EDA vendors and their plans and concerns Finally, leave room for several open session topics. Any comments or amplifications to this? Will Hobbs Chair, EIA IBIS Committee Intel Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: January Face to Face To: ibis@vhdl.org Message-Id: From: Will Hobbs Date: Mon, 06 Nov 95 16:57:00 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Mon, 06 Nov 95 17:01:25 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCcPl-000txMC; Mon, 6 Nov 95 17:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCcYS-000V22C; Mon, 6 Nov 95 17:10 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15664; Mon, 6 Nov 95 17:17:58 PST Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA04837; Mon, 6 Nov 95 17:24:42 PST Received: from SSD.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tCcmM-000txKC; Mon, 6 Nov 95 17:24 PST From Arpad_Muranyi@ccm.fm.intel.com Tue Nov 7 12:28:32 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28405; Tue, 7 Nov 95 12:28:32 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCuW0-000UdiC; Tue, 7 Nov 95 12:21 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCuKR-000twpC; Tue, 7 Nov 95 12:09 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Tue, 07 Nov 95 12:09:07 PST Date: Tue, 07 Nov 95 12:03:00 PST From: Arpad Muranyi Message-Id: To: Will_Hobbs@ccm.jf.intel.com, ibis@vhdl.org Subject: Re[3]: January Face to Face Text item: Will, No, I don't mind at all, I just wasn't sure whether what I suggested was already part of any of your items, and I did not want to make a fool of myself in the open public. On the other hand, I agree with your topics. Now, taking into consideration the IC vendors' problems, do you think we should invite people from companies, who do not attend the Open Forum yet? I mean to have companies other than National Semiconductor and Intel represented. After all, tool vendors would not know much about IC vendors' problems, and the Open Forum consists primarily of tool vendors... Of course the next question will be: is one day enough for addressing all these topics? Arpad =============================================================================== Arpad, Thanks. It is a fifth category, and should be addressed. I posted my question/suggestion to call attention to the fact that a whole class of issues never addressed by the forum, the IC vendors' test problem, needs addressing and could benefit from mutual discussion. I hope you don't mind that I posted this reply to the reflector. >Will >Which category would "what goes into IBIS3 and when will it happen" belong to? >I feel we will need some time for those topics also. Arpad =============================================================================== IBISians, At our January summit, I would like to suggest an organization to the meeting: we've generally mixed the presentations between model providers, EDA vendors, and others. I'd like to make the divisions a bit more crisp, so we can pursue some common themes that various groups might have. I suggest we divide the meeting into the following sections: 1. Semiconductor Vendors and their plans and concerns, such as: - Model generation - Model guarantee - Test issues - ... 2. Other Model Providers (same issues) 3. Users and their concerns - Obtaining models they need - Trusting the models - Getting the information in the model that is critical (what do they use/need the models for and when?) - ... 4. EDA vendors and their plans and concerns Finally, leave room for several open session topics. Any comments or amplifications to this? Will Hobbs Chair, EIA IBIS Committee Intel Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: January Face to Face To: ibis@vhdl.org Message-Id: From: Will Hobbs Date: Mon, 06 Nov 95 16:57:00 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Mon, 06 Nov 95 17:01:25 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCcPl-000txMC; Mon, 6 Nov 95 17:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCcYS-000V22C; Mon, 6 Nov 95 17:10 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15664; Mon, 6 Nov 95 17:17:58 PST Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA04837; Mon, 6 Nov 95 17:24:42 PST Received: from SSD.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tCcmM-000txKC; Mon, 6 Nov 95 17:24 PST From Will_Hobbs@ccm.jf.intel.com Tue Nov 7 13:50:39 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28958; Tue, 7 Nov 95 13:50:39 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCvnS-000UhcC; Tue, 7 Nov 95 13:43 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCvnS-000twWC; Tue, 7 Nov 95 13:43 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Tue, 07 Nov 95 13:43:10 PST Date: Tue, 07 Nov 95 13:40:00 PST From: Will Hobbs Message-Id: To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: January Face to Face, and, calling all IC vendors Text item: Arpad, I think 1 day will be aggressive, but will leave us energized to go out and conquer the world. Two days would be enough time to cover stuff in much more detail, but I fear everyone would go away drained. A 1 day meeting forces us to stay on track, which is a good thing. It's also easier to schedule around. I suppose I could be persuaded otherwise, though. Regarding getting other IC vendors to actively participate, this mailing list contains people in probably a dozen IC companies, and hopefully this mail will entice them to comment and participate. I'm not opposed to having people actively solicited either. So, here is a call to arms: How about a show of strength from the semiconductor manufacturers? I would like to see your concerns, plans, issues, problems, questions, etc., aired and I'd like to see your participation in the January meeting. Will Will, No, I don't mind at all, I just wasn't sure whether what I suggested was already part of any of your items, and I did not want to make a fool of myself in the open public. On the other hand, I agree with your topics. Now, taking into consideration the IC vendors' problems, do you think we should invite people from companies, who do not attend the Open Forum yet? I mean to have companies other than National Semiconductor and Intel represented. After all, tool vendors would not know much about IC vendors' problems, and the Open Forum consists primarily of tool vendors... Of course the next question will be: is one day enough for addressing all these topics? Arpad =============================================================================== Arpad, Thanks. It is a fifth category, and should be addressed. I posted my question/suggestion to call attention to the fact that a whole class of issues never addressed by the forum, the IC vendors' test problem, needs addressing and could benefit from mutual discussion. I hope you don't mind that I posted this reply to the reflector. >Will >Which category would "what goes into IBIS3 and when will it happen" belong to? >I feel we will need some time for those topics also. Arpad =============================================================================== IBISians, At our January summit, I would like to suggest an organization to the meeting: we've generally mixed the presentations between model providers, EDA vendors, and others. I'd like to make the divisions a bit more crisp, so we can pursue some common themes that various groups might have. I suggest we divide the meeting into the following sections: 1. Semiconductor Vendors and their plans and concerns, such as: - Model generation - Model guarantee - Test issues - ... 2. Other Model Providers (same issues) 3. Users and their concerns - Obtaining models they need - Trusting the models - Getting the information in the model that is critical (what do they use/need the models for and when?) - ... 4. EDA vendors and their plans and concerns Finally, leave room for several open session topics. Any comments or amplifications to this? Will Hobbs Chair, EIA IBIS Committee Intel Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: January Face to Face To: ibis@vhdl.org Message-Id: From: Will Hobbs Date: Mon, 06 Nov 95 16:57:00 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Mon, 06 Nov 95 17:01:25 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tCcPl-000txMC; Mon, 6 Nov 95 17:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tCcYS-000V22C; Mon, 6 Nov 95 17:10 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15664; Mon, 6 Nov 95 17:17:58 PST Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA04837; Mon, 6 Nov 95 17:24:42 PST Received: from SSD.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tCcmM-000txKC; Mon, 6 Nov 95 17:24 PST From huq@rockie.nsc.com Tue Nov 7 14:43:38 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29326; Tue, 7 Nov 95 14:43:38 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA08725 for ibis@vhdl.org; Tue, 7 Nov 95 14:33:25 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA12199 for Arpad_Muranyi@ccm.fm.intel.com; Tue, 7 Nov 95 14:33:13 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA13123; Tue, 7 Nov 95 14:33:42 PST Date: Tue, 7 Nov 95 14:33:42 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9511072233.AA13123@rockie.nsc.com> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org, Will_Hobbs@ccm.jf.intel.com Subject: Re: January Face to Face, and, calling all IC vendors Will, Great idea about semiconductor vendor participation. Since EDA tool vendors deal with a lot of semiconductor vendors, I think it would great if some of these EDA guys stir up some more interest(eg..HyperLynx has done great in contacting Xilinx..) Hope to see more participation.. Syed. National Semiconductor. > > > Text item: > > Arpad, > > I think 1 day will be aggressive, but will leave us energized to go out and > conquer the world. Two days would be enough time to cover stuff in much more > detail, but I fear everyone would go away drained. A 1 day meeting forces us to > stay on track, which is a good thing. It's also easier to schedule around. I > suppose I could be persuaded otherwise, though. > > Regarding getting other IC vendors to actively participate, this mailing list > contains people in probably a dozen IC companies, and hopefully this mail will > entice them to comment and participate. I'm not opposed to having people > actively solicited either. > > So, here is a call to arms: How about a show of strength from the semiconductor > manufacturers? I would like to see your concerns, plans, issues, problems, > questions, etc., aired and I'd like to see your participation in the January > meeting. > > Will From bob@icx.com Wed Nov 8 15:33:31 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13825; Wed, 8 Nov 95 15:33:31 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Nov 95 15:25 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Nov 95 15:28 PST Message-Id: Date: Wed, 8 Nov 95 15:28 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Face-to-Face 96 To Ibisians: I support Will's proposal for devoting a chunk of meeting time to the aspects and issues of IBIS model development/validation/distribution/ support, etc. from different player's points of view. However, I also agree with Arpad that technical issues related to Version 3.0 improvements need discussion. I see a stack of previously raised subjects and possible new subjects. I expect some of the (old, open) subjects raised with respect to solid proposals. Examples of such subjects are stored charge, feedback mechanism, multistaged switching, physical package/mcm representation, ground/power noise, ttl/cmos differences, connectors & cables, etc. So we should also have a rich technical session which provide some more Version 3.0 improvements. Bob Ross Interconnectix, Inc. From Arpad_Muranyi@ccm.fm.intel.com Wed Nov 8 16:10:20 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14017; Wed, 8 Nov 95 16:10:20 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tDKS7-000Uk5C; Wed, 8 Nov 95 16:02 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tDKS7-000twYC; Wed, 8 Nov 95 16:02 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Wed, 08 Nov 95 16:02:47 PST Date: Wed, 08 Nov 95 15:57:00 PST From: Arpad Muranyi Message-Id: To: bob@icx.com, ibis@vhdl.org Subject: Re: IBIS Face-to-Face 96 Text item: Bob, Will, and all IBIS fans, You have a valid point. I must repeat my fear that with such a reach agenda one day might not be enough. In my experience these kind of meetings could always have been longer. On the other hand, I see Will's point also about burnout. Would it make sense to have one day for the technical topics Bob listed, and another day for the topics on problems of IC vendors, etc. Will wrote about? That way people not interested in one or the other session might not have to come for both days, even though every one would be welcomed. Of course, it would be just as difficult for me to decide which day I should go as taking off two days from my regular work... Arpad ================================================================================ To Ibisians: I support Will's proposal for devoting a chunk of meeting time to the aspects and issues of IBIS model development/validation/distribution/ support, etc. from different player's points of view. However, I also agree with Arpad that technical issues related to Version 3.0 improvements need discussion. I see a stack of previously raised subjects and possible new subjects. I expect some of the (old, open) subjects raised with respect to solid proposals. Examples of such subjects are stored charge, feedback mechanism, multistaged switching, physical package/mcm representation, ground/power noise, ttl/cmos differences, connectors & cables, etc. So we should also have a rich technical session which provide some more Version 3.0 improvements. Bob Ross Interconnectix, Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS Face-to-Face 96 To: ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Wed, 8 Nov 95 15:28 PST Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Nov 95 15:28 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Nov 95 15:25 PST Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13825; Wed, 8 Nov 95 15:33:31 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Nov 95 15: 33:36 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tDK0Y-000twXC; Wed, 8 Nov 95 15:34 PST From uunet!qdt.com!jonp@uunet.uu.net Wed Nov 8 18:17:58 1995 Return-Path: Received: from relay5.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15014; Wed, 8 Nov 95 18:17:58 PST Received: from uucp1.UU.NET by relay5.UU.NET with SMTP id QQzpau17441; Wed, 8 Nov 1995 21:06:34 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 8 Nov 1995 21:06:38 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01262; Wed, 8 Nov 95 17:40:04 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA07573; Wed, 8 Nov 95 17:40:04 PST Received: from uucp4.UU.NET by relay5.UU.NET with SMTP id QQzpas11589; Wed, 8 Nov 1995 20:35:41 -0500 (EST) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 8 Nov 1995 20:35:42 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01165; Wed, 8 Nov 95 17:00:33 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA07218; Wed, 8 Nov 95 17:00:33 PST Date: Wed, 8 Nov 95 17:00:33 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9511090100.AA07218@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA03074; Wed, 8 Nov 95 17:00:32 PST To: uunet!uunet!ccm.fm.intel.com!Arpad_Muranyi@uunet.uu.net Cc: uunet!uunet!icx.com!bob@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: (uunet!ccm.fm.intel.com!Arpad_Muranyi) Subject: Re: IBIS Face-to-Face 96 Do IC vendors come to DAC? Maybe we could target another meeting (maybe even on that other coast) that was targetted specifically at IC vendor interests. jon From huq@rockie.nsc.com Thu Nov 9 00:01:41 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17038; Thu, 9 Nov 95 00:01:41 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA24112 for ibis@vhdl.org; Wed, 8 Nov 95 23:54:12 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA06969 for ibis@vhdl.org; Wed, 8 Nov 95 23:54:10 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA17069; Wed, 8 Nov 95 23:54:40 PST Date: Wed, 8 Nov 95 23:54:40 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9511090754.AA17069@rockie.nsc.com> To: ibis@vhdl.org Subject: The face to face meeting IBISgurus, I can tell the excitement from all the responses on the reflector for the Jan29th(Mon) 1996 meeting. We have to remember that TUE/WED/THURS is DesignSuperCon'96 and quite a number of us will be attending that. This may make a 2 day IBIS meeting very difficult for some of us. We may have to come up with a precise agenda in order to cover all that we are talking about in a day. Regards, Syed National Semiconductor From rhughson@BayNetworks.com Thu Nov 9 06:46:25 1995 Return-Path: Received: from lobster.wellfleet.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24358; Thu, 9 Nov 95 06:46:25 PST Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21265; Thu, 9 Nov 95 09:37:52 EST Received: from aurora.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA08600; Thu, 9 Nov 95 09:38:52 EST Date: Thu, 9 Nov 95 09:38:52 EST From: rhughson@BayNetworks.com (Rick Hughson) Message-Id: <9511091438.AA08600@pobox.BayNetworks.com> To: ibis@vhdl.org unsubscribe From EGJJ77A@mail.prodigy.com Thu Nov 9 08:49:06 1995 Return-Path: Received: from pimaia2w.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25155; Thu, 9 Nov 95 08:49:06 PST Received: from mail.prodigy.com ([199.4.137.13]) by pimaia2w.prodigy.com (8.6.10/8.6.9) with SMTP id LAA46884; Thu, 9 Nov 1995 11:08:14 -0500 Date: Thu, 09 Nov 1995 11:06:16 EST From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.04474002.EGJJ77A@prodigy.com> To: cottrell@cfi.org, john_beatty@vnet.ibm.com, steve.grout@sematech.org, ovidc-arch@chronologic.com, ibis@vhdl.org Subject: Fwd: Re: IBIS Minutes 10/27/95 -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Don and John Beatty, System delay will have this same problem. A standard mechanism is required so that the same optional buffer I/O configuration is chosen for the IBIS model as is chosen for the abstracted delay model. The IBIS folk believe that the criteria for choosing the proper programmable buffer I/O model is sometimes too complex to automate based on design data. A standard selection file used by IBIS and the delay process could be one answer. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Thursday, 02-Nov-95 12:42 PM > > From: Arpad Muranyi \ Internet: > (arpad_muranyi@ccm.fm.intel.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re: IBIS Minutes 10/27/95 > > Text item: > > Jon, > > Reading the minutes, I see your concern about large boards. However, I > don't think that this can only be done through interactive user > interface. > > The simulator tool could have a macro, or an external buffer selection > response file, or simulation configuration file, or something like that, > through which the "user responses" (buffer selections other than > defaults) are all available (predetermined). > > With this method you have an option to do it completely invisibly (as in a > batch job which runs overnight), as well as through interactive user > interface (as in experimenting and what if simulations). > > Arpad > ======================================================================= == > ====== > BIRD30.2 - PIN PROGRAMMABLE BUFFER STRENGTHS > Arpad Muranyi discussed BIRD30.2 with a text revision. Some discussion > including its relationship to DCL (Delay Calculation Language) > standardization > with respect to dynamically selectable buffers was initiated by Ron > Christopher. Several ideas to select models including ordering were > discussed. The consensus was that the actual selection basis was too > complicated to come to an agreement at this time. The description syntax > could be standardized, but proposals would have to be developed and > considered. > > The current proposal allows manual selection through a graphical user > interface (GUI) with no standardization on descriptions. Jon Powell > stated that this could work for One device considerations, but the > concern > is that it would be a very cumbersome process for working with a large > board with many IBIS model files from several vendors. > > BIRD30.2 was approved by the Vote. > > Proposals the improve upon BIRD30.2 would be considered. > > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > Subject: IBIS Minutes 10/27/95 > To: ibis@vhdl.org > From: bob@icx.com ( Bob Ross) > Date: Wed, 1 Nov 95 14:16 PST > Message-Id: > Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 1 Nov 95 14:16 PST > Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 1 Nov 95 14:13 PST > Received: from icx.com (icx.rain.com) by vhdl.vhdl.org > (4.1/SMI-4.1/BARRNet) > id AA09681; Wed, 1 Nov 95 14:21:15 PST > Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 1 Nov > 95 14: > 19:52 -0800 > Received: from hermes.intel.com by relay.jf.intel.com with smtp > (Smail3.1.28.1 #2) id m0tAuTm-000twVC; Wed, 1 Nov 95 23:54 PST > > > ------- FORWARD, End of original message ------- From bob@icx.com Thu Nov 9 09:14:20 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25313; Thu, 9 Nov 95 09:14:20 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 9 Nov 95 09:06 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 9 Nov 95 09:09 PST Message-Id: Date: Thu, 9 Nov 95 09:09 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: ibis-request@vhdl.org To IBISians: This is a reminder that if you wish to subscribe or unsubscribe to the IBIS reflector, please use ibis-request@vhdl.org. This address is always noted at the bottom of the IBIS Minutes. Thanks, Bob Ross IBIS Open Forum Secretary Phone (503) 603-2523, Fax (503) 639-3469 bob@icx.com Interconnectix, Inc., 10220 S.W. Nimbus Ave., K4, Portland, OR 97223 From grege@chensys.com Thu Nov 9 11:14:24 1995 Return-Path: Received: from human.chensys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26170; Thu, 9 Nov 95 11:14:24 PST Received: from puma.chensys.com by human.chensys.com (8.6.10/SMI-4.1) id TAA19046; Thu, 9 Nov 1995 19:12:10 GMT Received: from [137.42.2.33] by puma.chensys.com via SMTP (931110.SGI/930416.SGI) for @chensys.com:ibis@vhdl.org id AA06928; Thu, 9 Nov 95 13:01:50 -0600 Date: Thu, 9 Nov 95 13:01:50 -0600 Message-Id: <9511091901.AA06928@puma.chensys.com> X-Sender: gre@pop3.chensys.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: grege@chensys.com (Greg Edlund) Subject: IBIS modeling questions Anybody care to take a stab at these? 1. I was discussing IBIS model support with one of our IC vendors, and they raised a concern about ESD diode SPICE models not being accurate at -5 V and + 10 V. Any clues about how to get around this without setting up a test lab? Why do you need such a wide range in the first place, since nobody operates out there? 2. When will s2ibis 2.0 be available on Windows? Actually, I'd be happy with DOS, but that's probably not in the plan... 3. Has anybody written a "theory of operations" paper on behavioral simulators? For instance, if I have a simple behavioral driver model (no ESD diodes, no package) driving a 50 Ohm transmission line terminated at the far end into 50 Ohms, how do I calculate the current and voltage vs. time at the output of the driver? At the far end? This must be an easy problem to solve. I'd like to write a little C program to do this so I can better understand IBIS and critically compare it to SPICE. (For the sake of accuracy in system design issues, not so I can write another simulator!) 4. Has anybody thought about organizing an IBIS users group and mailing list? Thanks in advance, -- Greg Edlund +----+----+ Circuits and Modeling | | | Chen Systems Corp. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) voice (715) 833-7067 > | ) FAX (715) 833-7096 | | | email grege@chensys.com +----+----+ From Will_Hobbs@ccm.jf.intel.com Thu Nov 9 12:18:19 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26926; Thu, 9 Nov 95 12:18:19 PST Received: from ormail.intel.com by relay3.UU.NET with SMTP id QQzpdo15528; Thu, 9 Nov 1995 15:06:38 -0500 (EST) Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tDdF7-000UhlC; Thu, 9 Nov 95 12:06 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tDdF0-000twWC; Thu, 9 Nov 95 12:06 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Thu, 09 Nov 95 12:06:30 PST Date: Thu, 09 Nov 95 11:58:00 PST From: Will Hobbs Message-Id: To: jonp%qdt.com%uunet@uunet.uu.net, uunet!uunet!ccm.fm.intel.com!Arpad_Muranyi@uunet.uu.net Cc: uunet!uunet!icx.com!bob@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re[2]: IBIS Face-to-Face 96 Text item: Jon, There's another coast?!? Seriously, I think that IC vendors are major attendees at DAC, so I don't think we're being exclusionary. Also, I feel that we need to have a forum that is well represented by all sides of the equation-- I think end users, EDA vendors, model developers and IC vendors will benefit from each others' stories. I really can't think of a better forum than DAC, but I'm certainly open to suggestions as long as we have a reasonable chance of having all groups represented. Will Do IC vendors come to DAC? Maybe we could target another meeting (maybe even on that other coast) that was targetted specifically at IC vendor interests. jon Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: IBIS Face-to-Face 96 In-Reply-To: (uunet!ccm.fm.inte l.com!Arpad_Muranyi) Cc: uunet!uunet!icx.com!bob@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net To: uunet!uunet!ccm.fm.intel.com!Arpad_Muranyi@uunet.uu.net Received: by f14.qdt.com (4.1/SMI-4.1) id AA03074; Wed, 8 Nov 95 17:00:32 PST Message-Id: <9511090100.AA07218@hal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Wed, 8 Nov 95 17:00:33 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA07218; Wed, 8 Nov 95 17:00:33 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01165; Wed, 8 Nov 95 17:00:33 PST Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 8 Nov 1995 20:35:42 -0500 Received: from uucp4.UU.NET by relay5.UU.NET with SMTP id QQzpas11589; Wed, 8 Nov 1995 20:35:41 -0500 (EST) Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA07573; Wed, 8 Nov 95 17:40:04 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01262; Wed, 8 Nov 95 17:40:04 PST Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 8 Nov 1995 21:06:38 -0500 Received: from uucp1.UU.NET by relay5.UU.NET with SMTP id QQzpau17441; Wed, 8 Nov 1995 21:06:34 -0500 (EST) Received: from relay5.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15014; Wed, 8 Nov 95 18:17:58 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Nov 95 18: 49:31 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 8 Nov 95 18:49:38 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tDN3d-000twXC; Wed, 8 Nov 95 18:49 PST From Arpad_Muranyi@ccm.fm.intel.com Thu Nov 9 12:33:01 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27055; Thu, 9 Nov 95 12:33:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tDdXK-000Um1C; Thu, 9 Nov 95 12:25 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tDdXI-000twaC; Thu, 9 Nov 95 12:25 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Thu, 09 Nov 95 12:25:23 PST Date: Thu, 09 Nov 95 12:19:00 PST From: Arpad Muranyi Message-Id: To: grege@chensys.com, ibis@vhdl.org Subject: Re: IBIS modeling questions Text item: Greg, I will make an attempt to answer some of your questions. 1) To be more accurate, the requirement is -Vcc to +2*Vcc. There are two reasons for this. First, in an idealized situation, you can have a 100 % reflection at the unterminated end of a transmission line. If you have a strong buffer driving it (again in an ideal situation), it can switch a full swing (i.e. 5 volts to 0 volts). Under conditions like this it is possible to have a -5 volt undershoot at the unterminated end (receiver). The amount of undershoot (or overshoot for a rising edge) at the receiver will greatly depend on the clamping characteristics of the input structure. Second, different simulators extrapolate I-V curves differently (horizontally, vertically, linearly, or any other way). The best way to ensure that the curve is "correct" in the required range (-Vcc to +2*Vcc) is to define it. Now, we all know that not all real devices can be measured all the way in this range (even though I did succeed measuring some). However, you can do your best in the lab and then extrapolate the curve to the required limits. Most often these curves become a straight line because the resistive properties of the diodes dominate their exponential nature beyond a certain voltaqe. If you simulate this with a SPICE model, don't worry about hair splitting accuracy at the limits. The point is to define something to the best of your knowledge that otherwise might get messed up. However, I would recommend that the curve be fairly accurate in the range of Vcc and GND +/- 1-2 volts, since most over and undershoots could have such magnitudes. On the other hand, if your SPICE model gives you kilo, Giga and Tera amp currents at -1 to -2 or +6 to +7 volts for a 5 V device, you better make sure that the resistive properties of the diodes and transistors are modeled correctly in the SPICE model. If these are ignored, the defult number in SPICE is usually 0 for the resistance, and the pure junction and channel current equations can indeed yield currents in the kilo amp range already at -1 volts! Real life measurements would give around 5-10 amps around -5 volts (~ couple of Ohms slope). For example the voltage in the exponential diode equation refers to the junction voltage, which is not the same as the voltage at the terminals of the diode. The current has to go through a significant chunk of resistive material before it gets to the junctions where you are actually making you connection to the device. 2) I don't know the answer to this one. 3) You can do that by "programming" what Lattice diagrams or Bergeron diagrams do graphically. As far as how to construct these, you could probably find text books or other literature (app notes in high speed logic data books) on the subject. (I was born with this knowledge, so I am not sure where to find this info... :-) 4) It was discussed in some of the IBIS Open Forum meetings, but I don't remeber what the outcome was. Maybe someone else could answer that? I hope I gave you some insight with this reply. Arpad Muranyi Intel Corporation ================================================================================ Anybody care to take a stab at these? 1. I was discussing IBIS model support with one of our IC vendors, and they raised a concern about ESD diode SPICE models not being accurate at -5 V and + 10 V. Any clues about how to get around this without setting up a test lab? Why do you need such a wide range in the first place, since nobody operates out there? 2. When will s2ibis 2.0 be available on Windows? Actually, I'd be happy with DOS, but that's probably not in the plan... 3. Has anybody written a "theory of operations" paper on behavioral simulators? For instance, if I have a simple behavioral driver model (no ESD diodes, no package) driving a 50 Ohm transmission line terminated at the far end into 50 Ohms, how do I calculate the current and voltage vs. time at the output of the driver? At the far end? This must be an easy problem to solve. I'd like to write a little C program to do this so I can better understand IBIS and critically compare it to SPICE. (For the sake of accuracy in system design issues, not so I can write another simulator!) 4. Has anybody thought about organizing an IBIS users group and mailing list? Thanks in advance, -- Greg Edlund +----+----+ Circuits and Modeling | | | Chen Systems Corp. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) voice (715) 833-7067 > | ) FAX (715) 833-7096 | | | email grege@chensys.com +----+----+ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS modeling questions From: grege@chensys.com (Greg Edlund) To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 X-Sender: gre@pop3.chensys.com Message-Id: <9511091901.AA06928@puma.chensys.com> Date: Thu, 9 Nov 95 13:01:50 -0600 Received: from [137.42.2.33] by puma.chensys.com via SMTP (931110.SGI/930416.SGI ) for @chensys.com:ibis@vhdl.org id AA06928; Thu, 9 Nov 95 13:01:50 -0600 Received: from puma.chensys.com by human.chensys.com (8.6.10/SMI-4.1) id TAA19046; Thu, 9 Nov 1995 19:12:10 GMT Received: from human.chensys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26170; Thu, 9 Nov 95 11:14:24 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 9 Nov 95 11: 10:36 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tDcQ4-000twZC; Thu, 9 Nov 95 11:13 PST From fvance@firepower.com Thu Nov 9 12:52:13 1995 Return-Path: Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27155; Thu, 9 Nov 95 12:52:13 PST Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by firepower.com (8.7.1/8.7.1) with ESMTP id MAA21114; Thu, 9 Nov 1995 12:43:21 -0800 (PST) Received: from protocol.FirePower.COM (protocol.firepower.com [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id MAA17874; Thu, 9 Nov 1995 12:44:36 -0800 (PST) From: Fred Vance Message-Id: <199511092044.MAA17874@freedom.firepower.com> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02374; Thu, 9 Nov 95 12:44:34 -0800 Date: Thu, 9 Nov 95 12:44:34 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: grege@chensys.com (Greg Edlund) Subject: Re: IBIS modeling questions Cc: ibis@vhdl.org Hi Greg, You wrote: >To: ibis@vhdl.org >From: grege@chensys.com (Greg Edlund) >Subject: IBIS modeling questions > >Anybody care to take a stab at these? > I'll give it a try. >1. I was discussing IBIS model support with one of > our IC vendors, and they raised a concern about > ESD diode SPICE models not being accurate at > -5 V and + 10 V. Any clues about how to get > around this without setting up a test lab? Why > do you need such a wide range in the first place, > since nobody operates out there? I think that some simulators use the last couple of points to extrapolate out to infinity or some asymptotic value, so if your data is not available over the full range, you can probably do the same. Maybe it doesn't matter whether the full range is provided. It might depend on a simulator's interpretation of the IBIS specification. If I remember correctly, using the full range is optional in the latest IBIS revision. (Someone help me here.) >2. When will s2ibis 2.0 be available on Windows? > Actually, I'd be happy with DOS, but that's > probably not in the plan... > I believe someone would be glad to make the source code available to you. Since you seem to have some experience with C compiling, you might be the right person to create the DOS/Windows executable and upload it to ibis@vhdl.org. >3. Has anybody written a "theory of operations" > paper on behavioral simulators? For instance, if > I have a simple behavioral driver model (no ESD > diodes, no package) driving a 50 Ohm transmission > line terminated at the far end into 50 Ohms, how > do I calculate the current and voltage vs. time at > the output of the driver? At the far end? This > must be an easy problem to solve. I'd like to > write a little C program to do this so I can better > understand IBIS and critically compare it to SPICE. > (For the sake of accuracy in system design issues, > not so I can write another simulator!) > Maybe, I can't really say. I believe the way to approach this is to use piece-wise linear dependent functions to control a conductance to Vdd, simulating a pull-up switch and one to Gnd simulating a pull-down switch. The independent variable controlling the dependent conductance functions would be the voltage at the driver's output pad. Both conductance switches also need to be dependent on the pin's logic state and need to make a transition between states at a controlled rate using the dV/dt information in the IBIS. The state transition would have to occur based on some threshold value and the buffer's input level. Sounds simple, only the details get in the way. >4. Has anybody thought about organizing an IBIS > users group and mailing list? > This is it, I think. I would be happy to discuss the "theory of operations" of behavioral simulators in more detail. I agree that for the "sake of accuracy in system design issues" it is good to know issues and limitations involved with behavioral model simulations. It may be difficult to discuss IBIS models independent of a specific simulator, but might be interesting to try. Regards, Fred Vance FirePower Systems, Inc. (415) 462-3055 Phone (415) 462-3051 Fax From idodd@ian.edaco.ingr.com Thu Nov 9 13:47:48 1995 Return-Path: Received: from ian.edaco.ingr.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27519; Thu, 9 Nov 95 13:47:48 PST Received: by ian.edaco.ingr.com (4.1/SMI-4.1) id AA01092; Thu, 9 Nov 95 14:37:58 MST Date: Thu, 9 Nov 95 14:37:58 MST From: idodd@ian.edaco.ingr.com (Ian Dodd) Message-Id: <9511092137.AA01092@ian.edaco.ingr.com> To: ibis@vhdl.org Subject: Re: IBIS modelling questions Good answer Arpad, Adding to your response on programming .... William Blood gives a pretty good description of the Lattice diagram technique in Motorolas MECL System Design Handbook (Chapter 7, Transmission Line Theory) Ian C Dodd Intergraph Electronics idodd@ingr.com From kellee@alaska.nwlink.com Thu Nov 9 14:30:49 1995 Return-Path: Received: from alaska.nwlink.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27769; Thu, 9 Nov 95 14:30:49 PST Received: (from kellee@localhost) by alaska.nwlink.com (8.6.12/8.6.9) id OAA15962; Thu, 9 Nov 1995 14:32:06 -0800 Date: Thu, 9 Nov 1995 14:32:06 -0800 Message-Id: <199511092232.OAA15962@alaska.nwlink.com> X-Sender: kellee@hyperlynx.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: Kellee Crisafulli Subject: IBIS modeling questions response to greg Edlund Hi Greg, I will take a crack at answering your questions: >1. I was discussing IBIS model support with one of > our IC vendors, and they raised a concern about > ESD diode SPICE models not being accurate at > -5 V and + 10 V. Any clues about how to get > around this without setting up a test lab? Why > do you need such a wide range in the first place, > since nobody operates out there? You can extrapolate the data relatively easily to -5V and +10V. If each vendor extrapolates the data independently there is no way to sure how it will be extrapolated. Linear? exponential?, clipped?. For many devices it needs to be clipped, for others a linear extrapolation is better. The reason we specified it out that far is to prevent anything strange from happening with any given simulator after the last data point. This way we know that all the simulators at least in theory should operate the same at least within -5V to +10V. This should insure stable and accurate operation under all normal operating conditions. >2. When will s2ibis 2.0 be available on Windows? > Actually, I'd be happy with DOS, but that's > probably not in the plan... I have given this a first pass and had some trouble getting the source code to compile. I will try it again soon when I get a few spare hours. >3. Has anybody written a "theory of operations" > paper on behavioral simulators? For instance, if > I have a simple behavioral driver model (no ESD > diodes, no package) driving a 50 Ohm transmission > line terminated at the far end into 50 Ohms, how > do I calculate the current and voltage vs. time at > the output of the driver? At the far end? This > must be an easy problem to solve. I'd like to > write a little C program to do this so I can better > understand IBIS and critically compare it to SPICE. > (For the sake of accuracy in system design issues, > not so I can write another simulator!) There are several books on this subject. Visit your local book store and look under transmission lines, signal integrity, microstrip, and stripline. The easier method is to buy one of the cheaper programs on the market that already does the it for you. There are several that support IBIS. If you need a reference let me know. >4. Has anybody thought about organizing an IBIS > users group and mailing list? This has been talked about a few times. It hasn't gotten enough steam up to make the engine run yet. Have a great day...Kellee Crisafulli, HyperLynx Inc. From bob@icx.com Thu Nov 9 14:51:26 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28014; Thu, 9 Nov 95 14:51:26 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 9 Nov 95 14:43 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 9 Nov 95 12:44 PST Message-Id: Date: Thu, 9 Nov 95 14:46 PST From: bob@icx.com ( Bob Ross) To: grege@chensys.com, ibis@vhdl.org Subject: Re: IBIS modeling questions Greg: Here are some brief responses to your questions. (1) Arpad covered that one well. (2) We seem to be having a problem in compiling a Windows verion of s2ibis2 which seems difficult to resolve, so I cannot give a date or committment. (3) I do not know of any theory of operation of behavioral models (even from CAE vendors), but many vendors use IBIS models or translated versions for simulation with excellent results and correlation with Spice Models. So while vendors are not necessarily open about all the details of their internal algorithms, the fundamental IBIS architecture gives enough detail for using IBIS models in simulation. IBIS models work well in tranmission line simulations. (4) There was extensive discussion regarding an IBIS USERS group last February and March. There was agreement of the need, but we got bogged down in what specific from it should take. After discussing this with Will Hobbs, I intend to set up a users mail group reflector. This may take several days or a week. This will be announced on the IBIS and SI reflectors, and people can join at that time. We can elaborate elsewhere on what the scope and rules should be, but this is basically an unmoderated group focused on user questions and applying IBIS models. We will archive all of the mail. Bob Ross Interconnectix, Inc. > Date: Thu, 9 Nov 95 13:01:50 -0600 > To: ibis@vhdl.org > From: grege@chensys.com (Greg Edlund) > Subject: IBIS modeling questions > Status: R > Anybody care to take a stab at these? > 1. I was discussing IBIS model support with one of > our IC vendors, and they raised a concern about > ESD diode SPICE models not being accurate at > -5 V and + 10 V. Any clues about how to get > around this without setting up a test lab? Why > do you need such a wide range in the first place, > since nobody operates out there? > 2. When will s2ibis 2.0 be available on Windows? > Actually, I'd be happy with DOS, but that's > probably not in the plan... > 3. Has anybody written a "theory of operations" > paper on behavioral simulators? For instance, if > I have a simple behavioral driver model (no ESD > diodes, no package) driving a 50 Ohm transmission > line terminated at the far end into 50 Ohms, how > do I calculate the current and voltage vs. time at > the output of the driver? At the far end? This > must be an easy problem to solve. I'd like to > write a little C program to do this so I can better > understand IBIS and critically compare it to SPICE. > (For the sake of accuracy in system design issues, > not so I can write another simulator!) > 4. Has anybody thought about organizing an IBIS > users group and mailing list? > Thanks in advance, > -- > Greg Edlund +----+----+ > Circuits and Modeling | | | > Chen Systems Corp. < | ) > 1414 W. Hamilton Ave. > ----- ) > Eau Claire, WI 54701 < ----- ) > voice (715) 833-7067 > | ) > FAX (715) 833-7096 | | | > email grege@chensys.com +----+----+ From Will_Hobbs@ccm.jf.intel.com Thu Nov 9 16:41:56 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28998; Thu, 9 Nov 95 16:41:56 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tDhOy-000UqkC; Thu, 9 Nov 95 16:33 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tDhOy-000twXC; Thu, 9 Nov 95 16:33 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Thu, 09 Nov 95 16:33:04 PST Date: Thu, 09 Nov 95 16:27:00 PST From: Will Hobbs Message-Id: To: fvance@firepower.com, grege@chensys.com Cc: ibis@vhdl.org Subject: Re[2]: IBIS modeling questions Text item: Fred, Greg, Sorry to be a bearer of bad news, but the source code must be licensed, for a fee. There are many companies who have licensed the code, and we are in the process of porting it to various O/S and platforms. When that work is done, the resulting object code will be made freely available on vhdl.org. If you do want to license the parser, here are the details: There are three options for licensing the IBIS Golden Parser source code, V2.1, depending on your membership status in the IBIS committee of EIA: 1) If you are a current member of the IBIS committee, you can license the parser source for an additional $250.00 2) If you are not a member, but would like to be, you can join the committee and license the parser source for a total of $750 3) If you are not a member, and do not wish to become a member, you can license the source for $500. In any case, submit a request to: EIA 2500 Wilson Blvd. Arlington, VA 22201 (703) 907-7545 (phone) (703) 907-7501 (fax) Enclose a check in the appropriate amount made out to EIA. EIA will take care of distributing the source. Regards, Will Hobbs, Chair, EIA IBIS Committee Intel Corp. Hi Greg, You wrote: >To: ibis@vhdl.org >From: grege@chensys.com (Greg Edlund) >Subject: IBIS modeling questions > >Anybody care to take a stab at these? > I'll give it a try. >1. I was discussing IBIS model support with one of > our IC vendors, and they raised a concern about > ESD diode SPICE models not being accurate at > -5 V and + 10 V. Any clues about how to get > around this without setting up a test lab? Why > do you need such a wide range in the first place, > since nobody operates out there? I think that some simulators use the last couple of points to extrapolate out to infinity or some asymptotic value, so if your data is not available over the full range, you can probably do the same. Maybe it doesn't matter whether the full range is provided. It might depend on a simulator's interpretation of the IBIS specification. If I remember correctly, using the full range is optional in the latest IBIS revision. (Someone help me here.) >2. When will s2ibis 2.0 be available on Windows? > Actually, I'd be happy with DOS, but that's > probably not in the plan... > I believe someone would be glad to make the source code available to you. Since you seem to have some experience with C compiling, you might be the right person to create the DOS/Windows executable and upload it to ibis@vhdl.org. >3. Has anybody written a "theory of operations" > paper on behavioral simulators? For instance, if > I have a simple behavioral driver model (no ESD > diodes, no package) driving a 50 Ohm transmission > line terminated at the far end into 50 Ohms, how > do I calculate the current and voltage vs. time at > the output of the driver? At the far end? This > must be an easy problem to solve. I'd like to > write a little C program to do this so I can better > understand IBIS and critically compare it to SPICE. > (For the sake of accuracy in system design issues, > not so I can write another simulator!) > Maybe, I can't really say. I believe the way to approach this is to use piece-wise linear dependent functions to control a conductance to Vdd, simulating a pull-up switch and one to Gnd simulating a pull-down switch. The independent variable controlling the dependent conductance functions would be the voltage at the driver's output pad. Both conductance switches also need to be dependent on the pin's logic state and need to make a transition between states at a controlled rate using the dV/dt information in the IBIS. The state transition would have to occur based on some threshold value and the buffer's input level. Sounds simple, only the details get in the way. >4. Has anybody thought about organizing an IBIS > users group and mailing list? > This is it, I think. I would be happy to discuss the "theory of operations" of behavioral simulators in more detail. I agree that for the "sake of accuracy in system design issues" it is good to know issues and limitations involved with behavioral model simulations. It may be difficult to discuss IBIS models independent of a specific simulator, but might be interesting to try. Regards, Fred Vance FirePower Systems, Inc. (415) 462-3055 Phone (415) 462-3051 Fax Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: ibis@vhdl.org Subject: Re: IBIS modeling questions To: grege@chensys.com (Greg Edlund) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 9 Nov 95 12:44:34 -0800 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02374; Thu, 9 Nov 95 12:44:34 -0800 Message-Id: <199511092044.MAA17874@freedom.firepower.com> From: Fred Vance Received: from protocol.FirePower.COM (protocol.firepower.com [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id MAA17874; Thu, 9 Nov 1995 12:4 4:36 -0800 (PST) Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by fi repower.com (8.7.1/8.7.1) with ESMTP id MAA21114; Thu, 9 Nov 1995 12:43:21 -0800 (PST) Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SM I-4.1/BARRNet) id AA27155; Thu, 9 Nov 95 12:52:13 PST Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 9 Nov 95 13: 40:37 -0800 Received: from aurora.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 9 Nov 95 13:42:26 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tDejt-000twnC; Thu, 9 Nov 95 13:42 PST From fvance@firepower.com Fri Nov 10 05:35:05 1995 Return-Path: Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08383; Fri, 10 Nov 95 05:35:05 PST Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by firepower.com (8.7.1/8.7.1) with ESMTP id FAA24575; Fri, 10 Nov 1995 05:23:43 -0800 (PST) Received: from protocol.FirePower.COM (protocol.firepower.com [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id FAA25577; Fri, 10 Nov 1995 05:24:57 -0800 (PST) From: Fred Vance Message-Id: <199511101324.FAA25577@freedom.firepower.com> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02589; Fri, 10 Nov 95 05:25:00 -0800 Date: Fri, 10 Nov 95 05:25:00 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: Will Hobbs Subject: Re: Re[2]: IBIS modeling questions Cc: ibis@vhdl.org Will, This is only a personal opinion, but for what it is worth, I think it would be equitable for someone to provide an executable on a platform for which you have none, in exchange for the license fee for the source code. (I'm not volunteering.) If you were concerned that you might not get the executable in a timely manner, you could at least offer to refund the license fee on recepit and approval of the executable. Fred Begin forwarded message: Date: Thu, 09 Nov 95 16:27:00 PST From: Will Hobbs Message-ID: To: fvance@firepower.com, grege@chensys.com cc: ibis@vhdl.org Subject: Re[2]: IBIS modeling questions Text item: Fred, Greg, Sorry to be a bearer of bad news, but the source code must be licensed, for afee. There are many companies who have licensed the code, and we are in theprocess of porting it to various O/S and platforms. When that work is done, theresulting object code will be made freely available on vhdl.org. If you do want to license the parser, here are the details: There are three options for licensing the IBIS Golden Parser source code, V2.1, depending on your membership status in the IBIS committee of EIA: 1) If you are a current member of the IBIS committee, you can license the parser source for an additional $250.00 2) If you are not a member, but would like to be, you can join the committee and license the parser source for a total of $750 3) If you are not a member, and do not wish to become a member, you can license the source for $500. In any case, submit a request to: EIA 2500 Wilson Blvd. Arlington, VA 22201 (703) 907-7545 (phone) (703) 907-7501 (fax) Enclose a check in the appropriate amount made out to EIA. EIA will take care of distributing the source. Regards, Will Hobbs, Chair, EIA IBIS Committee Intel Corp. Hi Greg, You wrote: >To: ibis@vhdl.org >From: grege@chensys.com (Greg Edlund)>Subject: IBIS modeling questions > >Anybody care to take a stab at these?> I'll give it a try. >1. I was discussing IBIS model support with one of> our IC vendors, and they raised a concern about> ESD diode SPICE models not being accurate at > -5 V and + 10 V. Any clues about how to get > around this without setting up a test lab? Why > do you need such a wide range in the first place,> since nobody operates out there? I think that some simulators use the last couple of points to extrapolate outto infinity or some asymptotic value, so if your data is not available over the full range, you can probably do the same. Maybe it doesn't matter whether thefull range is provided. It might depend on a simulator's interpretation of the IBIS specification. If I remember correctly, using the full range is optionalin the latest IBIS revision. (Someone help me here.) >2. When will s2ibis 2.0 be available on Windows?> Actually, I'd be happy with DOS, but that's > probably not in the plan... > I believe someone would be glad to make the source code availableto you. Since you seem to have some experience with C compiling, you might be the rightperson to create the DOS/Windows executable and upload it to ibis@vhdl.org. >3. Has anybody written a "theory of operations" > paper on behavioral simulators? For instance, if> I have a simple behavioral driver model (no ESD > diodes, no package) driving a 50 Ohm transmission> line terminated at the far end into 50 Ohms, how > do I calculate the current and voltage vs. time at> the output of the driver? At the far end? This > must be an easy problem to solve. I'd like to > write a little C program to do this so I can better> understand IBIS and critically compare it to SPICE.> (For the sake of accuracy in system design issues,> not so I can write another simulator!) > Maybe, I can't really say. I believe the way to approach this is to use piece-wise linear dependentfunctions to control a conductance to Vdd, simulating a pull-up switchand one to Gnd simulating a pull-down switch. The independent variable controllingthe dependent conductance functions would be the voltage at the driver's outputpad. Both conductance switches also need to be dependent on the pin's logicstate and need to make a transition between states at a controlled rate usingthe dV/dt information in the IBIS. The state transition would have to occurbased on some threshold value and the buffer's input level. Sounds simple, only the details get in the way. >4. Has anybody thought about organizing an IBIS> users group and mailing list? > This is it, I think. I would be happy to discuss the "theory of operations"of behavioral simulators in more detail. I agree that for the "sake of accuracy in system design issues" it is good toknow issues and limitations involved with behavioral model simulations. It may be difficult to discuss IBIS models independent of a specific simulator, butmight be interesting to try. Regards, Fred Vance FirePower Systems, Inc. (415) 462-3055 Phone (415) 462-3051 Fax Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: ibis@vhdl.org Subject: Re: IBIS modeling questions To: grege@chensys.com (Greg Edlund) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 9 Nov 95 12:44:34 -0800 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02374; Thu, 9 Nov 95 12:44:34 -0800 Message-Id: <199511092044.MAA17874@freedom.firepower.com> From: Fred Vance Received: from protocol.FirePower.COM (protocol.firepower.com [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id MAA17874; Thu, 9 Nov 1995 12:4 4:36 -0800 (PST) Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by fi repower.com (8.7.1/8.7.1) with ESMTP id MAA21114; Thu, 9 Nov 1995 12:43:21 -0800 (PST) Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SM I-4.1/BARRNet) id AA27155; Thu, 9 Nov 95 12:52:13 PST Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 9 Nov 95 13: 40:37 -0800 Received: from aurora.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 9 Nov 95 13:42:26 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tDejt-000twnC; Thu, 9 Nov 95 13:42 PST From awglaser@eos.ncsu.edu Fri Nov 10 08:37:02 1995 Return-Path: Received: from mw9.ece.ncsu.edu (c11051-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09403; Fri, 10 Nov 95 08:37:02 PST Received: by mw9.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA17560; Fri, 10 Nov 1995 11:27:59 -0500 From: "Alan W. Glaser" Message-Id: <9511101127.ZM17558@eos.ncsu.edu> Date: Fri, 10 Nov 1995 11:27:28 -0500 In-Reply-To: Will Hobbs "Re[2]: IBIS modeling questions" (Nov 9, 4:27pm) References: X-Mailer: Z-Mail (3.2.1 15feb95) To: Will Hobbs Subject: Re: Re[2]: IBIS modeling questions Cc: ibis@vhdl.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Folks: Just to make this clear, I believe Will is referring to the IBIS Golden Parser. Greg's question regarding source code was referring to s2ibis v2.0, for which source code is freely available from ftp.vhdl.org and the NCSU ERL software archive at (http://www2.ncsu.edu/eos/project/erl_html/erl_home.html). Note that s2ibis v2 is still officially in beta, and probably will be until the end of the year. Thanks to everyone who has reported any lurking bugs and inconsistencies. Please keep the comments coming. Regards, Alan On Nov 9, 4:27pm, Will Hobbs wrote: > Subject: Re[2]: IBIS modeling questions > > Text item: > > Fred, Greg, > > Sorry to be a bearer of bad news, but the source code must be > licensed, for a fee. There are many companies who have licensed the > code, and we are in the process of porting it to various O/S and > platforms. When that work is done, the resulting object code will be > made freely available on vhdl.org. If you do want to license the > parser, here are the details: >-- End of excerpt from Will Hobbs -- Alan Glaser ECE Dept. North Carolina State University From Will_Hobbs@ccm.jf.intel.com Fri Nov 10 16:13:52 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12126; Fri, 10 Nov 95 16:13:52 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tE3Se-000UkyC; Fri, 10 Nov 95 16:06 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tE3Sd-000twZC; Fri, 10 Nov 95 16:06 PST Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Fri, 10 Nov 95 16:06:18 PST Date: Fri, 10 Nov 95 16:02:00 PST From: Will Hobbs Message-Id: To: awglaser@eos.ncsu.edu Cc: ibis@vhdl.org Subject: Re[4]: IBIS modeling questions Text item: Mea culpa, I responded too quickly. Alan is exactly right-- I was thinking the question was about the golden parser. I should have re-read the message before I responded. Sorry for the confusion. Will Folks: Just to make this clear, I believe Will is referring to the IBIS Golden Parser. Greg's question regarding source code was referring to s2ibis v2.0, for which source code is freely available from ftp.vhdl.org and the NCSU ERL software archive at (http://www2.ncsu.edu/eos/project/erl_html/erl_home.html). Note that s2ibis v2 is still officially in beta, and probably will be until the end of the year. Thanks to everyone who has reported any lurking bugs and inconsistencies. Please keep the comments coming. Regards, Alan On Nov 9, 4:27pm, Will Hobbs wrote: > Subject: Re[2]: IBIS modeling questions > > Text item: > > Fred, Greg, > > Sorry to be a bearer of bad news, but the source code must be > licensed, for a fee. There are many companies who have licensed the > code, and we are in the process of porting it to various O/S and > platforms. When that work is done, the resulting object code will be > made freely available on vhdl.org. If you do want to license the > parser, here are the details: >-- End of excerpt from Will Hobbs -- Alan Glaser ECE Dept. North Carolina State University Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Cc: ibis@vhdl.org Subject: Re: Re[2]: IBIS modeling questions To: Will Hobbs X-Mailer: Z-Mail (3.2.1 15feb95) References: In-Reply-To: Will Hobbs "Re[2]: IBIS modeling questions" (Nov 9, 4:27pm) Date: Fri, 10 Nov 1995 11:27:28 -0500 Message-Id: <9511101127.ZM17558@eos.ncsu.edu> From: "Alan W. Glaser" Received: by mw9.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA17560; Fri, 10 Nov 1995 11:27:59 -0500 Received: from mw9.ece.ncsu.edu by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tDwKa-000UpaC; Fri, 10 Nov 95 08:29 PST Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tDwKb-000twWC; Fri, 10 Nov 95 08:29 PST From yoram@taux01.nsc.com Sun Nov 12 03:24:21 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29779; Sun, 12 Nov 95 03:24:21 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA25146 for ibis@vhdl.org; Sun, 12 Nov 95 03:16:49 -0800 Received: from taux01.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA24755 for ibis@vhdl.org; Sun, 12 Nov 95 03:16:44 -0800 Received: from tasu44.nsc.com by taux01.nsc.com (4.1/SMI-4.1) id AA21216; Sun, 12 Nov 95 13:19:51 IST Received: by tasu44.nsc.com (4.1/SMI-4.1) id AA11673; Sun, 12 Nov 95 13:19:50 IST Date: Sun, 12 Nov 95 13:19:50 IST From: yoram@taux01.nsc.com (Yoram Avigdor) Message-Id: <9511121119.AA11673@tasu44.nsc.com> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From tareq@sh-gpl.ti.com Mon Nov 13 14:13:38 1995 Return-Path: Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22636; Mon, 13 Nov 95 14:13:38 PST Errors-To: tareq@sh-gpl.ti.com Received: from sherm-g1.sh-gpl.ti.com ([157.170.61.67]) by gate.ti.com (8.6.12/) with ESMTP id QAA19480; Mon, 13 Nov 1995 16:06:03 -0600 Received: from brain.sh-gpl.ti.com by sherm-g1.sh-gpl.ti.com with SMTP (1.37.109.16/IDA1.4.4.1) id AA224190272; Mon, 13 Nov 1995 16:04:32 -0600 From: Tareq Shahwan Received: by brain.sh-gpl.ti.com id ; Mon, 13 Nov 1995 16:04:28 -0600 Message-Id: <9511132204.AA17997@brain.sh-gpl.ti.com> Subject: Pullup/down data To: ibis@vhdl.org (ibis @vhdl.org) Date: Mon, 13 Nov 1995 16:04:27 -0600 (CST) Cc: tareq@ti.com (Tareq Shahwan) Reply-To: tareq@sh-gpl.ti.com Errors-To: tareq@sh-gpl.ti.com X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 891 All, I need some clarification on the following : (1) When running simulations on an "input buffer with Bus-Hold" to extract clamp data, should the bus-hold circuitry be disconnected ?. In other words, should we include the contribution from the Bus-Hold circuit in the clamp data. I would think not, any suggestions ? (2) Similarly, some of our devices have the so called Power-on-demand (POD) feature on the output buffer. In a BiCMOS device, this feature works to reduce the base current in the pulldown transistor when the output voltage is below a preset level, thereby reducing power consumption. While this circuitry can be disconnected in a simulation, it is always present in real-life. Again, should the effect of such circuit be incorporated into the pulldown data ?. Please advise ! Regards, Tareq Shahwan, ABI Applications From tareq@sh-gpl.ti.com Mon Nov 13 14:27:10 1995 Return-Path: Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22719; Mon, 13 Nov 95 14:27:10 PST Errors-To: tareq@sh-gpl.ti.com Received: from sherm-g1.sh-gpl.ti.com ([157.170.61.67]) by gate.ti.com (8.6.12/) with ESMTP id QAA22974 for ; Mon, 13 Nov 1995 16:19:37 -0600 Received: from brain.sh-gpl.ti.com by sherm-g1.sh-gpl.ti.com with SMTP (1.37.109.16/IDA1.4.4.1) id AA226841086; Mon, 13 Nov 1995 16:18:06 -0600 From: Tareq Shahwan Received: by brain.sh-gpl.ti.com id ; Mon, 13 Nov 1995 16:18:05 -0600 Message-Id: <9511132218.AA18014@brain.sh-gpl.ti.com> Subject: Questions To: ibis@vhdl.org (ibis @vhdl.org) Date: Mon, 13 Nov 1995 16:18:05 -0600 (CST) Reply-To: tareq@sh-gpl.ti.com Errors-To: tareq@sh-gpl.ti.com X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 912 All, I need some clarification on the following : (1) When running simulations on an "input buffer with Bus-Hold" to extract cla mp data, should the bus-hold circuitry be disconnected ?. In other words, should we include the contribution from the Bus-Hold circuit in the clamp data. I would think not, any suggestions ? (2) Similarly, some of our devices have the so called Power-On-Demand (POD) fe ature on the output buffer. In a BiCMOS device, this feature works to reduce the base current in the pulldown transistor when the output voltage is below a preset level, thereby reducing power consumption. While this circuitry can be disconnected in a simulation, it is always present in real-life. Again, should the effect of such circuit be incorporated into the pulldown data ?. Please advise ! Tareq Shahwan, ABI applications Texas Instruments From Arpad_Muranyi@ccm.fm.intel.com Mon Nov 13 15:38:05 1995 Return-Path: Received: from mailbag.jf.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23221; Mon, 13 Nov 95 15:38:05 PST Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by mailbag.jf.intel.com (8.6.12/8.6.12) with SMTP id PAA02905; Mon, 13 Nov 1995 15:29:05 -0800 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0tF8JS-000UftC; Mon, 13 Nov 95 15:29 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0tF8JR-000tx2C; Mon, 13 Nov 95 15:29 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Mon, 13 Nov 95 15:29:17 PST Date: Mon, 13 Nov 95 15:11:00 PST From: Arpad Muranyi Message-Id: To: tareq@sh-gpl.ti.com, ibis@vhdl.org Cc: tareq@ti.com Subject: Re: Pullup/down data Text item: Tareq, These are very good questions! 1) I think this kind of an input must be handeled as if it would be an output or an I/O buffer. However, a lot depends on how it works. If the HOLD circuit is always on, model it as if it would be an OUTPUT buffer. If the HOLD circuit is getting turned on after a certain amount of time (from when it saw a transition), I would model it as if it was an I/O buffer which starts driving shortly after it saw an edge. I know, this is a simplistic answer and there might be more to it than that. More complicated cituations might not be possible in IBIS as of right now. 2) The answer to this depends on how this power saver works. Does it immediately turn off if it sees that pre-determined voltage level, or later? If this save mode does not come into effect untill the reflections are settled, I would not worry about modeling it. However, if it reduces the drive strength while the signal is still bouncing back and fourth, it might be important to model it, since the reflection coeffitients depend on the driver impedance (=strength). How you do it, is another question. Not knowing the guts of your buffer, I am just guessing, but using the V-t curves might be one possible way of doing it if it is time dependent. If it is only voltage dependent, it would most likely show up in the shape of its I-V curve. Arpad Muranyi Intel Corporation ================================================================================ All, I need some clarification on the following : (1) When running simulations on an "input buffer with Bus-Hold" to extract clamp data, should the bus-hold circuitry be disconnected ?. In other words, should we include the contribution from the Bus-Hold circuit in the clamp data. I would think not, any suggestions ? (2) Similarly, some of our devices have the so called Power-on-demand (POD) feature on the output buffer. In a BiCMOS device, this feature works to reduce the base current in the pulldown transistor when the output voltage is below a preset level, thereby reducing power consumption. While this circuitry can be disconnected in a simulation, it is always present in real-life. Again, should the effect of such circuit be incorporated into the pulldown data ?. Please advise ! Regards, Tareq Shahwan, ABI Applications Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Length: 891 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: ELM [version 2.4 PL24] Errors-To: tareq@sh-gpl.ti.com Reply-To: tareq@sh-gpl.ti.com Cc: tareq@ti.com (Tareq Shahwan) Date: Mon, 13 Nov 1995 16:04:27 -0600 (CST) To: ibis@vhdl.org (ibis @vhdl.org) Subject: Pullup/down data Message-Id: <9511132204.AA17997@brain.sh-gpl.ti.com> Received: by brain.sh-gpl.ti.com id ; Mon, 13 Nov 1 995 16:04:28 -0600 From: Tareq Shahwan Received: from brain.sh-gpl.ti.com by sherm-g1.sh-gpl.ti.com with SMTP (1.37.109.16/IDA1.4.4.1) id AA224190272; Mon, 13 Nov 1995 16:04:32 -0600 Received: from sherm-g1.sh-gpl.ti.com ([157.170.61.67]) by gate.ti.com (8.6.12/) with ESMTP id QAA19480; Mon, 13 Nov 1995 16:06:03 -0600 Errors-To: tareq@sh-gpl.ti.com Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22636; Mon, 13 Nov 95 14:13:38 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 13 Nov 95 14 :09:37 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tF74O-000tx4C; Mon, 13 Nov 95 14:09 PST From speters@ichips.intel.com Mon Nov 13 17:54:58 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24160; Mon, 13 Nov 95 17:54:58 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 13 Nov 95 17:47:25 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 13 Nov 95 17:46:59 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 13 Nov 95 17:46:58 PST Message-Id: <9511140146.AA17076@xtg801.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Cc: tareq@ti.com Subject: Re: Pullup/down data Date: Mon, 13 Nov 1995 17:46:56 -0800 From: Stephen Peters Hello Tareq, Arpad, others: Yes, very good questions. I read Arpads answer to your first question below, but I assumed that the BUS HOLD feature you refered to is just a weak current source (maybe a resistor?) that pulls the input to a know voltage level if nothing else is driving that input. In that is the case, I belive that the extra current belongs in one of the clamp curves and the input should be modeled as an input, not as an output or I/O. Regards, Stephen Peters Intel Corp. Tareq, These are very good questions! 1) I think this kind of an input must be handeled as if it would be an output or an I/O buffer. However, a lot depends on how it works. If the HOLD circuit is always on, model it as if it would be an OUTPUT buffer. If the HOLD circuit is getting turned on after a certain amount of time (from when it saw a transition), I would model it as if it was an I/O buffer which starts driving shortly after it saw an edge. I know, this is a simplistic answer and there might be more to it than that. More complicated cituations might not be possible in IBIS as of right now. 2) The answer to this depends on how this power saver works. Does it immediately turn off if it sees that pre-determined voltage level, or later? If this save mode does not come into effect untill the reflections are settled, I would not worry about modeling it. However, if it reduces the drive strength while the signal is still bouncing back and fourth, it might be important to model it, since the reflection coeffitients depend on the driver impedance (=strength). How you do it, is another question. Not knowing the guts of your buffer, I am just guessing, but using the V-t curves might be one possible way of doing it if it is time dependent. If it is only voltage dependent, it would most likely show up in the shape of its I-V curve. Arpad Muranyi Intel Corporation ================================================================================ All, I need some clarification on the following : (1) When running simulations on an "input buffer with Bus-Hold" to extract clamp data, should the bus-hold circuitry be disconnected ?. In other words, should we include the contribution from the Bus-Hold circuit in the clamp data. I would think not, any suggestions ? (2) Similarly, some of our devices have the so called Power-on-demand (POD) feature on the output buffer. In a BiCMOS device, this feature works to reduce the base current in the pulldown transistor when the output voltage is below a preset level, thereby reducing power consumption. While this circuitry can be disconnected in a simulation, it is always present in real-life. Again, should the effect of such circuit be incorporated into the pulldown data ?. Please advise ! Regards, Tareq Shahwan, ABI Applications Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Length: 891 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: ELM [version 2.4 PL24] Errors-To: tareq@sh-gpl.ti.com Reply-To: tareq@sh-gpl.ti.com Cc: tareq@ti.com (Tareq Shahwan) Date: Mon, 13 Nov 1995 16:04:27 -0600 (CST) To: ibis@vhdl.org (ibis @vhdl.org) Subject: Pullup/down data Message-Id: <9511132204.AA17997@brain.sh-gpl.ti.com> Received: by brain.sh-gpl.ti.com id ; Mon, 13 Nov 1 995 16:04:28 -0600 From: Tareq Shahwan Received: from brain.sh-gpl.ti.com by sherm-g1.sh-gpl.ti.com with SMTP (1.37.109.16/IDA1.4.4.1) id AA224190272; Mon, 13 Nov 1995 16:04:32 -0600 Received: from sherm-g1.sh-gpl.ti.com ([157.170.61.67]) by gate.ti.com (8.6.12/) with ESMTP id QAA19480; Mon, 13 Nov 1995 16:06:03 -0600 Errors-To: tareq@sh-gpl.ti.com Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22636; Mon, 13 Nov 95 14:13:38 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 13 Nov 95 14 :09:37 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0tF74O-000tx4C; Mon, 13 Nov 95 14:09 PST From ingraham@wrksys.ENET.dec.com Tue Nov 14 06:13:12 1995 Return-Path: Received: from mail11.digital.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04428; Tue, 14 Nov 95 06:13:12 PST Received: from us1rmc.bb.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA30749; Tue, 14 Nov 1995 08:58:20 -0500 Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA04775; Tue, 14 Nov 95 08:52:44 -0500 Message-Id: <9511141352.AA04775@us1rmc.bb.dec.com> Received: from wrksys.enet; by us1rmc.enet; Tue, 14 Nov 95 08:54:02 EST Date: Tue, 14 Nov 95 08:54:03 EST From: Andy Ingraham To: tareq@sh-gpl.ti.com, ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org, tareq@sh-gpl.ti.com Subject: Re: Pullup/down data > (1) When running simulations on an "input buffer with Bus-Hold" to extract clamp > data, should the bus-hold circuitry be disconnected ?. In other words, > should we include the contribution from the Bus-Hold circuit in the clamp data. > I would think not, any suggestions ? "Bus-hold" circuits typically use two weak inverters connected in a positive feedback loop. Modeling this with any V/I simulator will be problematic, because the static V/I curves depend on past history, not just on present voltage. It is impossible to do this with a V/I simulator. (Not to mention the implication of negative resistance, which even some SPICE-like simulators have trouble dealing with.) In principle you should include everything. You would have to pick one of the states, for the region where the two V/I curves don't overlap. If the contribution to current is small, you might justify omitting it; but then your simulations could be in error if the feature is used. Regards, Andy Ingraham From aargee@india.ti.com Tue Nov 14 20:12:28 1995 Return-Path: Received: from dragon.ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10674; Tue, 14 Nov 95 20:12:28 PST Received: from robin.itg.ti.com ([128.247.31.238]) by dragon.ti.com (8.6.12/) with ESMTP id WAA20589; Tue, 14 Nov 1995 22:04:27 -0600 Received: from itg.ti.com (magic.itg.ti.com [128.247.93.50]) by robin.itg.ti.com (8.6.12/8.6.11) with SMTP id VAA16594; Tue, 14 Nov 1995 21:58:06 -0600 Received: from india.ti.com (dadsparc4.india.ti.com) by itg.ti.com (4.1/ITG-1.1) id AA11576; Tue, 14 Nov 95 22:04:40 CST Received: from dadsparc11.india.ti.com (dadsparc11.india.ti.com [134.183.150.111]) by india.ti.com (8.6.12/8.6.10) with SMTP id JAA14671; Wed, 15 Nov 1995 09:30:38 +0500 Received: by dadsparc11.india.ti.com (4.1/SMI-4.1) id AA01465; Wed, 15 Nov 95 09:34:59+050 Date: Wed, 15 Nov 95 09:34:59+050 From: aargee@india.ti.com (Geetha R) Message-Id: <9511150434.AA01465@dadsparc11.india.ti.com > To: ibis@vhdl.org Cc: Alan Subject: IV data extrapolation All, I need some clarifications on the following questions 1.When simulating the IV data for the Pull-up and Pull-down devices from -VCC to 2*VCC why is that extrapolation is done from -VCC to 0 for the Pull-up data when actually the dc source at the output pin is varied from -VCC to 2*VCC and similarly for the Pull-down devices the extapolation is done from VCC to 2*VCC. Is the data we obtain through simulation in these ranges not accurate? 2.Can anyone tell me how this behavioral model for the buffers was actually arrived at?Can you please explain each block in detail? Does it in anyway represent an inverter circuit? Cheers and Best Regards, Geetha Rangarajan ******************************************* * * * CONTACTS: * * * * ......email- aargee@india.ti.com * * * * ......phone-2254235-9,extn:1030 * * * * ......fax - 2257024 * * * * * * Office addr: DESIGN AUTOMATION DIVISION* * TEXAS INSTRUMENTS * * 71,MILLER ROAD, * * BANGALORE-52 * * * ******************************************* From martin_goetz@worltek.com Wed Nov 15 08:40:34 1995 Return-Path: Received: from gatekeeper.worltek.com ([204.30.128.1]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21811; Wed, 15 Nov 95 08:40:34 PST Received: (from smap@localhost) by gatekeeper.worltek.com (8.6.8/8.6.6) id IAA26402 for ; Wed, 15 Nov 1995 08:24:13 -0800 Received: from unknown(204.30.129.147) by gatekeeper.worltek.com via smap (V1.3) id sma026400; Wed Nov 15 08:23:58 1995 Received: from ccMail by ccgate.worltek.com (IMA Internet Exchange 1.04b) id 0aa16320; Wed, 15 Nov 95 08:32:50 -0800 Mime-Version: 1.0 Date: Wed, 15 Nov 1995 08:32:02 -0800 Message-Id: <0aa16320@worltek.com> From: martin_goetz@worltek.com Subject: Unsubscribe To: ibis@vhdl.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part unsubscribe From bob@icx.com Wed Nov 15 10:32:40 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22747; Wed, 15 Nov 95 10:32:40 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 15 Nov 95 10:24 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 15 Nov 95 10:27 PST Message-Id: Date: Wed, 15 Nov 95 10:27 PST From: bob@icx.com ( Bob Ross) To: aargee@india.ti.com, ibis@vhdl.org Subject: Re: IV data extrapolation Geetha: The context of your questions appears to be with respect to the s2ibis simulation and extraction algorithms. For reference, I am copying the algorithm description for s2ibis version 1.2 that is described in the FAQ section under man/man1 in Question (6): ******************************************************************************** s2ibis Frequently Asked Questions ******************************************************************************** QUESTION (6): "How does s2ibis generate tables?" ANSWER: s2ibis uses the following scheme for determining what tables need to be generated for a particular pin: 0) For POWER, GND, and NC pins, no tables are generated. 1) For each Input pin, s2ibis automatically runs SPICE jobs for [GND_clamp] and [POWER_clamp] tables. If the typ column in either of the resulting tables exceeds the clamp tolerance limit (default 1 microamp, changeable by user), that table is printed. 2) For each Output (*Not* I/O, 3-state, or Open_drain) pin, s2ibis generates [Pulldown] and [Pullup] tables only. Clamp simulations are not even attempted for Output pins. [Ramp] tables are generated by causing the output to transition while attached to the IBIS-specified load, reading the 20% and 80% points of the transition, and calculating the slope in between these points. 3) For each I/O or 3-state pin, s2ibis generates SPICE simulations for [Pulldown], [Pullup], [GND_clamp], [Power_clamp], and [Ramp] tables. Generation of the [Ramp] tables uses exactly the same procedure as described above under Ouput pins. Generation of the [Pulldown], [Pullup], [GND_clamp], and [Power_clamp] tables involves a current partitioning scheme. First s2ibis runs the [GND_clamp] and [Pulldown] simulations. The [Pulldown] table is generated as follows: pulldown(-5->0):subtract the associated ground clamp table from the pulldown table pulldown(0->Vcc):just use the pull- down table as simulated pulldown(Vcc->2*Vcc):extrapolate using the point at Vcc and the point five points before Vcc in the pulldown table. The [GND_clamp] table is not modified. The [Pullup] and [POWER_clamp] tables are created using an analogous procedure. Then s2ibis runs the [POWER_clamp] and [Pullup] simulations. The [Pullup] table is generated as follows: pullup(-5->0):subtract the associated power clamp table from the pullup table pullup(0->Vcc):just use the pull- up table as simulated pullup(Vcc->2*Vcc):extrapolate using the point at Vcc and the point five points before Vcc in the pulldown table. The [POWER_clamp] table is not modified. (1) Your first question is about the choice to use an extrapolation of data for the PULLDOWN table in the region between Vcc and 2Vcc. The alternative algorithm is to just subtract the POWER CLAMP table from a simulation of the pulldown characteristics in the region from Vcc to 2Vcc (which would include the power clamp). The problem with that approach is that if a power clamp exists, it may have very large currents as it approaches 2Vcc. So the actual subtraction of the two curves with numerically large values would tend to produce a curve that folds back to 0ma around 2Vcc for many cases do to the numerical instability of this approach. So the extrapolation technique was selected as the better alternative, expecially since this particular region is very unlikely to be encountered in actual IBIS model simulation. So the extrapolation choice avoids an almost guarenteed area on non-monotonicity which could be upsetting to some simulators. The same argument applies to the PULLUP table in the region from -Vcc to 0 (absolute voltages). The foldback characteristics do exist in some extractions of the PULLDOWN table in the region from -Vcc to 0 due to the same numerical problems, but the choice was made to retain the subtraction algorithm because of some more complicated behavior especially for Bipolar TTL devices. The PULLUP table in the Vcc to 2Vcc region is also constructed using the subtraction algorithm. (2) I am not sure how to address this question other than to reference you to the description given in the Overview document which can be obtained via FTP from /pub/ibis/documents on vhdl.org. Also the March 16, 1995 EDN article on IBIS which give some very good descriptions and basis of the behavioral model. It is intended to mimic the performance of typical CMOS and TTL models. The model and be for a Non-Inverting or Inverting device, as described by the Polarity sub-parameter. Bob Ross, Interconnectix, Inc. > Date: Wed, 15 Nov 95 09:34:59+050 > From: aargee@india.ti.com (Geetha R) > To: ibis@vhdl.org > Cc: Alan > Subject: IV data extrapolation > All, > I need some clarifications on the following questions > 1.When simulating the IV data for the Pull-up and Pull-down devices > from -VCC to 2*VCC why is that extrapolation is done from > -VCC to 0 for the Pull-up data when actually the dc source at > the output pin is varied from -VCC to 2*VCC and similarly for > the Pull-down devices the extapolation is done from VCC to 2*VCC. > Is the data we obtain through simulation in these ranges not > accurate? > 2.Can anyone tell me how this behavioral model for the buffers was > actually arrived at?Can you please explain each block in detail? > Does it in anyway represent an inverter circuit? > Cheers and Best Regards, > Geetha Rangarajan > ******************************************* > * * > * CONTACTS: * > * * > * ......email- aargee@india.ti.com * > * * > * ......phone-2254235-9,extn:1030 * > * * > * ......fax - 2257024 * > * * > * * > * Office addr: DESIGN AUTOMATION DIVISION* > * TEXAS INSTRUMENTS * > * 71,MILLER ROAD, * > * BANGALORE-52 * > * * > ******************************************* From grege@chensys.com Fri Nov 17 14:51:43 1995 Return-Path: Received: from human.chensys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24964; Fri, 17 Nov 95 14:51:43 PST Received: from puma.chensys.com by human.chensys.com (8.6.10/SMI-4.1) id WAA26136; Fri, 17 Nov 1995 22:50:09 GMT Received: from [137.42.2.33] by puma.chensys.com via SMTP (931110.SGI/930416.SGI) for @chensys.com:ibis@vhdl.org id AA02389; Fri, 17 Nov 95 16:38:16 -0600 Message-Id: <9511172238.AA02389@puma.chensys.com> X-Sender: gre@pop3.chensys.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Nov 1995 16:43:42 -0600 To: ibis@vhdl.org From: grege@chensys.com (Greg Edlund) Subject: users list Hey, looks good! I sent off a copy of the annoucement to the signal integrity list, and I'll try to make the new IBIS users list known to my acquaintances. -- Greg Edlund +----+----+ Circuits and Modeling | | | Chen Systems Corp. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) voice (715) 833-7067 > | ) FAX (715) 833-7096 | | | email grege@chensys.com +----+----+ From grege@chensys.com Tue Nov 21 06:19:49 1995 Return-Path: Received: from human.chensys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19987; Tue, 21 Nov 95 06:19:49 PST Received: from puma.chensys.com by human.chensys.com (8.6.10/SMI-4.1) id OAA08074; Tue, 21 Nov 1995 14:18:42 GMT Received: from [137.42.2.33] by puma.chensys.com via SMTP (931110.SGI/930416.SGI) for @chensys.com:ibis@vhdl.org id AA26169; Tue, 21 Nov 95 08:06:06 -0600 Message-Id: <9511211406.AA26169@puma.chensys.com> X-Sender: gre@pop3.chensys.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Nov 1995 08:11:47 -0600 To: ibis@vhdl.org From: grege@chensys.com (Greg Edlund) Subject: Signal Integrity List For those of you who may be interested: > The address for subscribing to the Signal Integrity List is: > si-admin@silab.eng.sun.com > > To post a message: > si-list@silab.eng.sun.com I'm including a copy of the charter of the Signal Integrity List with this email. Note that the addresses listed below are no longer valid. ---------------------------------------------------------------- The following message is a modified copy of that sent out when the list was activated. ---------------------------------------------------------------- ANNOUNCEMENT: The Signal Integrity Mailing List has been activated. PURPOSE: The si-list is intended to be a forum for professionals both in industry and academia to: discuss signal integrity matters, ask questions pertaining to si, make announcements related to si related functions, and anything else you can think of related signal integrity. Modeling, simulation, measurements, software, EMC/EMI are some of the areas for discussion that come to mind. If interest warrants, I can provide ftp space on a publically accessible server for signal integrity related files and programs. HOW TO USE: To send a message to the list subscribers: ==> email to: si-list@android.ebay.sun.com <== Any message sent to this address will be broadcast to ALL subscribers of the list. Remember that this list is comprised of members from various organizations both academic and commercial scattered across the continent, so be careful not to post proprietary information. Please use the si-admin address described below for administrative matters. This will help maximize the signal to noise ratio on the list and keep admin messages from flooding everyones mailbox. For administrative matters (subscribe, unsubscribe, change address, etc.): ==> e-mail to: si-admin@android.ebay.sun.com <== Any message sent to this address will NOT go to the general list, but will result in local action being taken to administer the list. Please note that at this time administration is being done manually so any admin requests will not take effect instantly but may take 1 to 2 days in some cases. Please list the action desired, (subscribe, unsubscribe, change, etc.) in the subject line. Describe the change in the body of the message. Form isn't important as a human will be reading the message. Thanks to all of those that expressed interest in the concept of an internet signal integrity mailing list. ---------------------------------------------------------------------------- This response does not represent the official position of, or statement by, Sun Microsystems Incorporated. The above data is provided for informational purposes only. It is supplied without warranty of any kind. ---------------------------------------------------------------------------- /\ \\ \ \ \\ / / \/ / / Raymond E. Anderson WB6TPU / / \//\ Signal Integrity Engineer \//\ / / Sun Microsystems / / /\ / 2550 Garcia Ave. MS MIL04-16 / \\ \ Mountain View, CA 94043-1100 \ \\ \/ (408) 276-5224 (408) 956-0492 fax raymond.anderson@Sun.Com -- Greg Edlund o---+----+----+---o Circuits and Modeling | | | Chen Systems Corp. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) voice (715) 833-7067 > | ) FAX (715) 833-7096 | | | email grege@chensys.com o---+----+----+----o From bob@icx.com Wed Nov 22 12:15:03 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08051; Wed, 22 Nov 95 12:15:03 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 22 Nov 95 12:06 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 22 Nov 95 12:09 PST Message-Id: Date: Wed, 22 Nov 95 12:09 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org, ibis@vhdl.org Subject: NEW IBISCHK2 EXECUTABLES Hello: If you receive two copies of this, then you are on both the ibis@vhdl.org and ibis-users@vhdl.org reflectors. Release versions of ibischk2 executables have been put under the ibischk2 directory under /pub/ibis on vhdl.org. These are now organized by computer operating system. Thanks to Jon Powell for creating these executables. The older executables are temporarily stored in an "old" subdirectory as a backup. Please report any problems. Also, there is a new subdirectory "wip" for work in progress where some approved BIRDS are rolled up into a working draft for future Version 3.0 activity. Bob Ross, Interconnectix, Inc. IBIS Open Forum Secretary From bob@icx.com Wed Nov 22 15:32:52 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09440; Wed, 22 Nov 95 15:32:52 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 22 Nov 95 15:24 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 22 Nov 95 15:27 PST Message-Id: Date: Wed, 22 Nov 95 15:27 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD31 - CONNECTOR MODELS To IBIS Members: BIRD31 for Version 3.0 proposes a method for IBIS to model connectors in multi-board simulation which leverages off of the existing package model syntax and extensions. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 31 ISSUE TITLE: Connector Models REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 11/22/95 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: No guidance is given within IBIS with respect to modeling connectors and their interconnection to other boards. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: A CONNECTOR MODELING section following the PACKAGE MODELING section is added to describe how connectors can be modeled. The proposed approach does not contain any technical change or new keywords and sub-parameters. |============================================================================= | | CONNECTOR MODELING | | This section describes how connectors can be modeled and how connection | paths between boards are modeled. | | Each side of a connector may be configured as a complete IBIS [Component]. | This is illustrated using the default [Package] sub-parameters L_pkg, R_pkg, | and C_pkg: | | | L_pkg_1 R_pkg_1 | n1 o-----+---@@@@@---/\/\/\-------+ | | ___|___ | | NC, | | | __|__ POWER or, | | Optional | C_pkg_1 _____ GND or | | [Model] | | |_______| | | | | GND GND, Gnd_Clamp Reference, | or Power Clamp Reference | | Model of Board 1, Connector m1, Pin n1 | | | R_pkg_2 L_pkg_2 | +--------/\/\/\---@@@@@---+-----o n2 | ___|___ | | NC, | | | | POWER or, | | Optional __|__ | GND or | | [Model] _____ C_pkg_2 | |_______| | | | | | GND, Gnd_Clamp Reference, GND | or Power Clamp Reference | | Model of Board 2, Connector m2, Pin n2 | | | When, pins n1 and n2 are connected (as specified by the simulator), they | are joined at the die position of each model. This is illustrated below: | | | | Board 1, Connector m1 Board 2, Connector m2 | | Connection | L_pkg_1 R_pkg_1 V R_pkg_2 L_pkg_2 | n1 o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o n2 | | ___|___ | | | NC, | | | | __|__ POWER or, | | Optional __|__ | C_pkg_1 _____ GND or | | [Model](s) _____ C_pkg_2 | | |_______| | | | | | | GND GND, Gnd_Clamp Reference, GND | or Power Clamp Reference | | Example of Model Showing Connection of Pins n1 and n2 | | | This illustration also applies to other package model forms by substituting | The [Pin] sub-parameters L_pin, R_pin and C_pin or the [Define Package | Model] matrix keywords [Inductance Matrix], [Resistance Matrix] and | [Capacitance Matrix] for the L_pkg, R_pkg, and C_pkg elements above. | Furthermore, the complete set of sections contained in a [Define Package | Model] description could be substituted. So, discrete elements, transmission | line elements and coupled matrix sections also can be used to model connector | pins. | | The connector elements of each board do not have to be symmetrical, nor | do they have to be of the same form. The connectivity model is just the | cascading of separate models on each board. So, for example, Board 1 may | be described by the default package parameters while board 2 may be described | by with [Define Package Model] and several sections. | | NC, POWER, or GND can be used for the model_name definition so that the | [Component] keyword for the connector conforms to IBIS syntax rules. An | actual model_name with a corresponding [Model] keyword may be used. The | most common application will be to insert a Terminator model to provide | an additional C_comp element and possibly some built-in connector clamping | and resistive elements. | | All other model types are permitted for active elements. However, unless | there really is an active element within a connector, these models would | normally be used as stubs for simulation purposes. No connection would | be specified by the simulator. | | If no connection exists, as might occur when the board has an optional | memory card, the complete [Component] model provides the termination | of each pin. Since connector model data is most frequently given with | the connector connected, this no-connect model may only serve as an | approximation. | | If electrical model details of non-connect modes exist, they could by added | by using [Model Selector] keyword selections. | |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Connectors may appear as components just like any other electrical part. Thus, they can be described by IBIS models. Thus electrical stubs can be introduced for single board analysis. However, this approach may not be sufficiently accurate. Multi-board analysis is becoming a requirement and a reality. The proposal gives a method of providing accurate models for the connector. The connectivity itself must be described by the simulator. Because the connector structures have similar characteristics as package structures, the approach here is to leverage off of the exiting package syntax and extensions. Thus, no new keywords or sub-parameters are needed. Connector models are therefore handled in a totally consistent manner. With the [Model Selector] extension, even connected and non-connected modes of connectors can be modeled. This is a realistic situation with optional memory cards and open backplane slots. Possible extensions to include cables are not considered here. They could be simulator specific and could be modeled as another type of "board" in multi-board analysis. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Thanks to Chris Reid for suggesting this approach. ****************************************************************************** From vdm@decwa.ece.uiuc.edu Thu Nov 23 18:19:09 1995 Return-Path: Received: from uxh.cso.uiuc.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24654; Thu, 23 Nov 95 18:19:09 PST Received: from ruger-81.slip.uiuc.edu. (ruger-81.slip.uiuc.edu) by uxh.cso.uiuc.edu with SMTP id AA07003 (5.67b/IDA-1.5); Thu, 23 Nov 1995 20:11:24 -0600 Message-Id: Date: Thu, 23 Nov 95 20:11:51 CST From: "Dmitri Kuznetsov" Subject: Job wanted To: ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: VersaTerm Link v1.1.1 Dear Sir or Madam: I will graduate from the University of Illinois in May of 1996 with a Ph.D. in Electrical and Computer Engineering, and looking for an R&D position in the area of CAD tools. I have 4 years of research experience in the circuit simulation of high-speed digital interconnects. The interconnect models I developed have been adopted in the Cadence's DFSignoise commercial CAD product, and at the Intel's in-house circuit simulator. The attached resume provides more information on my qualifications. I would be happy to supply any further information. Thank you very much for your time. I am looking forward to hearing from you soon. Sincerely, Dmitri Kuznetsov >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>RESUME<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< DMITRI KUZNETSOV 703 E. Colorado Ave., Apt. 310 Tel: (217)337-6353 Urbana, IL 61801 Fax: (217)333-8986 e-mail: vdm@decwa.ece.uiuc.edu ======================================================================= STATUS ----------------------------------------------------------------------- Permanent resident. OBJECTIVE ----------------------------------------------------------------------- A research and development position in Electronics Engineering or Computational Electronics. SUMMARY OF QUALIFICATIONS ----------------------------------------------------------------------- * 4 YEARS OF RESEARCH EXPERIENCE in computational electronics. * 4 YEARS OF ENGINEERING EXPERIENCE in analog and digital electronics design. * Broad fundamental knowledge--120 COURSES--in all areas of Electronics and Computer Engineering, Mathematics, and Physics. * SUMMA CUM LAUDE undergraduate degree. EDUCATION ----------------------------------------------------------------------- UNIVERSITY OF ILLINOIS AT URBANA, DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING 6/93-5/96 PH.D. IN ELECTRICAL AND COMPUTER ENGINEERING (expected) Thesis: Indirect numerical integration, difference approximation, and circuit simulation of transmission lines G.P.A.: 5/5 1/92-5/93 M.S. IN ELECTRICAL AND COMPUTER ENGINEERING Thesis: Transmission line modeling and transient simulation G.P.A.: 4.64/5 SPACE RESEARCH INSTITUTE, MOSCOW, RUSSIA 11/88-2/91 Post-graduate study in Information and Measurement Systems in Space Research 9/86-6/88 Special program in Aerospace Electronics for engineering students MOSCOW ELECTROTECHNICAL INSTITUTE OF TELECOMMUNICATION, DEPARTMENT OF AUTOMATICS, TELEMECHANICS AND ELECTRONICS, RUSSIA 9/83-6/88 DIPL. ING., SUMMA CUM LAUDE, IN ELECTRONICS ENGINEERING Thesis: High-resolution videomonitor G.P.A.: 4.91/5 EXPERIENCE ----------------------------------------------------------------------- UNIVERSITY OF ILLINOIS AT URBANA 5/91-present RESEARCH ASSISTANT Development of computational methods of transient analysis, circuit simulation and transmission line modeling. THE DEVELOPED METHODS HAVE BEEN ADOPTED IN THE CADENCE'S DFSIGNOISE COMMERCIAL CAD PRODUCT AND AT THE INTEL'S IN-HOUSE CIRCUIT SIMULATOR, AND ARE TAUGHT IN A GRADUATE- LEVEL COURSE AT THE UNIVERSITY OF ILLINOIS. SPACE RESEARCH INSTITUTE, MOSCOW, RUSSIA 1/87-2/91 ELECTRONICS ENGINEER Digital and analog design of computer graphics systems for aerospace applications. Designs included: high-resolution computer graphics system; systems for computerized acquisition, processing and visualization of satellite images; computerized X-ray, ultrasonic and iridodiagnostics biomedical systems. KHRUNICHEV PLANT, MOSCOW, RUSSIA summer 1986 SENIOR TECHNICIAN Installation of secure underground communication cables. SSO MURMANSK, MURMANSK DISTRICT, RUSSIA summer 1985 TECHNICIAN Installation of secure underground communication cables. SHAULYAY TELEVISION PLANT, LITHUANIA summer 1984 TECHNICIAN Testing of TV sets. COMPUTER SKILLS ----------------------------------------------------------------------- Operating systems: UNIX, Macintosh, DOS. Programming languages: C++, C, Pascal, PL, Assembler, Mathematica, MatLab. CAD tools: SPICE, PC-CAD, AutoCAD, TeamWork. REFERENCES ----------------------------------------------------------------------- Available upon request. PUBLICATIONS ----------------------------------------------------------------------- 1. D. B. Kuznetsov and J. E. Schutt-Aine, "Transmission line modeling and transient simulation," EMC Lab., Dept. of ECE, Univ. of Illinois at Urbana, Tech. Rep. 92-4, Dec. 1992. 2. D. B. Kuznetsov and J. E. Schutt-Aine, "Difference model approach for the transient simulation of transmission lines," in Proc. ISCAS'93, 1993, pp. 1547-1550. 3. J. E. Schutt-Aine and D. B. Kuznetsov, "Efficient transient simulation of distributed interconnects," presented at 10th Int. Conf. Num. Analysis Semicond. Dev. Integr. Circuits (NASECODE X), Dublin, Ireland, Jun. 1994. 4. K. S. Oh, D. B. Kuznetsov and J. E. Schutt-Aine, "Capacitance computations in a multilayered dielectric medium using closed-form spatial Green's functions," IEEE Trans. Microwave Theory Tech., vol. 42, pp. 1443-1453, Aug. 1994. 5. J. E. Schutt-Aine and D. B. Kuznetsov, "Efficient transient simulation of distributed interconnects," Int. Journ. Computation Math. Electr. Eng. (COMPEL), vol. 13, no. 4, Dec. 1994, pp. 795-806. 6. D. B. Kuznetsov, J. E. Schutt-Aine and R. Mittra, "Optimal transient simulation of distributed lines," in Proc. MCMC'95, 1995, pp. 164-169. 7. D. B. Kuznetsov and J. E. Schutt-Aine, "Optimal transient simulation of transmission lines," to appear in IEEE Trans. Circuits Syst., vol. 42, Dec. 1995. 8. D. B. Kuznetsov and J. E. Schutt-Aine, "Indirect numerical integration," submitted for publication in IEEE Trans. Circuits Syst. 9. D. B. Kuznetsov and J. E. Schutt-Aine, "Efficient circuit simulation of nonuniform transmission lines," submitted for publication in IEEE Trans. Microwave Theory Tech. 10. D. B. Kuznetsov and J. E. Schutt-Aine, "Difference approximation," submitted for publication in IEEE Trans. Circuits Syst. 11. D. B. Kuznetsov, K. S. Oh and J. E. Schutt-Aine, "Equivalent circuit modeling of electromagnetic systems," submitted for publication in IEEE Trans. Microwave Theory Tech. 12. D. B. Kuznetsov and J. E. Schutt-Aine, "Efficient circuit simulation of transmission lines," in preparation. From vdm@decwa.ece.uiuc.edu Thu Nov 23 19:14:38 1995 Return-Path: Received: from uxh.cso.uiuc.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24954; Thu, 23 Nov 95 19:14:38 PST Received: from ruger-81.slip.uiuc.edu. (ruger-81.slip.uiuc.edu) by uxh.cso.uiuc.edu with SMTP id AA07671 (5.67b/IDA-1.5); Thu, 23 Nov 1995 21:06:56 -0600 Message-Id: Date: Thu, 23 Nov 95 21:07:23 CST From: "Dmitri Kuznetsov" Subject: Job wanted To: ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: VersaTerm Link v1.1.1 Dear Sir or Madam: I will graduate from the University of Illinois in May of 1996 with a Ph.D. in Electrical and Computer Engineering, and looking for an R&D position in the area of CAD tools. I have 4 years of research experience in the circuit simulation of high-speed digital interconnects. The interconnect models I developed have been adopted in the Cadence's DFSignoise commercial CAD product, and at the Intel's in-house circuit simulator. The attached resume provides more information on my qualifications. I would be happy to supply any further information. Thank you very much for your time. I am looking forward to hearing from you soon. Sincerely, Dmitri Kuznetsov >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>RESUME<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< DMITRI KUZNETSOV 703 E. Colorado Ave., Apt. 310 Tel: (217)337-6353 Urbana, IL 61801 Fax: (217)333-8986 e-mail: vdm@decwa.ece.uiuc.edu ======================================================================= STATUS ----------------------------------------------------------------------- Permanent resident. OBJECTIVE ----------------------------------------------------------------------- A research and development position in Electronics Engineering or Computational Electronics. SUMMARY OF QUALIFICATIONS ----------------------------------------------------------------------- * 4 YEARS OF RESEARCH EXPERIENCE in computational electronics. * 4 YEARS OF ENGINEERING EXPERIENCE in analog and digital electronics design. * Broad fundamental knowledge--120 COURSES--in all areas of Electronics and Computer Engineering, Mathematics, and Physics. * SUMMA CUM LAUDE undergraduate degree. EDUCATION ----------------------------------------------------------------------- UNIVERSITY OF ILLINOIS AT URBANA, DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING 6/93-5/96 PH.D. IN ELECTRICAL AND COMPUTER ENGINEERING (expected) Thesis: Indirect numerical integration, difference approximation, and circuit simulation of transmission lines G.P.A.: 5/5 1/92-5/93 M.S. IN ELECTRICAL AND COMPUTER ENGINEERING Thesis: Transmission line modeling and transient simulation G.P.A.: 4.64/5 SPACE RESEARCH INSTITUTE, MOSCOW, RUSSIA 11/88-2/91 Post-graduate study in Information and Measurement Systems in Space Research 9/86-6/88 Special program in Aerospace Electronics for engineering students MOSCOW ELECTROTECHNICAL INSTITUTE OF TELECOMMUNICATION, DEPARTMENT OF AUTOMATICS, TELEMECHANICS AND ELECTRONICS, RUSSIA 9/83-6/88 DIPL. ING., SUMMA CUM LAUDE, IN ELECTRONICS ENGINEERING Thesis: High-resolution videomonitor G.P.A.: 4.91/5 EXPERIENCE ----------------------------------------------------------------------- UNIVERSITY OF ILLINOIS AT URBANA 5/91-present RESEARCH ASSISTANT Development of computational methods of transient analysis, circuit simulation and transmission line modeling. THE DEVELOPED METHODS HAVE BEEN ADOPTED IN THE CADENCE'S DFSIGNOISE COMMERCIAL CAD PRODUCT AND AT THE INTEL'S IN-HOUSE CIRCUIT SIMULATOR, AND ARE TAUGHT IN A GRADUATE- LEVEL COURSE AT THE UNIVERSITY OF ILLINOIS. SPACE RESEARCH INSTITUTE, MOSCOW, RUSSIA 1/87-2/91 ELECTRONICS ENGINEER Digital and analog design of computer graphics systems for aerospace applications. Designs included: high-resolution computer graphics system; systems for computerized acquisition, processing and visualization of satellite images; computerized X-ray, ultrasonic and iridodiagnostics biomedical systems. KHRUNICHEV PLANT, MOSCOW, RUSSIA summer 1986 SENIOR TECHNICIAN Installation of secure underground communication cables. SSO MURMANSK, MURMANSK DISTRICT, RUSSIA summer 1985 TECHNICIAN Installation of secure underground communication cables. SHAULYAY TELEVISION PLANT, LITHUANIA summer 1984 TECHNICIAN Testing of TV sets. COMPUTER SKILLS ----------------------------------------------------------------------- Operating systems: UNIX, Macintosh, DOS. Programming languages: C++, C, Pascal, PL, Assembler, Mathematica, MatLab. CAD tools: SPICE, PC-CAD, AutoCAD, TeamWork. REFERENCES ----------------------------------------------------------------------- Available upon request. PUBLICATIONS ----------------------------------------------------------------------- 1. D. B. Kuznetsov and J. E. Schutt-Aine, "Transmission line modeling and transient simulation," EMC Lab., Dept. of ECE, Univ. of Illinois at Urbana, Tech. Rep. 92-4, Dec. 1992. 2. D. B. Kuznetsov and J. E. Schutt-Aine, "Difference model approach for the transient simulation of transmission lines," in Proc. ISCAS'93, 1993, pp. 1547-1550. 3. J. E. Schutt-Aine and D. B. Kuznetsov, "Efficient transient simulation of distributed interconnects," presented at 10th Int. Conf. Num. Analysis Semicond. Dev. Integr. Circuits (NASECODE X), Dublin, Ireland, Jun. 1994. 4. K. S. Oh, D. B. Kuznetsov and J. E. Schutt-Aine, "Capacitance computations in a multilayered dielectric medium using closed-form spatial Green's functions," IEEE Trans. Microwave Theory Tech., vol. 42, pp. 1443-1453, Aug. 1994. 5. J. E. Schutt-Aine and D. B. Kuznetsov, "Efficient transient simulation of distributed interconnects," Int. Journ. Computation Math. Electr. Eng. (COMPEL), vol. 13, no. 4, Dec. 1994, pp. 795-806. 6. D. B. Kuznetsov, J. E. Schutt-Aine and R. Mittra, "Optimal transient simulation of distributed lines," in Proc. MCMC'95, 1995, pp. 164-169. 7. D. B. Kuznetsov and J. E. Schutt-Aine, "Optimal transient simulation of transmission lines," to appear in IEEE Trans. Circuits Syst., vol. 42, Dec. 1995. 8. D. B. Kuznetsov and J. E. Schutt-Aine, "Indirect numerical integration," submitted for publication in IEEE Trans. Circuits Syst. 9. D. B. Kuznetsov and J. E. Schutt-Aine, "Efficient circuit simulation of nonuniform transmission lines," submitted for publication in IEEE Trans. Microwave Theory Tech. 10. D. B. Kuznetsov and J. E. Schutt-Aine, "Difference approximation," submitted for publication in IEEE Trans. Circuits Syst. 11. D. B. Kuznetsov, K. S. Oh and J. E. Schutt-Aine, "Equivalent circuit modeling of electromagnetic systems," submitted for publication in IEEE Trans. Microwave Theory Tech. 12. D. B. Kuznetsov and J. E. Schutt-Aine, "Efficient circuit simulation of transmission lines," in preparation. From vdm@decwa.ece.uiuc.edu Fri Nov 24 15:20:17 1995 Return-Path: Received: from uxh.cso.uiuc.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07733; Fri, 24 Nov 95 15:20:17 PST Received: from ruger-94.slip.uiuc.edu. (ruger-94.slip.uiuc.edu) by uxh.cso.uiuc.edu with SMTP id AA26105 (5.67b/IDA-1.5); Fri, 24 Nov 1995 17:12:34 -0600 Message-Id: Date: Fri, 24 Nov 95 17:13:04 CST From: "Dmitri Kuznetsov" Subject: Job wanted To: ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: VersaTerm Link v1.1.1 Dear Sir or Madam: I will graduate from the University of Illinois in May of 1996 with a Ph.D. in Electrical and Computer Engineering, and looking for an R&D position in the area of CAD tools. I have 4 years of research experience in the circuit simulation of high-speed digital interconnects. The interconnect models I developed have been adopted in the Cadence's DFSignoise commercial CAD product, and at the Intel's in-house circuit simulator. The attached resume provides more information on my qualifications. I would be happy to supply any further information. Thank you very much for your time. I am looking forward to hearing from you soon. Sincerely, Dmitri Kuznetsov >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>RESUME<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< DMITRI KUZNETSOV 703 E. Colorado Ave., Apt. 310 Tel: (217)337-6353 Urbana, IL 61801 Fax: (217)333-8986 e-mail: vdm@decwa.ece.uiuc.edu ======================================================================= STATUS ----------------------------------------------------------------------- Permanent resident. OBJECTIVE ----------------------------------------------------------------------- A research and development position in Electronics Engineering or Computational Electronics. SUMMARY OF QUALIFICATIONS ----------------------------------------------------------------------- * 4 YEARS OF RESEARCH EXPERIENCE in computational electronics. * 4 YEARS OF ENGINEERING EXPERIENCE in analog and digital electronics design. * Broad fundamental knowledge--120 COURSES--in all areas of Electronics and Computer Engineering, Mathematics, and Physics. * SUMMA CUM LAUDE undergraduate degree. EDUCATION ----------------------------------------------------------------------- UNIVERSITY OF ILLINOIS AT URBANA, DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING 6/93-5/96 PH.D. IN ELECTRICAL AND COMPUTER ENGINEERING (expected) Thesis: Indirect numerical integration, difference approximation, and circuit simulation of transmission lines G.P.A.: 5/5 1/92-5/93 M.S. IN ELECTRICAL AND COMPUTER ENGINEERING Thesis: Transmission line modeling and transient simulation G.P.A.: 4.64/5 SPACE RESEARCH INSTITUTE, MOSCOW, RUSSIA 11/88-2/91 Post-graduate study in Information and Measurement Systems in Space Research 9/86-6/88 Special program in Aerospace Electronics for engineering students MOSCOW ELECTROTECHNICAL INSTITUTE OF TELECOMMUNICATION, DEPARTMENT OF AUTOMATICS, TELEMECHANICS AND ELECTRONICS, RUSSIA 9/83-6/88 DIPL. ING., SUMMA CUM LAUDE, IN ELECTRONICS ENGINEERING Thesis: High-resolution videomonitor G.P.A.: 4.91/5 EXPERIENCE ----------------------------------------------------------------------- UNIVERSITY OF ILLINOIS AT URBANA 5/91-present RESEARCH ASSISTANT Development of computational methods of transient analysis, circuit simulation and transmission line modeling. THE DEVELOPED METHODS HAVE BEEN ADOPTED IN THE CADENCE'S DFSIGNOISE COMMERCIAL CAD PRODUCT AND AT THE INTEL'S IN-HOUSE CIRCUIT SIMULATOR, AND ARE TAUGHT IN A GRADUATE- LEVEL COURSE AT THE UNIVERSITY OF ILLINOIS. SPACE RESEARCH INSTITUTE, MOSCOW, RUSSIA 1/87-2/91 ELECTRONICS ENGINEER Digital and analog design of computer graphics systems for aerospace applications. Designs included: high-resolution computer graphics system; systems for computerized acquisition, processing and visualization of satellite images; computerized X-ray, ultrasonic and iridodiagnostics biomedical systems. KHRUNICHEV PLANT, MOSCOW, RUSSIA summer 1986 SENIOR TECHNICIAN Installation of secure underground communication cables. SSO MURMANSK, MURMANSK DISTRICT, RUSSIA summer 1985 TECHNICIAN Installation of secure underground communication cables. SHAULYAY TELEVISION PLANT, LITHUANIA summer 1984 TECHNICIAN Testing of TV sets. COMPUTER SKILLS ----------------------------------------------------------------------- Operating systems: UNIX, Macintosh, DOS. Programming languages: C++, C, Pascal, PL, Assembler, Mathematica, MatLab. CAD tools: SPICE, PC-CAD, AutoCAD, TeamWork. REFERENCES ----------------------------------------------------------------------- Available upon request. PUBLICATIONS ----------------------------------------------------------------------- 1. D. B. Kuznetsov and J. E. Schutt-Aine, "Transmission line modeling and transient simulation," EMC Lab., Dept. of ECE, Univ. of Illinois at Urbana, Tech. Rep. 92-4, Dec. 1992. 2. D. B. Kuznetsov and J. E. Schutt-Aine, "Difference model approach for the transient simulation of transmission lines," in Proc. ISCAS'93, 1993, pp. 1547-1550. 3. J. E. Schutt-Aine and D. B. Kuznetsov, "Efficient transient simulation of distributed interconnects," presented at 10th Int. Conf. Num. Analysis Semicond. Dev. Integr. Circuits (NASECODE X), Dublin, Ireland, Jun. 1994. 4. K. S. Oh, D. B. Kuznetsov and J. E. Schutt-Aine, "Capacitance computations in a multilayered dielectric medium using closed-form spatial Green's functions," IEEE Trans. Microwave Theory Tech., vol. 42, pp. 1443-1453, Aug. 1994. 5. J. E. Schutt-Aine and D. B. Kuznetsov, "Efficient transient simulation of distributed interconnects," Int. Journ. Computation Math. Electr. Eng. (COMPEL), vol. 13, no. 4, Dec. 1994, pp. 795-806. 6. D. B. Kuznetsov, J. E. Schutt-Aine and R. Mittra, "Optimal transient simulation of distributed lines," in Proc. MCMC'95, 1995, pp. 164-169. 7. D. B. Kuznetsov and J. E. Schutt-Aine, "Optimal transient simulation of transmission lines," to appear in IEEE Trans. Circuits Syst., vol. 42, Dec. 1995. 8. D. B. Kuznetsov and J. E. Schutt-Aine, "Indirect numerical integration," submitted for publication in IEEE Trans. Circuits Syst. 9. D. B. Kuznetsov and J. E. Schutt-Aine, "Efficient circuit simulation of nonuniform transmission lines," submitted for publication in IEEE Trans. Microwave Theory Tech. 10. D. B. Kuznetsov and J. E. Schutt-Aine, "Difference approximation," submitted for publication in IEEE Trans. Circuits Syst. 11. D. B. Kuznetsov, K. S. Oh and J. E. Schutt-Aine, "Equivalent circuit modeling of electromagnetic systems," submitted for publication in IEEE Trans. Microwave Theory Tech. 12. D. B. Kuznetsov and J. E. Schutt-Aine, "Efficient circuit simulation of transmission lines," in preparation. From bob@icx.com Mon Nov 27 09:38:01 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17747; Mon, 27 Nov 95 09:38:01 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 27 Nov 95 09:30 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 27 Nov 95 09:32 PST Message-Id: Date: Mon, 27 Nov 95 09:32 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA DEC 1, 1995 IBIS Open Forum Meeting Agenda for 12/1/95 Bridge Number Reservation # Passcode (916) 356-9200 2-34986 8556351 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 Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Rusher/Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press Updates Hobbs/Rusher/All - New Models Available, Library Update All - Opens for New Issues All 8:15 EIA/IBIS Activities - ANSI Ratification of IBIS (EIA-656) Progress Rusher/Hobbs - 1996 Membership Hobbs/Rusher 8:25 Administrative and Project Discussions Users' Group Ross January 29, 1996 Face-to-Face Meeting Huq Model Topics Hobbs/All Technical Topics Hobbs/All Web Project Update & Huq Company Logos Powell Model Usage Tracking on vhdl.org Huq/Peters Golden Parser 2.1 Status Powell/Ross S2IBIS 2.1 Status Ross/Steer New Administrative Issues All 9:00 Technical Discussions BIRD31 Connector Models Ross BIRD28.3+ - Matrix Name Enhancement proposal Kumar/Peters EGG8 - Physical Package Description Discussion Crisafulli EGG6 - CMOS and TTL Data Powell DCL Relationship, Roadmap Timing, Other Standards Christopher New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From songjj@nsrc.nus.sg Wed Nov 29 23:21:44 1995 Return-Path: Received: from aba.nsrc.nus.sg by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25887; Wed, 29 Nov 95 23:21:44 PST Received: by aba.nsrc.nus.sg (8.7.1/SMI-SVR4) id PAA11118; Thu, 30 Nov 1995 15:14:00 +0800 (SGT) From: songjj@nsrc.nus.sg (Song JJ) Message-Id: <199511300714.PAA11118@aba.nsrc.nus.sg> Subject: subscribe To: ibis@vhdl.org Date: Thu, 30 Nov 1995 15:13:59 +0800 (SGT) X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit subscribe