From mat@askew50.lsi.tmg.nec.co.jp Mon Nov 7 01:24:00 1994 Return-Path: Received: from TYO1.gate.nec.co.jp by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01843; Mon, 7 Nov 94 01:24:00 PST Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO1.gate.nec.co.jp (8.6.9+2.4Wb3/3.3Wb-NEC-TYO1) with SMTP id SAA23721 for ; Mon, 7 Nov 1994 18:19:47 +0900 Received: from askew50.lsi.tmg.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA17064; Mon, 7 Nov 1994 18:19:46 +0900 Received: by askew50.lsi.tmg.nec.co.jp (5.65c/6.4JAIN-lsi-mx1.0) id AA06101; Mon, 7 Nov 1994 18:20:00 +0900 From: Matsumoto Hiroshi Message-Id: <199411070920.AA06101@askew50.lsi.tmg.nec.co.jp> To: ibis@vhdl.org Cc: mat@askew50.lsi.tmg.nec.co.jp, narita@lsi.tmg.nec.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Mon, 07 Nov 94 18:19:59 +0900 Subscribe narita@lsi.tmg.nec.co.jp Regards Hiroshi Matsumoto (mat@lsi.tmg.nec.co.jp) ============================================================================== Hiroshi Matsumoto NEC Corporation (Design System Dept. , ASIC Division) Tel:+81 -44-435-1501(DIR) Fax:+81 -44-435-1887 E-mail:mat@lsi,tmg.nec.co.jp TELNET:8-22-25751 Mail:22-25751 PCVAN(buz/private):HYT26679@pcvan.nec.co.jp / MWM86833@pcvan.nec.co.jp NIFTY-Serve(private):PFA03123@niftyserve.or.jp ============================================================================== From Derrick_Duehren@ccm2.jf.intel.com Mon Nov 7 09:48:47 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08290; Mon, 7 Nov 94 09:48:47 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r4Y7O-000UfmC; Mon, 7 Nov 94 09:44 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r4Y7O-000twdC; Mon, 7 Nov 94 09:44 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 7 Nov 94 09:44:34 PST Date: Mon, 7 Nov 94 09:44:34 PST From: Derrick Duehren Message-Id: <941107094434_1@ccm.hf.intel.com> To: Jerry_Budelman@ccm2.jf.intel.com, Randy_L_Wilhelm@ccm.fm.intel.com, ibis@vhdl.org Subject: IBIS 10/28/94 Meeting Minutes Text item: Text_1 Date: Nov. 7, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum Meeting 10/28/94 To: AT&T Global Info Systems Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec Maah Sango Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, Hoa Quoc, John Burnett Integrated Silicon Systems Eric Bracken Integrity Engineering Greg Doyle Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross*, Scott Bloom Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal Meta-Software Mei Wong, You-Pang Wei, John Sliney NEC Hiroshi Matsumoto MicroSim Arthur Wong National Semiconductor Syed Huq North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn PC Ware Paul Munsey* Quad Design Jon Powell* Quantic Labs Mike Ventham Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier Stanford University Randy Harr Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum* Zeelan Technology George Opsahl, Hiro Moriyasu Mon Seng(?), Stree Co. CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 11/18/94 (916) 356-9999 406223 12/9/94 (916) 356-9999 406224 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ Check-in, Intros, Announcements The following correction was made to the Oct. 7th meeting minutes: Scott Bloom was not present. Will reported on finances. The current balance about $8,900. So far, 8 companies have paid for the 2.0 parser. HP, HyperLynx, Quad Design, Interconnectix, DEC, ATT-GIS, Cadence, and Intel. Quantic reported having the paperwork in process. New Agenda Items: Format of files on vhdl.org. Case sensitivity. Press Updates: The IBIS overview article has been forwarded to EDN mag. (DERRICK IS VERIFYING) Electronic Engineering Times, Oct. 24th, pg 59. IBIS is mentioned several times. Derrick informed the forum that we need an official body to approve press releases and the like. We decided that the Open Forum will act as Communication Approval Committee, approving all notices similar to the approval process for BIRDs. Old AR Will/Derrick: Draft a press release with current status. [No progress made] Progress toward enlisting new IC vendors Will reported that the Intel960(TM) processor family IBIS models are available through Intel sales reps, and soon validated IBIS files will be posted to vhdl.org. Syed reported via the reflector that he has a v2.0 Differential Driver model available for verification only by Simulation vendors on a request basis only. Once he gets feedback, it will be officially released to the IBIS forum. By end Nov., he plans to pass around a v2.0 Differential Receiver model. Jon reported that he believes that IBM is developing IBIS models. Motorola PowerPC IBIS models are available from Motorola under nondisclosure. David Moxley has talked to Integrated Circuit Systems about IBIS; they have since requested [and received] information from Derrick. Will reported that VITAL has made initial inquiries into possible use of IBIS for back-annotation, timing, and buffer strength... Golden Parser, 2.0 Paul reported that a flow of problems has been reported. Two issues need to be decided: 1. What do we want to do about the memory situation? It appears to be a DOS limitation problem. Bob Ross found the problem and Paul duplicated it. They are not using EMS. The latest version of DOS (V6.02) seems to work better. The software that makes EMS available requires a runtime license. GNU compiler for DOS does not have this limitation-- Jon Powell recommends using that compiler. Bob Ward also suggests DPMI S/W from Microsoft. Living up to that standard should make the GP compatible with any memory manager. Arpad suggested putting in a compiler option to choose to not save the memory structures. The default should be to not save the structures. Kellee offered a win32s version that wouldn't have the problem. AR Bob Ross: E-mail Paul info on DPMI. 2. Do we want another Beta? Will wants to see the fixes, and the features that hadn't been implemented for the first Beta. AR Paul: Produce a new disk and give it to Arpad next week. Will Hobbs will distribute the files within 1 day to those who have paid the fee. Bob Ross tried the GP on many 2.0 models, including ECL, differential, and terminators. When he called it 1.1, he got expected errors. When he called it 2.0, he got a few errors, which he reported. Syed's RS232 model worked. Syed sent out a new one yesterday. Paul and Bob discussed rising and falling waveforms; there is nothing in the spec that lists a minimum number of points. AR Stephen: Post something showing rising and falling waveforms... AR Bob R.: Publish BIRD21 specifying a minimum of 2 points. [Done] Stephen ran all of the models on vhdl.org through the parser with no problems as is. Still no problems after re-designating them as 2.0 files. Kellee did similar tests with his set of 50 models. No new bugs were discovered. No one has verified that the files are being correctly parsed, and no one has verified a .pkg file. Kumar volunteered. AR Kumar: Parse some .pkg files. HyperLynx, Interconnectix, Quad, and Cadence expressed interest in getting realistic V2.0 data from Intel, either obfuscated or under nondisclosure. AR Stephen/Derrick: Provide 2.0 IBIS data to the above under nondisclosure. [In process] Will proposed creating a table of features needed to be tested. Stephen volunteered. AR Stephen: Create features/test matrix in ASCII format, post to reflector, collect input on what has been tested, repost as needed. [Table created and posted] Quad ran old models, while waiting on new IBIS models. Spice-to-IBIS Converter Bob Ross reported that a DOS version was created and will be posted. 2.0 BNF Bob Ross commented that the project is ongoing. Some fundamental compatibility issues exist, such as enabling the random sequencing of keywords. This issue may never be addressed. Case Insensitivity Bob Ross expressed his concern about case sensitivity in subparameters. The current parser enforces subparameter case. AR Rob Ross: Create BIRD22 to make subparameters case insensitive. AR Arpad: Tell Paul of this potential change, but don't have him hold up the next Beta for this change. DOS/UNIX File Incompatibility. DOS and UNIX treat CR/LF differently. DOS requires ^M, UNIX does not like it. Kellee proposed giving solving this issue to Paul M. We want the IBIS check program to be insensitive as to whether the IBIS file was created on a DOS or UNIX system. AR Arpad: Inform Paul of this DOS/UNIX quirk. Monotonicity Kellee posted the pre-approved BIRD20 to the great unknown of cyberspace two weeks ago for comments. No one received it. Kellee reposted it this morning. Bob Ross was the only one who had seen it before the meeting. He and others had several issues with it; the discussion will continue on the reflector, and we will rediscuss and vote on it in the next meeting. IBIS General Session (face-to-face) Will proposed that we have our next face-to-face meeting in early December in San Jose. The forum agreed. Agenda suggestions: o 2.1 Ratification o EIA Affiliation o Technology presentations AR Derrick: Coordinate choice of day in early December for the meeting. [In process] Wrap-up, Next Meeting Plans Our next meeting is 11/18/94. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to 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. ============================================================================== From 73053.721@compuserve.com Tue Nov 8 23:23:24 1994 Return-Path: <73053.721@compuserve.com> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25958; Tue, 8 Nov 94 23:23:24 PST Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.940406sam) id CAA03082; Wed, 9 Nov 1994 02:19:16 -0500 Date: 09 Nov 94 02:15:50 EST From: Paul Munsey <73053.721@compuserve.com> To: IBIS Reflector Subject: Golden Parser Beta Message-Id: <941109071549_73053.721_GHB60-1@CompuServe.COM> IBISians, Ron and I have run into some integration problems in the process of combining our fixes. I appologize for the delay in providing a 2nd beta of the 2.x parser, but we have some of our regression tests failing and want to correct the problem before sending another set of files. I know people have been waiting for this next delivery. We will be working to resolve the problems immediately. Thanks for your patience. Paul Munsey From icx!bob@uu4.psi.com Fri Nov 11 17:20:15 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02953; Fri, 11 Nov 94 17:20:15 PST Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23100 for ; Fri, 11 Nov 94 20:09:40 -0500 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Nov 94 16:55 PST Message-Id: Date: Fri, 11 Nov 94 16:55 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, kellyp@xilinx.com Subject: Xilinx IBIS Models Members: This is to inform members that Kerry Pierce of Xilinx is working on IBIS models for Xilinx while temporarily living in Oregon. Kerry contacted me after referals from Don Telian and Will Hobbs, and we plan to provide any assistance he needs. Plans are that he will use the s2ibis utility. I expect that Kerry will be joining the reflector. Please feel free to contact him at kerryp@xilinx.com or (503) 266-1897. Bob Ross, Interconnectix, Inc. From lfs@Synopsys.COM Fri Nov 11 20:03:22 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03846; Fri, 11 Nov 94 20:03:22 PST Received: from atropos.synopsys.com ([146.225.64.26]) by chronos.synopsys.com with SMTP id AA04264 (5.65c/IDA-1.4.4); Fri, 11 Nov 1994 19:57:32 -0800 Received: from clotho.synopsys.com (clotho.synopsys.com [146.225.64.24]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id TAA22701; Fri, 11 Nov 1994 19:57:31 -0800 Received: from tahiti-pc.synopsys.com (tahiti-pc.synopsys.com [146.225.82.18]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id TAA24728; Fri, 11 Nov 1994 19:58:24 GMT Date: Fri, 11 Nov 1994 19:58:24 GMT Message-Id: <199411111958.TAA24728@clotho.synopsys.com> X-Sender: lfs@po1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: billd@vhdl.org, billd@reprise.com, steve_sherwood@mentorg.com, ross_nelson@mentorg.com, frank_binnendyk@mentorg.com, dan_milliron@mentorg.com, archie_lachner@mentorg.com, greg_seltzer@mentorg.com, sherman@netcad.enet.dec.com, biro@ecadsr.enet.dec.com, bandali@lsil.com, ritag@doc.com, wdb@vhdl.com, cpk@cadence.com, filano@vhdl.lmc.com, graham@cfi.org, Will_Hobbs@ccm2.jf.intel.com, subbu@india.ti.com, mano@india.ti.com, vijay@india.ti.com, geoff@cadence.com, gilman@wash.inmet.com, gurup@ichips.intel.com, hnosrat@scdt.intel.com, marc@ichips.intel.com, pkukkal@ichips.intel.com, sankar@ichips.intel.com, wickart@ichips.intel.com, xwang@ichips.intel.com, vmartin@dtc.hp.com, eeteam@pdesds2.scra.org, julianm@lmc.com, christop@vnet.ibm.com, dave@icx.com, peter@icx.com, wasco@icx.com, bob@icx.com, mick@hpfcla.fc.hp.com, marc.laurent@matramhs.fr, apte@omnivw.com, ibis@vhdl.org, vital@vhdl.org, omf@cfi.org, 544-6089@mcimail.com, randy.harr@vhdl.org, stank@compass-da.com, ede@lmc.com, kevinh@lmc.com, pete@lmc.com, jayh@lmc.com, billd@vhdl.org, huangchi@idtinc.com, westbrook@mms.com, blakkan@mms.com, marnow@mms.com, ting@atb.teradyne.com, concha@el.wpafb.af.mil, craig@idtinc.com, harryw@nchip.com, rjg570@email.sps.mot.com, filano@lmc.com, cpk@cadence.com, mick@neptune.fc.hp.com, kahn@cs.man.ac.uk, asg@potomac.wash.inmet.com From: lfs@Synopsys.COM (Larry Saunders) Subject: X-Mailer: The DIET Format Version 0.9 is complete! You may get a copy from the VHDL.ORG machine. It is in /pub/die/diet0-9. Comments would be appreciated. We will review the new version at the DIE Workshop on 12/16. Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-965-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From Will_Hobbs@ccm2.jf.intel.com Mon Nov 14 13:58:21 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06731; Mon, 14 Nov 94 13:58:21 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r79Lg-000UeMC; Mon, 14 Nov 94 13:54 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r79Lg-000twdC; Mon, 14 Nov 94 13:54 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 14 Nov 94 13:54:04 PST Date: Mon, 14 Nov 94 13:54:04 PST From: Will Hobbs Message-Id: <941114135404_3@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Need Minutes-taker for Friday meeting Text item: Text_1 Friends, Romans, IBISians, Lend me your pen. Derrick will not be attending Friday's meeting and I will be on the road without my laptop. Could someone volunteer to do the minutes of this meeting? If you need an earlier set of minutes to use for format, let me know. Thanks in advance. Will From Derrick_Duehren@ccm2.jf.intel.com Tue Nov 15 10:43:04 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18649; Tue, 15 Nov 94 10:43:04 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r7Sm9-000UgjC; Tue, 15 Nov 94 10:38 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r7Sm8-000twfC; Tue, 15 Nov 94 10:38 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 15 Nov 94 10:38:37 PST Date: Tue, 15 Nov 94 10:38:37 PST From: Derrick Duehren Message-Id: <941115103837_29@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 11/18/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 11/18/94 Bridge: Res: (916) 356-9999 406223 All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. **************************************************************************** Derrick will be unavailable Friday and Will will be on the road w/o his laptop. We still need someone to agree to do the minutes for this meeting. **************************************************************************** 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All Golden Parser, 2.1 Hobbs - New Beta BIRD 20, Monotonicity Crisafulli Closure expected BIRD 21, Waveform Table Minimum Number of Entries Ross BIRD 22, Sub-Parameter Case Sensitivity Ross 9:15 IBIS General Session/Summit (face-to-face) Hobbs - Date (December 12 or 14) - Location (San Jose) - Hammer out an agenda - Possible topics: o 2.1 Ratification o EIA Affiliation o Technology presentations 9:55 Wrap-up, next meeting plans Hobbs From olaf@salamix.cadlab.de Thu Nov 17 05:47:31 1994 Return-Path: Received: from mail.Germany.EU.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15217; Thu, 17 Nov 94 05:47:31 PST Received: by mail.Germany.EU.net with SMTP (8.6.5:29/EUnetD-2.5.1.b) via EUnet id OAA26395; Thu, 17 Nov 1994 14:44:39 +0100 Received: by cadlab.cadlab.de (5.51/12.71); Thu, 17 Nov 94 14:42:23 +0100 From: Olaf Rethmeier Date: Thu, 17 Nov 94 14:42:13 +0100 Message-Id: <9411171342.AA13286@salamix.cadlab.de> Received: by salamix.cadlab.de (4.1/12.71); Thu, 17 Nov 94 14:42:13 +0100 Apparently-To: ibis@vhdl.org Dear IBIS-community, we are happy to inform you that the EMC-activities of Siemens Nixdorf have been taken over by INCASES, Germany. This gives us the chance for world wide marketing and support of our EMC-tools. We (Werner Rissiek and Olaf Rethmeier) will join INCASES on December, 1st together with most of the EMC-Workbench development team. Of course, we will stay active in IBIS, so please change only the name of our company. Further details are enclosed in the following Press Release. INCASES Engineering, GmbH, founded on November 1, 1994, has opened its headquarter operations in Paderborn, Germany. INCASES is a supplier of design automation software and consulting services to the electronic design automation (EDA) market. Founded and directed by Martin Nixdorf, INCASES has been formed to develop market, sell and support two major product lines: THEDA, acquired from Computervision Corporation and EMC-Workbench, acquired from Siemens Nixdorf Informationssysteme AG. THEDA, software for printed circuit board design with a focus on `Design for Manufacturability', combined with EMC-Workbench, an integrated tool providing a solution for EMI and signal integrity relevant problems of electrical components, form the core technology of the new company's offering. The company will further develop and market this family of fully integrated software tools providing solutions in end-to-end design in the areas of printed circuit board design, signal integrity analysis and radiation application to their existing global user network. Driven by EMC market needs, INCASES will continue to add products which address radiation problems on the board level as well as on a whole system level design approach. INCASES will distribute their products worldwide with subsidiaries in Germany, France, Italy, U K, The Netherlands and the U.S. Other markets will be serviced through EDA distribution partners. INCASES will provide service and support for the already well-established THEDA customer base, comprised of global users with applications in industries from aerospace, automotive, computing, machinery, medical, consumer electronics and telecommunications which will also profit from the EMC-Workbench developments. The company has taken over the existing THEDA R&D facility and personnel from Computervision as well as major parts of the EMC-Workbench development team from Siemens-Nixdorf. INCASES has entered into an agreement with CADLAB, a R&D laboratory of Siemens-Nixdorf and the University-GH-Paderborn, to support continued development in the area of EMC technology. INCASES has also entered into an agreement with Computervision to ensure continuing product development and integration of THEDA with CV's mechanical CAD tools. Best regards Werner Rissiek Olaf Rethmeier From cpk@Cadence.COM Thu Nov 17 06:31:36 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15679; Thu, 17 Nov 94 06:31:36 PST Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id GAA06944 for ; Thu, 17 Nov 1994 06:27:23 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma006938; Thu Nov 17 06:27:10 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA28872; Thu, 17 Nov 94 06:21:29 -0800 Received: by hot (5.65+/1.5) id AA01767; Thu, 17 Nov 94 09:27:04 -0500 Date: Thu, 17 Nov 94 09:27:04 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9411171427.AA01767@hot> To: ibis@vhdl.org Subject: Re: Re[1]: Draft IBIS 2.0 specification - Modelling of Ac Ramp Parasitics I am posting this at the suggestion of Will hobbs. I had discussions with Stephen Peters of Intel recently regarding the modelling of ramp ac parasitics. I am arguing for switching the location of L_fixture as shown in the Ibis 2.0(1) draft specification. Since we are dealing with "effective" parasitic values , this change may not have any adverse effect on modelling. My case for this change is mainly one of consistency with the way Ldut and Cdut is shown. A bonus , atleast in my view is that the new scheme is even simpler to model. I may not be able to attend tomorrow's session and Stephen has gracefully consented to raise this one. If there are any takers , I will be glad!! - kumar Stephen: My guess is that most of the parasitics in the model represent some "effective" value and may not be purely physical. That is why I prefer a representation which gives higher priority to consistency and simplicity. In my view Cfixture before Lfixture is more consistent and is even simpler to model. Most likely I will not be able to attend the forum this Friday. How do you propose we handle this issue? Can You raise this on my behalf if I am not there? Thanx and regards kumar > > Hello Kumar: > > When I came up with the test fixture R and C I was tring to > match the data book load most TTL and CMOS devices use when specifing > Tco -- a capacitor to ground and a pullup resistor to some voltage. > The L-fixture was an attempt to account for pin inductances due to > sockets, wire, etc. I thought the right order (physically) was an 'L', > in series with the R/C combination. Is a better representation the > C before the L? If it needs to be changed we can, but it should be > brought before the fourum soon before the spec gets approved. > > Regards, > Stephen > > > > Stephen: > > I have question regarding the text fixture waveform models > > $| > $| PACKAGE | TEST FIXTURE > $| _________ | > $| | DUT | L_dut R_dut | L_fixture R_fixture > *| | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture > *| |_________| | | | > *| | | | > *| | | | > $| C_dut === | === C_fixture > *| | | | > *| | | | > $| GND | GND > > > Do you know the text fixture in such a detail to model its parastics > differently from the device > output? If you do not I suggest we use a model like the following > which models the parasitics of the text fixture in the same way as the device. > > If Lfixture is large these two models will produce different results. For small > Lfixture the question is academic and is one of consistency in modelling. > > > - kumar > > > $| > $| PACKAGE | TEST FIXTURE > $| _________ | > $| | DUT | L_dut R_dut | L_fixture R_fixture > *| | die |---@@@@@--/\/\/\--o-----|-o--@@@@------/\/\/\----- V_fixture > *| |_________| | | | > *| | | | > *| | | | > $| C_dut === | === C_fixture > *| | | | > *| | | | > $| GND | GND > ----- End Included Message ----- From JCP%mimi@magic.itg.ti.com Thu Nov 17 10:15:33 1994 Return-Path: Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18088; Thu, 17 Nov 94 10:15:33 PST Received: from itg.ti.com ([128.247.93.50]) by gate.ti.com (8.6.9/) with SMTP id MAA18198 for ; Thu, 17 Nov 1994 12:11:21 -0600 From: JCP%mimi@magic.itg.ti.com Received: by itg.ti.com (4.1/ITG-1.1) id AA19947; Thu, 17 Nov 94 12:10:46 CST Date: Thu, 17 Nov 94 12:10:46 CST Message-Id: <9411171810.AA19947@itg.ti.com> To: Ibis@gate.ti.com, organisation@gate.ti.com, ibis@vhdl.org Subject: MSG From Jean-Claude PERRIN From: Jean-Claude PERRIN jcp@msg.ti.com I am working in Europe on High frequency models that are usable for intergrity and emc simulation. I would appreciate if somebody can answer to my questions.. Is somebody from Texas in US, participates to the IBIS commmittee ? If yes what is the name of the man who is responsible for ? (I did not arrived to get internaly this information) If somebody needs more information on the library developped by IBIS, what is the right way to get it? Many thanks for any help Best Regards Jean Claude Perrin From 71436.1314@compuserve.com Thu Nov 17 12:02:21 1994 Return-Path: <71436.1314@compuserve.com> Received: from dub-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19581; Thu, 17 Nov 94 12:02:21 PST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) id OAA17069; Thu, 17 Nov 1994 14:58:08 -0500 Date: 17 Nov 94 14:53:39 EST From: Kellee Crisafulli <71436.1314@compuserve.com> To: IBIS ALL Subject: Xilinx model library available soon Message-Id: <941117195339_71436.1314_HHB25-1@CompuServe.COM> From: Kellee Crisafulli, HyperLynx An FYI bit of good news. I spoke to Kerry Pierce at Xilinx and offered to give Xilinx the complete model library of Xilinx models we have developed in exchange for Xilinx's assurance that all the models that they create will be placed in the public domain. I spoke to Kerry yesterday and he received confirmation from their marketing department that Xilinx has agreed to place all the IBIS models they develop in public domain. Based on this word of mouth agreement I have emailed the model library to Xilinx. They may choose to make some or all of these models available immediately, or wait and develop all the models in-house. Kellee Crisafulli From 71436.1314@compuserve.com Thu Nov 17 12:23:18 1994 Return-Path: <71436.1314@compuserve.com> Received: from dub-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19715; Thu, 17 Nov 94 12:23:18 PST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) id PAA20058; Thu, 17 Nov 1994 15:19:05 -0500 Date: 17 Nov 94 15:14:42 EST From: Kellee Crisafulli <71436.1314@compuserve.com> To: IBIS ALL Subject: Fixture model Message-Id: <941117201441_71436.1314_HHB97-2@CompuServe.COM> From: Kellee Crisafulli, HyperLynx Re: Changing the fixture model. I am against making the change proposed. The existing model will provide a much beter model of distributed capacitance/inductance than the combined lump of capacitance proposed by Steven/Kumar. If the fixture includes any transmission line effects of distributed L and C for example a circuit board then the existing model is much better. Have a good day, talk to you Friday... Kellee From mbs@eos.ncsu.edu Thu Nov 17 12:36:14 1994 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19799; Thu, 17 Nov 94 12:36:14 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA16384; Thu, 17 Nov 1994 15:31:51 -0500 From: mbs@eos.ncsu.edu Message-Id: <9411172031.AA16384@mbs.ece.ncsu.edu> To: Kellee Crisafulli <71436.1314@compuserve.com> To: IBIS ALL To: kelleecrisafulli@eos.ncsu.edu, hyperlynx@eos.ncsu.edu Subject: Re: Xilinx model library available soon Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Nov 94 15:31:50 EST That is great nes. I will set up the IBIS model library now. Michael Steer ***************************************************************************** Dr. Michael Steer mbs@ncsu.edu Associate Professor 919-515-5191 Electrical and Computer Engineering Department 919-515-5523 (fax) North Carolina State University, Raleigh, NC 27695-7911 From cpk@Cadence.COM Thu Nov 17 12:46:15 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19877; Thu, 17 Nov 94 12:46:15 PST Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id MAA13685 for ; Thu, 17 Nov 1994 12:42:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma013662; Thu Nov 17 12:41:48 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA19795; Thu, 17 Nov 94 12:35:59 -0800 Received: by hot (5.65+/1.5) id AA01866; Thu, 17 Nov 94 15:41:42 -0500 Date: Thu, 17 Nov 94 15:41:42 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9411172041.AA01866@hot> To: ibis@vhdl.org Subject: Re: Re[1]: Draft IBIS 2.0 specification - Modelling of Ac Ramp Parasitics I just got Kellee's response saying that the existing L_fixture is better to model long wires (transmission lines). If such long wires were involved two v-t measurements one on the device side and other on the text fixture side should have been in order and is much superior to indirect modelling. L_fixture should model inductance internal to the fixture and in that case a consistent modelling scheme makes more sense. - kumar From icx!bob@uu4.psi.com Fri Nov 18 15:21:55 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02235; Fri, 18 Nov 94 15:21:55 PST Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15524 for ; Fri, 18 Nov 94 17:58:58 -0500 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Nov 94 14:44 PST Message-Id: Date: Fri, 18 Nov 94 14:44 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: APPROVED BIRD20.1 IBIS Members: BIRD20.1 is an APPROVED version of BIRD20, but contains the text revisions discussed in the November 18, 1994 meeting to replace explicit references to "IBIS_CHK" with a more generic "syntax checking program" verbage. Bob Ross, Interconnectix, Inc. ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 20.1 ISSUE TITLE: Error correction regarding monotonicity statement in V2.1 IBIS specification. REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: 10-10-94 DATE REVISED: 11-18-94 DATE ACCEPTED BY IBIS OPEN FORUM: 11-18-94 ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: There are two errors in the IBIS version 2.1 specification regarding monotonicity. During the meeting on 10-7-94 the IBIS forum agreed to change the specification to correct these errors. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The following changes apply to version 2.1 of the specification and IBIS_CHK program. *************************************************************************** Change 1- Delete the note about 'non-monotonic in one axis' *************************************************************************** In the section defining the keywords [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] and following the paragraph titled "Monotonicity Requirements" the following note is present: | Note that the above conditions allow the data to be | non-monotonic in one axis. The above two lines shall be deleted from the specification. *************************************************************************** Change 2- Add two paragraphs from BIRD 8.2 *************************************************************************** Add the following two paragraphs where the sentence from change 1 above is removed. This is not an error or even a warning. It was down-graded to a simple NOTE: in BIRD 8.2 * * An IBIS syntax checking program shall * test for non-monotonic data and * provide a maximum of one note per V/I table if non-montonic * data is found. For example: * "NOTE: Line 300, Pulldown V/I table for model DC040403 is * non-monotonic! Most simulators will filter this data * to remove the non-monotonic data." * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the IBIS Version 2.0 syntax checking programs, such * programs will conduct monotonicity testing only on one * V/I table at a time. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The problems were discovered while the new IBIS_CHK V2.x program was being written. The problems were reported to the IBIS forum at the 10-7-94 meeting by Arpad of Intel. ORIGINAL BIRD20.0 TEXT: * * The IBIS_CHK program will test for non-monotonic data and * provide a maximum of one note per V/I table if non-montonic * data is found. For example: * "NOTE: Line 300, Pulldown V/I table for model DC040403 is * non-monotonic! Most simulators will filter this data * to remove the non-monotonic data." * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the version 2.0 IBIS_CHK program, it will consider only one * V/I table at a time monotonicity testing. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: Bird 8.2 address's this issue. From speters@ichips.intel.com Fri Nov 18 17:35:30 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02994; Fri, 18 Nov 94 17:35:30 PST Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 18 Nov 94 17:30:42 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 18 Nov 94 17:29:15 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 18 Nov 94 17:30:32 PST Message-Id: <9411190130.AA06392@xtg801.intel.com> To: 73053.721@compuserve.com Cc: ibis@vhdl.org Subject: More Parser Bugs Date: Fri, 18 Nov 1994 17:30:30 -0800 From: Stephen Peters Hello Paul: While testing out the latest version of the parser (ibischk2b) I have uncovered the following problems. 1. The parser allows a minimum or maximum I-V column to begin/end with NA (it does flag an error if this occurs with the typical column). This situation is illegal for all three columns. 2. It is legal for a terminator model to have only the [GND clamp] and [POWER clamp] keywords and not use any of the [Rgnd]/[Power]/[Rac]/ [Cac] keywords. If this occurs the parser currenly flags this as an error. 3. The parser does not recognize the word 'Sparse_matrix' as a legal argument to any of the [Matrix] keywords in the package model section. Other that the above the parser looks very clean. If you receive other feedback please have the person(s) mail the reflector so I can update the test matrix. Thanks. Best Regards, Stephen Peters Intel Corp. From icx!icx.com!scott@uu4.psi.com Sat Nov 19 10:19:23 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11471; Sat, 19 Nov 94 10:19:23 PST Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA14694 for ; Sat, 19 Nov 94 13:09:38 -0500 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 19 Nov 94 09:50 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 19 Nov 94 10:04 PST Message-Id: Date: Sat, 19 Nov 94 10:04 PST From: scott@icx.com ( Scott Aron Bloom) To: 75126.3477@compuserve.com, 73053.721@compuserve.com Subject: Error during compilation of IBISCHK 2.0b Cc: ibis@vhdl.org Paul and Ron: (This may not get to Paul Munsey as his Email address did not look complete) While trying to compile IBISVHK 2.0b I got thie following compile time error "/users/scott/icx/src/ibischk2b/pkgmdl.c", line 340: undefined symbol: sTmpName After looking at the surrounding code, I replaced the variable sTmpName with sTmpFileName Was this the correct change? Scott scott@icx.com Interconnectix, Inc. From icx!bob@uu4.psi.com Sat Nov 19 12:30:26 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12151; Sat, 19 Nov 94 12:30:26 PST Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA01435 for ; Sat, 19 Nov 94 15:24:50 -0500 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 19 Nov 94 12:01 PST Message-Id: Date: Sat, 19 Nov 94 12:01 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD23 - MIN NUMERICAL ENTRIES IBIS Members: BIRD23 provides more detail than BIRD21, which was approved 18Nov94. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 23 ISSUE TITLE: Waveform Table Minimum Number of Numerical Entries REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 19 November 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The minimum required entries for Waveform tables is 2, but clarification is needed similar to that for V/I tables that the first and last entries of any column containing numerical data must NOT be "NA". Note, some of this is already implied by the text above. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: THE NEW CHANGE IS DESIGNATE BY "|***". The [Rising Waveform], [Falling Waveform] keyword description contains an additional sentence designated by "|**" to require at least two table entries for each waveform described. Note, the change approved by BIRD19.1 is still shown by "|*". |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. |* Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, |* C_fixture, L_fixture, | R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. |** Each table must contain at least two entries. |*** Thus, numerical values are required for the first and last |*** entries of any column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut Sub-params are analogous to the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used, its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | |* V_fixture defines the voltage for typ, min and max |* supply conditions. However, when the fixture voltage |* is related to the power supply voltages, then the |* sub-parameters V_fixture_min and V_fixture_max can |* be used to further specify the fixture voltage for |* min and max supply voltages. |* |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 |* V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc |* V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Paul Munsey indicated that no minimum number of Waveform table entries were explicitly specified. This addition creates an explicit requirement similar to the documentation of the [Pullup], [Pulldown], [Power Clamp] and [Gnd Clamp] tables. As a minimum, two entries could define the starting and ending points of the total ramp transition and be compatible with the [Ramp] keyword specification. Further clarification is provided concerning the first and last entry of any column containing numerical data. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION From moxley@eagle.ColumbiaSC.NCR.COM Mon Nov 21 06:47:38 1994 Return-Path: Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02219; Mon, 21 Nov 94 06:47:38 PST From: moxley@eagle.ColumbiaSC.NCR.COM >From: moxley@eagle (David.Moxley) Message-Id: <9411210943.ZM9318@eagle> Date: Mon, 21 Nov 1994 09:43:28 -0500 In-Reply-To: scott@icx.com ( Scott Aron Bloom) "Error during compilation of IBISCHK 2.0b" (Nov 19, 10:04am) References: X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis@vhdl.org Subject: Re: Error during compilation of IBISCHK 2.0b Content-Type: text Content-Length: 829 On Nov 19, 10:04am, Scott Aron Bloom wrote: > Subject: Error during compilation of IBISCHK 2.0b > Paul and Ron: > (This may not get to Paul Munsey as his Email address did not > look complete) > > While trying to compile IBISVHK 2.0b I got thie following compile time > error > > "/users/scott/icx/src/ibischk2b/pkgmdl.c", line 340: undefined symbol: sTmpName > > After looking at the surrounding code, I replaced the variable sTmpName with > sTmpFileName > > Was this the correct change? > > Scott > scott@icx.com > Interconnectix, Inc. >-- End of excerpt from Scott Aron Bloom Scott, I got the same error and made the same correction when compiling on a Unix system. Email was sent to Paul on Friday but I don't know if it was received. David Moxley AT&T Global Information Solutions moxley@eagle.columbiasc.ncr.com From Derrick_Duehren@ccm2.jf.intel.com Mon Nov 21 10:05:40 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03526; Mon, 21 Nov 94 10:05:40 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r9d3H-000Ug4C; Mon, 21 Nov 94 10:01 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r9d3H-000twfC; Mon, 21 Nov 94 10:01 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 21 Nov 94 10:01:19 PST Date: Mon, 21 Nov 94 10:01:19 PST From: Derrick Duehren Message-Id: <941121100119_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Draft Ver 2.1 on vhdl.org Text item: Text_1 Per Bob Ross's request, I posted his draft 2.1 spec (after I made a few formatting tweaks) to vhdl.org. It is in \ibis\ver2.1\. I also posted an updated roster.txt file. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | "Experience is not what happens to Phone (503) 696-4299 | you; it's what you do with what Fax (503) 696-4904 | happens to you." Derrick_Duehren@ccm.jf.intel.com | - Aldous Huxley 5200 NE Elam Young Pkwy. JF1-97 | Hillsboro, OR 97224 | ------------------------------------------------------------------------------ From lfs@Synopsys.COM Mon Nov 21 13:24:51 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00967; Mon, 21 Nov 94 13:24:51 PST Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA10008 (5.65c/IDA-1.4.4); Mon, 21 Nov 1994 13:06:04 -0800 Received: from clotho.synopsys.com (clotho.synopsys.com [146.225.64.24]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id NAA14669; Mon, 21 Nov 1994 13:06:02 -0800 Received: from tahiti-pc.synopsys.com (tahiti-pc.synopsys.com [146.225.82.18]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id NAA24005; Mon, 21 Nov 1994 13:05:57 -0800 Date: Mon, 21 Nov 1994 13:05:57 -0800 Message-Id: <199411212105.NAA24005@clotho.synopsys.com> X-Sender: lfs@po1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: huangchi@idtinc.com, westbrook@mms.com, blakkan@mms.com, marnow@mms.com, ting@atb.teradyne.com, concha@el.wpafb.af.mil, craig@idtinc.com, harryw@nchip.com, rjg570@email.sps.mot.com, dietech@vhdl.com, ede@lmc.com, kevinh@lmc.com, pete@lmc.com, jayh@lmc.com, stank@compass-da.com, randy.harr@vhdl.org, 544-6089@mcimail.com, omf@cfi.org, vital@vhdl.org, ibis@vhdl.org, billd@reprise.com, steve_sherwood@mentorg.com, ross_nelson@mentorg.com, frank_binnendyk@mentorg.com, dan_milliron@mentorg.com, archie_lachner@mentorg.com, greg_seltzer@mentorg.com, sherman@netcad.enet.dec.com, biro@ecadsr.enet.dec.com, bandali@lsil.com, ritag@doc.com, wdb@vhdl.com, cpk@cadence.com, filano@vhdl.lmc.com, graham@cfi.org, Will_Hobbs@ccm2.jf.intel.com, subbu@india.ti.com, mano@india.ti.com, vijay@india.ti.com, geoff@cadence.com, gilman@wash.inmet.com, gurup@ichips.intel.com, hnosrat@scdt.intel.com, marc@ichips.intel.com, pkukkal@ichips.intel.com, sankar@ichips.intel.com, wickart@ichips.intel.com, xwang@ichips.intel.com, vmartin@dtc.hp.com, eeteam@pdesds2.scra.org, julianm@lmc.com, christop@vnet.ibm.com, dave@icx.com, peter@icx.com, wasco@icx.com, bob@icx.com, mick@hpfcla.fc.hp.com, marc.laurent@matramhs.fr, apte@omnivw.com, kahn@cs.man.ac.uk, mick@neptune.fc.hp.com From: lfs@Synopsys.COM (Larry Saunders) Subject: X-Mailer: I sent this note out about a week ago but got several requests for instructions on how to access DIET information on the VHDL.ORG machine. See the instructions below. >The DIET Format Version 0.9 is complete! > >You may get a copy from the VHDL.ORG machine. It is in /pub/die/diet0-9. > >Comments would be appreciated. We will review the new version at the >DIE Workshop on 12/16. This document and related information are available from the VHDL International Internet Services machine. Dial-Up access: Dial-up the VHDL.org system at (415) 335-0110. Any baud (up to 14,400), parity, start & stop bits, and v.* settings will do. Login using the "guest" account. Once in, simple UNIX commands such as "cd pub/die", "ls" and "cat" are available. You can download any desired files using "kermit", "xmodem" or "sz" (zmodem). Internet access: Use "ftp VHDL.org" (or "ftp 198.31.14.3") and login as user "anonymous". Remember to set "binary" mode for any binary files you may select. Also, gopher is available and highly recommended if you have it available. Email access: There is an email FTP archive server on the machine. Send an email message to archive@VHDL.org. The subject is ignored. If a line in the body of the message begins with "help", then a descriptive help file of commands is sent. Basically, you communicate to the server through commands in the mail message body. It then responds to your commands via email. You should always add the command "path " to any message to assure the return address is understood. The following example assumes you have initiated a mail message to archive@VHDL.org. The body of the email message should be:. path lfs@synopsys.com Email address to send results to send pub/die/diet0-9/ diet0-9.ps For a postscript file of the DIET document send pub/die/diet0-9/diet0-9.rtf For a RTF file of the DIET document send pub/die/diet0-9/example.tim For a text file containing format examples send pub/die/diet0-9/diet0-9.exe For the MS-DOS ZIP'ed version of the entire package Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-965-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From icx!bob@uu4.psi.com Mon Nov 21 14:54:53 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02109; Mon, 21 Nov 94 14:54:53 PST Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA13156 for ; Mon, 21 Nov 94 16:55:28 -0500 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 21 Nov 94 13:29 PST Message-Id: Date: Mon, 21 Nov 94 13:29 PST From: bob@icx.com ( Bob Ross) To: 73053.721@compuserve.com, ibis@vhdl.org Subject: IBISCHK2 Questions Paul and Stephen, Here are some comments regarding items #1 and #2. #1 ################################################################################ Technically I believe the intention was to require that ANY column which contains a MIXTURE of NA and Numerical Data MUST have as the FIRST and LAST entry in that column a NUMERICAL entry. Furthermore, "min" and "max", but NOT "typ" columns may consist entirely of NAs. In the minutes for the 7/30/93 meeting over a year ago and just prior to IBIS Version 1.1 ratification and the conclusion of the IBIS_CHK check project, there were stated some requirements: "Requirements: * NAs are acceptable in linear regions * There must be no NAs in the first or last place in a column. The parser must check for conformance to this rule. * There should be a strict algorithm (linear interpolation) for generating missing points * There should be no interpolation between columns" At that time there was controversy over the usage and meaning of "NAs". Whether the second requirement correctly captured the context could be open for interpretation because a subtantial part of the discussion was focused on the typical column. In any case, the original IBIS_CHK program checks for compliance to the second requirement only for the "typ" column, but NOT for the "min" and "max" columns, as you stated. There are three choices for action: (1) Do nothing, IBISCHK2 is consistent with IBIS_CHK and does NOT check min and max columns. (2) Introduce the check into IBISCHK2 based on the interpretation that any column with numerical data must start and end with numerical data. Produce an ERROR message if this is violated. (3) Same as (2) but produce a WARNING message for a violation in the min and max columns only. My personal preference is to go with (3) as a compromise posiiton to capture the intention of the specification, but also to preserve compliance with the previous interpretation (although I do not know of any practical models that violate the strict interpretation). My second choice and "official" recommendation is to go with (2) since one intent of requiring a beginning and ending numerical entry for all columns is to allow parsering of all columns containing numerical data to be done in a consistent manner (by the same procedures). This also should make your task easier. I have other reasons why (2) is acceptable, but I do not want to get into the details at this time. #2 ################################################################################ Paul, your point is well taken that there are some confusing portions with respect to the Terminator model keywords. The reference diagram in the specification titled "Terminator Model" gives a model which contains the [Rpower], [Rgnd], [Rac], and [Cac] elements AND also the [Power clamp] and [Gnd clamp] elements. Also the C_comp, L_pkg (or L_pin), C_pkg (or C_pin), and R_pkg (or R_pin) parameters are shown. | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword | | | / Sub-parameters | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND With the exception of the ADDITIONAL components [Rpower], [Rgnd], [Rac], and [Cac] the Terminator model is the same as the Input model. However, unlike the Input model, it does not require Vinh and Vinl entries. Because the keywords [Rpower], [Rgnd], [Rac], and [Cac] may be treated differently in different simulators and because these new elements most likely do not exist in everyone's Input model, a restriction was imposed that if these keywords exist, then the Model_type MUST be Terminator. What is NOT stated is the converse. The Terminator model may contain ANY (consistent with their individual requirements) of the elements of the reference diagram. Thus a Terminator model may consist of only the [Gnd clamp] or [Power clamp] models since diode "terminators" are classified in practice with the selection of available terminators. Moreover, a Terminator type input can be constructed WITHOUT any of the keywords, but with just the package and C_comp elements (requried even if set to 0) alone. This is consistent with the Input model rules. In the [Model] keyword description, there is another clarifying statement: | Terminator This model type is an input-only device that | can have analog loading effects on the | circuit being simulated but has no digital | logic thresholds. Examples of Terminators | are: capacitors, termination diodes, and | pull-up resistors. ################################################################################### Attached for reference is the previous discussions on these subjects. I hope this helps. Bob Ross, Interconnectix, Inc. From: Paul Munsey <73053.721@compuserve.com> To: Stephen Peters Cc: Ron Neville <75123.3477@compuserve.com>, Bob Ross Subject: More Parser Bugs Message-Id: <941120024232_73053.721_GHB29-1@CompuServe.COM> Status: RO Stephen, In reference to item #1, it could well be that I've misread the spec. I assume you're referring to where it says: All four columns are required under these keywords, however data is only required in the typical column. If minimum and/or maximum current values are not available, the reserved word "NA" must be used. "NA" can be used for currents in the typical column, but numeric values MUST be specified for the first and last voltage points on any V/I curve. It seems to me that you're interpretting "any V/I curve" (in the last sentence) to refer to the typical, minimum, and maximum columns. I interpreted it to refer to "pullup", "pulldown", "gnd clamp", and "power clamp". Thinking that way, along with the first sentence saying "however data is only required in the typical column", I've only checked the typical column for 'NA' in it's first and last voltage points. This was also true in the v1.1 parser, so I've duplicated it's behavour here. Since there's the opportunity for confusion here I've cc'd Bob Ross to verify/clarify this. In reference to item #2, I think some of the wording in the spec leads to confusion here, so any clarification is useful. Here's some of the spec that seems to speak to this: In the [Rgnd], ... section it says "When [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the Model_type must be Terminator". It also says under the "Required" entry, "Yes, if they exist in the device". Both of these are consistent with what you've stated. However, in the "Other Notes" section of keyword "[Model]" it says "A Terminator model uses one or more of the [Rgnd], [Rposer], [Rac], and [Cac]." The term "one or more" is why I made the decision to give an error if none of them were specified for Terminator. Bob, could you clarify both of these for me just to make sure I get it correct? I'll wait for your response before I fix these. Stephen, thanks for your input. Paul Munsey ---------- Forwarded Message ---------- From: Stephen Peters, INTERNET:speters@ichips.intel.com TO: Paul Munsey, 73053,721 (unknown), 71436,1314 (unknown), 74012,21 DATE: 11/18/94 5:46 PM To: 73053.721@compuserve.com Cc: ibis@vhdl.org Subject: More Parser Bugs Date: Fri, 18 Nov 1994 17:30:30 -0800 From: Stephen Peters Hello Paul: While testing out the latest version of the parser (ibischk2b) I have uncovered the following problems. 1. The parser allows a minimum or maximum I-V column to begin/end with NA (it does flag an error if this occurs with the typical column). This situation is illegal for all three columns. 2. It is legal for a terminator model to have only the [GND clamp] and [POWER clamp] keywords and not use any of the [Rgnd]/[Power]/[Rac]/ [Cac] keywords. If this occurs the parser currenly flags this as an error. 3. The parser does not recognize the word 'Sparse_matrix' as a legal argument to any of the [Matrix] keywords in the package model section. Other that the above the parser looks very clean. If you receive other feedback please have the person(s) mail the reflector so I can update the test matrix. Thanks. Best Regards, Stephen Peters Intel Corp. From Derrick_Duehren@ccm2.jf.intel.com Mon Nov 21 16:33:02 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03087; Mon, 21 Nov 94 16:33:02 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r9j6A-000UepC; Mon, 21 Nov 94 16:28 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r9j69-000twdC; Mon, 21 Nov 94 16:28 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 21 Nov 94 16:28:40 PST Date: Mon, 21 Nov 94 16:28:40 PST From: Derrick Duehren Message-Id: <941121162840_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Version 2.1, Draft to be voted 12/9/94 Text item: Text_1 IBISians, Attached (and posted to \ibis\ver2.1\ on vhdl.org) is the draft 2.1 spec. We hope to ratify this draft at our 12/9/94 teleconference meeting. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ Text item: ver2_1.txt 11/21/94 9:43A Will, Derrick, Stephen: I plan to MAIL this on MONDAY. Please do a quick check of this for accuracy and any other spelling/text changes that are needed. You can identify the few changes plus a few other lines by doing "grep * ". Holding this for a few days also gives me a chance to proof the text. Let's make contact Monday afternoon regarding action on this draft. Derrick, can you still POST stuff on vhdl.org. I do not have "ftp" or "gopher" here, so I would otherwise have to mail this to Michael Steer or Steve denBeste for POSTING. Bob Ross, Interconnectix, Inc. |****************************************************************************** |* DRAFT OF IBIS VERSION 2.1 CONTAINING IBIS VERSION 2.0 PLUS: |* |* CHANGES FROM BIRD18.2, BIRD19.1, BIRD20.1, BIRD21, and PENDING BIRD23. |* SOME TEXT UPDATES OF DATES, CASE CORRECTIONS AND MINOR CLARIFICATIONS. |* |* All lines with "|*" indicated changes from Version 2.0. |* All Header lines starting with "|" are for information and are NOT part |* of the Specification. |****************************************************************************** |============================================================================== |* I/O Buffer Information Specification (IBIS) Version 2.1 (12/9/94) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================== | Statement of Intent: | | In order to enable an industry standard method to electronically transport | IBIS Modeling Data between silicon vendors, simulation software vendors, and | end customers, this template is proposed. The intention of this template is | to specify a consistent format that can be parsed by software, allowing each | simulation vendor to derive models compatible with their own product. | | One goal of this template is to represent the current state of IBIS data, | while allowing a growth path to more complex models / methods (when deemed | appropriate). This would be accomplished by a revision of the base | template, and possibly the addition of new keywords or categories. | | Another goal of this template is to ensure that it is simple enough for | silicon vendors and customers to use and modify, while ensuring that it is | rigid enough for software simulation vendors to write reliable parsers. | | Finally, this template is meant to contain a complete description of the I/O | elements on an entire component. Consequently, several models will need to | be defined in each file, as well as a table that equates the appropriate | buffer to the correct pin and signal name. | | Version 2.0 of this electronic template was finalized by an industry-wide | group of simulation experts representing various companies and interests. | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | ASCII file format. It represents the minimum amount of I/O buffer | information required to create an accurate IBIS model of common CMOS and | bipolar I/O structures. Future revisions of the ASCII file will add items | considered to be "enhancements" to Version 1.0 to allow accurate modeling | of new, or other, I/O buffer structures. Consequently, all future | revisions will be considered super sets of Version 1.0, allowing backward | compatibility. In addition, as modeling platforms develop support for | revisions of the IBIS ASCII template, all previous revisions of the | template must also be supported. | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | comments have been added for further clarification. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | |* Version 2.1 update. The file "ver2_1.ibs" contains some clarification |* text changes and corrections and two additional waveform parameters |* beyond Version 2.0. |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. File names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no-connect pins, | NA - used where data not available. | | 3) File names used in the file must only have lower case characters to | enhance UNIX compatibility and must conform to DOS rules. (The length of | a file name should not exceed eight plus three characters and it must | not contain special characters which are illegal in DOS). | | 4) The file must have no more than 80 characters per line. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment char] to any other character. The [Comment char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | | 7) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, and Henries.) The | parser looks at only one alphabetic character after a numerical entry, | therefore it is enough to use only the prefixes to scale the parameters. | However, for clarity, it is allowed to use full abbreviations for the | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | allowed (e.g., 1.2345e-12). | | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) Currents are considered positive when their direction is into the | component. | | 11) All temperatures are represented in degrees Celsius. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |------------------------------------------------------------------------------ | |* [IBIS Ver] 2.1 | Used for template variations | |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment char] keyword. The following | characters can NOT be used: A B C D E F G H I J K L M N O P | Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u | v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + - | Other Notes: The [Comment char] keyword can be used throughout the file, as | desired. |------------------------------------------------------------------------------ [Comment char] |_char | ============================================================================== | Keyword: [File name] | Required: Yes | Description: Specifies the name of the IBIS file, "filename.ibs". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ibs". |------------------------------------------------------------------------------ |* [File name] ver2_1.ibs | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely |------------------------------------------------------------------------------ [File Rev] 1.0 | Used for .ibs file variations | |============================================================================== | Keywords: [Date] [Source] [Notes] [Disclaimer] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: These keywords/arguments can contain blanks, and be of | any format. The [Date] keyword argument is limited to a | maximum of 40 characters. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |------------------------------------------------------------------------------ |* [Date] 12/09/94 | The latest file revision date | [Source] Put originator and the source of information here. For example: From silicon level SPICE model at Intel. From lab measurement at IEI. Compiled from manufacturer's data book at Quad Design, etc... | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the Component Name must not exceed 40 characters, | and blank characters are allowed. | | NOTE: Blank characters are not recommended due to usability | issues. |------------------------------------------------------------------------------ [Component] 7403398 MC452 | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies the component's manufacturer. | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines a range of values for the default packaging resistance, | inductance, and capacitance of the component pins. | Sub-Params: R_pkg, L_pkg, C_pkg | Usage Rules: The typical (typ) column must be specified. If data for the | other columns are not available, they must be noted with "NA". | Other Notes: If RLC parameters are available for individual pins, they can | be listed in columns 4-6 under keyword [Pin]. The values | listed in the [Pin] description section override the default | values defined here. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |------------------------------------------------------------------------------ [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF | |============================================================================== | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pins and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, associates the I/O model for that | pin. Each model_name must have a [Model] keyword below, | unless it is a reserved model name (POWER, GND, or NC). | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |------------------------------------------------------------------------------ [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF | |============================================================================== | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. | Spaces are allowed in the name. The name should include the | company name or initials to help ensure uniqueness. The | simulator will search for a matching package model name as an | argument to a [Define Package Model] keyword in the current | IBIS file first. If a match is not found, the simulator will | look for a match in an external .pkg file. If the package | model is in a separate .pkg file, it must be kept in the same | directory as the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that part. | The specification permits .ibs files to contain [Define | Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models | that have the same name. |------------------------------------------------------------------------------ [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Pin Mapping] | Required: No |Description: Used to indicate which power and ground buses a given driver, | receiver, or terminator is connected. | Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref |Usage Rules: Each power and ground bus is given a unique name which must | not exceed 15 characters. The first column contains a pin | number. Each pin number must match one of the pin numbers | declared previously in the [Pin] section of the IBIS file. | The second column, pulldown_ref, designates the ground bus | connections for that pin. Here the term ground bus can | also mean another power bus. The third column pullup_ref | designates the power bus connection. The forth and fifth | columns gnd_clamp_ref and power_clamp_ref contain | entries, if needed, to specify different ground bus | and power bus connections than those previously specified. | | If the [Pin Mapping] keyword is present, then the bus | connections for EVERY pin listed in the [Pin] section must | be given. | | Each line must contain either three or five columns. Use the | NC reserved word for entries that are not needed or that follow | the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose |* model_name is POWER or GND. | | If a pin has no connection, then both the pulldown_ref | and pullup_ref sub-parameters for it will be NC. | | GND and POWER pin entries and buses are designated by | entries in either the pulldown_ref or pullup_ref columns. | There is no implied association to any column other than | through explicit designations in other pins. | | For any other type of pin, the pulldown_ref column contains | the power connection for the [Pulldown] table for non-ECL type | [Models]. This is also the power connection for the [GND Clamp] | table and the [Rgnd] model unless overridden by a specification | in the gnd_clamp_ref column. | | Also, the pullup_ref column contains the power connection | for the [Pullup] table and, for ECL type models, the [Pulldown] | table. This is also the power connection for the [POWER Clamp] | table and the [Rpower] model unless overridden by a | specification in the power_clamp_ref column. | | The column length limits are: | [Pin Mapping] 5 characters max | pulldown_ref 15 characters max | pullup_ref 15 characters max | gnd_clamp_ref 15 characters max | power_clamp_ref 15 characters max | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |--------------------------------------------------------------------------- [Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref | 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP 5 GNDBUS2 PWRBUS2 NC PWRCLAMP 6 GNDBUS2 PWRBUS2 GNDCLMP NC | Some possible clamping connections | . | are shown above for illustration | . | purposes | . 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. | . 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC | . 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. | . 41 NC PWRBUS2 | Second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================== |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |****************************************************************************** |* BIRD18.2 TEXT CHANGE |****************************************************************************** |*Usage Rules: Enter only differential pin pairs. The first column, |* [Diff Pin], contains a non-inverting pin number. The second |* column, inv_pin, contains the corresponding inverting pin number |* for I/O output. Each pin number must match the pin |* numbers declared previously in the [Pin] section of the IBIS |* file. The third column, vdiff, contains the specified |* output and differential threshold voltage between pins if |* the pins are Input or I/O model types. For output only |* differential pins, the vdiff entry is 0V. The forth, fifth, |* and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, |* contain launch delays of the non-inverting pins relative to |* the inverting pins. The values can be either polarity. ****************************************************************************** | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh and | Vinl. | | If vdiff is not defined for a pin that is defined as requiring a | Vinh by its [Model] type, vdiff is set to the default value of | 200mV. | |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | one [Model] to be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is interpreted as the | tdelay_typ value. When using six columns, the headers | tdelay_min and tdelay_max must be listed. Entries for the | tdelay_min column are based on minimum magnitudes; and | tdelay_max column, maximum magnitudes. One entry of vdiff, | regardless of its polarity, is used for difference magnitudes. |--------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V | |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes. | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref, | Rref, Vref | Usage Rules: Each model type must begin with the keyword [Model]. | The model name must match the one that is listed under | the [Pin] keyword and must not contain more than 20 characters. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that use reserved words (POWER, GND and | NC). Model names with reserved words are an exception and they | do not have to have a corresponding [Model] keyword. | | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type is an input-only device that | can have analog loading effects on the | circuit being simulated but has no digital | logic thresholds. Examples of Terminators | are: capacitors, termination diodes, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | |* 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | |* Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The | Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as |* either as Non-Inverting or Inverting, and the Enable sub- |* parameter can be defined as either Active-High or Active-Low. | | The Cref and Rref sub-parameters correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the | manufacturer uses for the component. Include Cref, Rref, and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of these keywords. For | example, an input structure normally only needs the | [Voltage Range], [GND Clamp], and possibly the [POWER Clamp] | keywords. If one or more of [Rgnd], [Rpower], [Rac], and [Cac] | keywords are used, then the Model_type must be Terminator. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== | Keyword: [Temperature Range] | Required: Yes, if other than the preferred 0, 50, 100 degree C range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], | [POWER Clamp Reference], and [GND Clamp Reference] are not | present |Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the pull-up and [POWER Clamp] V/I data is | referenced. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |--------------------------------------------------------------------------- | variable typ min max [Voltage Range] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [Pullup Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | pull-up V/I data. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_r values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pullup Reference] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [Pulldown Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a power supply rail other than 0V as the reference | voltage for the pull-down V/I data. If this keyword is not | present, the voltage data points in the pull-down V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the typ, min, and max dV/dt_f values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pulldown Reference] 0V 0V 0V | |============================================================================== | Keyword: [POWER Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | [POWER Clamp] V/I data. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Refer the "Other Notes" section of the [GND Clamp Reference] | keyword. |--------------------------------------------------------------------------- | variable typ min max [POWER Clamp Reference] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [GND Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a power supply rail other than 0V as the reference | voltage for the [GND Clamp] V/I data. If this keyword is not | present, the voltage data points in the [GND Clamp] V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Power Supplies: It is intended that standard TTL and CMOS | devices be specified using only the [Voltage Range] keyword. | However, in cases where the output characteristics of a device | depend on more than a single supply and ground, or a pull-up, | pull-down, or clamp structure is referenced to something other | than the default supplies, use the additional 'reference' | keywords. | | If the [Voltage Range] keyword is not present, then all four of | the other keywords must be present. If the [Voltage Range] | keyword is present, the other keywords are optional and may or | may not be used as required. It is legal (although redundant) | for an optional keyword to specify the same voltage as specified | by the [Voltage Range] keyword. |---------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================== | Keywords: [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves of | the pull-down and pull-up structures of an output buffer and | the V/I curves of the clamping diodes connected to the GND and | the POWER pins, respectively. Currents are considered positive | when their direction is into the component. | | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: The V/I curve of the [Pullup] and the [POWER Clamp] structures | are 'Vcc relative', meaning that the voltage values are | referenced to the Vcc pin. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage range], [Pullup Reference], or [POWER Clamp Reference] | keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5V in the table actually | means 5V above Vcc, which is +10V with respect to ground; | and 10V means 10V below Vcc, which is -5V with respect to | ground. Vcc-relative data is necessary to model a pull-up | structure properly, since the output current of a pull-up | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | | When tabulating data for ECL devices, the data in the pull-down | table is measured with the output in the 'logic low' state. | In other words, the data in the table represents the V/I | characteristics of the output when the output is at the most | negative of its two logic levels. Likewise, the data in the | pull-up table is measured with the output in the 'logic one' | state and represents the V/I characteristics when the output | is at the most positive logic level. Note that in BOTH of | these cases, the data is referenced to the Vcc supply voltage, | using the equation Vtable = Vcc - Voutput. | | Monotonicity Requirements: | To be monotonic, the V/I table data must meet any one of the | following 8 criteria: | 1- The CURRENT axis either increases or remains constant as | the voltage axis is increased. | 2- The CURRENT axis either increases or remains constant as | the voltage axis is decreased. | 3- The CURRENT axis either decreases or remains constant as | the voltage axis is increased. | 4- The CURRENT axis either decreases or remains constant as | the voltage axis is decreased. | | 5- The VOLTAGE axis either increases or remains constant as | the current axis is increased. | 6- The VOLTAGE axis either increases or remains constant as | the current axis is decreased. | 7- The VOLTAGE axis either decreases or remains constant as | the current axis is increased. | 8- The VOLTAGE axis either decreases or remains constant as | the current axis is decreased. | |****************************************************************************** |* BIRD20.1 TEXT DELETION - DELETE THE FOLLOWING SENTENCE |****************************************************************************** |* Note that the above conditions allow the data to be |* non-monotonic in one axis. |****************************************************************************** |* BIRD20.1 TEXT ADDITION |****************************************************************************** |* An IBIS syntax checking program shall test for non-monotonic |* data and provide a maximum of one note per V/I table if |* non-montonic data is found. For example: |* "NOTE: Line 300, Pulldown V/I table for model DC040403 is |* non-monotonic! Most simulators will filter this data |* to remove the non-monotonic data." |* |* It is also recognized that the some data may be monotonic if |* currents from both the output stage and the clamp diode are |* added together as most simulators do. To limit the complexity |* of the IBIS Version 2.0 syntax checking programs, such |* programs will conduct monotonicity testing only on one |* V/I table at a time. |****************************************************************************** | | It is assumed that the simulator sums the clamp curves | together with the appropriate pull-up or pull-down curve when | a buffer is driving high or low, respectively. From this | assumption and the nature of 3-statable buffers, it follows | that the data in the clamping curve sections are handled as | constantly present curves and the pull-up and pull-down curves | are used only when needed in the simulation. | | The clamp curves of an input or I/O buffer can be measured | directly with a curve tracer, with the I/O buffer 3-stated. | However, sweeping enabled buffers results in curves that are | the sum of the clamping curves and the output structures. | Based on the assumption outlined above, the pull-up and | pull-down curves of an IBIS model must represent the | difference of the 3-stated and the enabled buffer's curves. | (Note that the resulting difference curve can demonstrate a | non-monotonic shape.) This requirement enables the simulator | to sum the curves, without the danger of double counting, and | arrive at an accurate model in both the 3-stated and enabled | conditions. | | Since in the case of a non 3-statable buffer, this difference | curve cannot be generated through lab measurements (because | the clamping curves cannot be measured alone), the pull-up and | pull-down curves of an IBIS model can contain the sum of the | clamping characteristics and the output structure. In this | case, the clamping curves must contain all zeroes, or the | keywords must be omitted. |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | |============================================================================== | Keywords: [Rgnd], [Rpower], [Rac], [Cac] | Required: Yes, if they exist in the device | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and the POWER pins, | respectively. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for C(typ), C(min), and C(max) must be placed on a single line | and must be separated by at least one white space or tab | character. All three columns are required under these | keywords. However, data is only required in the typical | column. If minimum and/or maximum values are not available, | the reserved word "NA" must be used indicating the R(typ) or | C(typ) value by default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND Clamp Reference] | voltages, if defined, apply to [Rgnd]. [POWER Clamp Reference] | voltages, if defined, apply to [Rpower]. Either or both [Rgnd] | and [Rpower] may be defined and may coexist with [GND Clamp] |* and [POWER Clamp] structures. If the terminator consists |* of a series R and C (often referred to as either an AC or RC |* terminator), then both [Rac] and [Cac] are required. When | [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the | Model_type must be Terminator. | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword | | | / Sub-parameters | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator [Rpower] 220Ohm 200Ohm NA | [Rac] 30Ohm NA NA | | variable C(typ) C(min) C(max) | AC terminator [Cac] 50pF NA NA | |============================================================================== | Keyword: [Ramp] | Required: Yes, except for inputs and terminators | Description: Defines the rise and fall times of a buffer. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load sub-parameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |****************************************************************************** |* BIRD19.1 TEXT CHANGE AND ADDITIONS Designated by "|*" |* BIRD21 TEXT ADDITION Designated by "|**" |* PENDING BIRD23 TEXT ADDITION Designated by "|***" |****************************************************************************** |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. |* Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, |* C_fixture, L_fixture, | R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. |** Each table must contain at least two entries. |*** Thus, numerical values are required for the first and last |*** entries of any column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut Sub-params are analogous to the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used, its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | |* V_fixture defines the voltage for typ, min, and max |* supply conditions. However, when the fixture voltage |* is related to the power supply voltages, then the |* sub-parameters V_fixture_min and V_fixture_max can |* be used to further specify the fixture voltage for |* min and max supply voltages. |* |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 |* V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc |* V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | |****************************************************************************** |============================================================================= | | PACKAGE MODELING | | The [Package Model] keyword is optional. If more than the default RLC | package model is desired, use the [Define Package Model] keyword. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... | [End Package Model] keywords for each package model that is defined. For | reference, these keywords are listed below. Full descriptions follow. | Simulators that do not support these keywords will ignore all entries between | the [Define Package Model] and [End Package Model] keywords. | | [Define Package Model] Required if the [Package Model] keyword is used | [Manufacturer] Required* | [OEM] Required* | [Description] Required* | [Number of Pins] Required* |* [Pin Numbers] Required* | [Model Data] Required* | [Resistance Matrix] Optional | [Inductance Matrix] Required* | [Capacitance Matrix] Required* | [Bandwidth] Required (for Banded_matrix matrices only) | [Row] Required* | [End Model Data] Required* | [End Package Model] Required* | | * when the [Define Package Model] keyword is used | | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | | USAGE RULES FOR THE .PKG FILE | | Package models are stored in a file whose name looks like: | .pkg. | | The provided must adhere to the General Syntax Rules. Use the | ".pkg" extension to identify files containing package models. The .pkg file | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg | file. The .pkg file is for package models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package | model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes | Description: Declares the manufacturer of the package. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of | what kind of package the [Package Model] is representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |============================================================================== | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the package | pins, and to define an ordering of them. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." The pin names can not exceed 5 characters in | length. | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) |------------------------------------------------------------------------------ [Pin Numbers] A1 A2 | . | . | . A22 B1 | . | . | . | etc. | |============================================================================== | Keyword: [Model Data] | Required: Yes | Description: Indicates the beginning of the formatted package model data, | which can include the [Resistance Matrix], [Inductance Matrix], | [Capacitance Matrix], [Bandwidth], and [Row] keywords. |------------------------------------------------------------------------------ [Model Data] | |============================================================================== | Keyword: [End Model Data] | Required: Yes | Description: Indicates the end of the formatted model data. | Other Notes: In between the [Model Data] and [End Model Data] keywords is | the package model data itself. The data is a set of 3 | matrices: the resistance (R), inductance (L), and capacitance | (C) matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords below to mark the | beginning of each new matrix. |------------------------------------------------------------------------------ [End Model Data] | |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The sub-parameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the sub-parameters. | After each of these sub-parameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board | (General Syntax Rule #10). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | | For even a modest-sized package, this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | The first row only needs to specify the entries [1,1] through [1,1+B] since | any other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2, 2+B], and so on. In general, for row M | the entries [M,M] through [M,M+B] are given. | | Unlike the Full_matrix, each successive row will typically have the same | number of entries, except for the last few rows. When M + B finally exceeds | the size of the matrix N, then the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | Also, note that it is again necessarily the case that the N'th | row of an N x N matrix has just a single entry (the diagonal entry.) | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.0 [File Name] example.pkg [File Rev] 0.1 [Date] June, 9 1994 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" | | Nominal, min, and max temperature are specified by the manufacturer | of the part. The default range is 50C nom, 0C min, and 100C max | temperatures. | | X% should be statistically determined by the silicon vendor based | on numerous fab lots, test chips, process controls, etc.. The value | of X need not be published in the IBIS file, and may decrease over | time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | As described in the [Pulldown Reference] keyword section, the V/I curve of | the [Pullup] and the [POWER Clamp] structures are 'Vcc relative', using | the equation: Vtable = Vcc - Voutput. | | For example, a device with a 5V power supply voltage should be | characterized between (0 - 5) = -5V and (5 + 5) = 10V; and a | device with a 3.3V power supply should be characterized between | (0 - 3.3) = -3.3V and (3.3 + 3.3) = 6.6V for the pull-down curve. | | When tabulating output data for ECL type devices, the voltage points | must span the range of Vcc to Vcc - 2.2V. This range applies to both the | pull-up and pull-down tables. Note that this range applies ONLY when | characterizing an ECL output. | | These voltage ranges must be spanned by the IBIS data. Data derived | from lab measurements may not be able to span these ranges as such and | so may need to be extrapolated to cover the full range. This data must | not be left for the simulator to provide. | | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be devices that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the manufacturer's | suggested (non-reactive) load and add the load sub parameter to the [Ramp] | specification. | | The ramp rate does not include package and parameters; it is the intrinsic | output stage rise and fall time only. | | The ramp rates (listed in AC characteristics below) should be derived | as follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged device, perform the measurements as outlined below then | use whatever techniques are appropriate to derive the actual, unloaded | rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 Ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | d. Post the value as a ratio "dV/dt". The simulation tool vendor | extrapolates this value to span the required voltage swing range in | the final model. | | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" | | where nominal, min, and max temp are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min, and 100C max | temperatures. | | Note that the derate factor, "Y%", may be different than that used | for the V/I curve data. This factor is similar to the X% factor | described above. As in the case of V/I curves, temperatures are | junction temperatures. | | f. During the IV measurements, the driving waveform should have a | rise/fall time fast enough to avoid thermal feedback. The specific | choice of sweep time is left to the modeling engineer. | | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. | |============================================================================== From lfs@Synopsys.COM Mon Nov 28 11:48:04 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04549; Mon, 28 Nov 94 11:48:04 PST Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA29773 (5.65c/IDA-1.4.4); Mon, 28 Nov 1994 11:34:49 -0800 Received: from clotho.synopsys.com (clotho.synopsys.com [146.225.64.24]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id LAA27009; Mon, 28 Nov 1994 11:34:47 -0800 Received: from tahiti-pc.synopsys.com (tahiti-pc.synopsys.com [146.225.82.18]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id LAA11811; Mon, 28 Nov 1994 11:34:45 -0800 Date: Mon, 28 Nov 1994 11:34:45 -0800 Message-Id: <199411281934.LAA11811@clotho.synopsys.com> X-Sender: lfs@po1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: huangchi@idtinc.com, westbrook@mms.com, blakkan@mms.com, marnow@mms.com, ting@atb.teradyne.com, concha@el.wpafb.af.mil, craig@idtinc.com, harryw@nchip.com, rjg570@email.sps.mot.com, dietech@vhdl.com, ede@Synopsys.COM, kevinh@Synopsys.COM, jayh@Synopsys.COM, stank@compass-da.com, randy.harr@vhdl.org, 544-6089@mcimail.com, omf@cfi.org, vital@vhdl.org, ibis@vhdl.org, billd@reprise.com, steve_sherwood@mentorg.com, ross_nelson@mentorg.com, frank_binnendyk@mentorg.com, dan_milliron@mentorg.com, archie_lachner@mentorg.com, greg_seltzer@mentorg.com, sherman@netcad.enet.dec.com, biro@ecadsr.enet.dec.com, bandali@lsil.com, ritag@doc.com, wdb@vhdl.com, cpk@cadence.com, filano@vhdl.lmc.com, graham@cfi.org, Will_Hobbs@ccm2.jf.intel.com, subbu@india.ti.com, mano@india.ti.com, vijay@india.ti.com, geoff@cadence.com, gilman@wash.inmet.com, gurup@ichips.intel.com, hnosrat@scdt.intel.com, marc@ichips.intel.com, pkukkal@ichips.intel.com, sankar@ichips.intel.com, wickart@ichips.intel.com, xwang@ichips.intel.com, vmartin@dtc.hp.com, eeteam@pdesds2.scra.org, julianm@lmc.com, christop@vnet.ibm.com, dave@icx.com, peter@icx.com, wasco@icx.com, bob@icx.com, mick@hpfcla.fc.hp.com, marc.laurent@matramhs.fr, apte@omnivw.com, kahn@cs.man.ac.uk, mick@neptune.fc.hp.com, lfs@vhdl.org From: lfs@Synopsys.COM (Larry Saunders) Subject: comments on the diet 0.9 format ref manual X-Mailer: I received the following comments on the DIET Format from Peter Ting of Teradyne. In the interest of stimulating some discussion I am distributing them to the dietech reflector. Please take a few minutes to review them and send your comments back to me at dietech@vhdl.org. Also, don't hesitate to forward this to anyone you think might be interested. I can use all the feedback I can get. Thanks due to Peter for taking the time to put together the comments. Peter's comments are at least partially the result of his writing a DIET model of a 74act646 component. If you would like me to email you a copy of his model, please contact me. I will seek Peter's permission to send you a copy. >Date: Mon, 28 Nov 94 12:19:51 EST >From: ting.peter@atb.teradyne.com (Peter Ting) >Message-Id: <9411281719.AA24852@bamboo.ATB.Teradyne.COM> >Received: by flame.beekeeper (4.1/SMI-4.1) > id AA11747; Mon, 28 Nov 94 12:20:42 EST >To: lfs@synopsys.com >Subject: comments on the diet 0.9 format ref manual >Content-Length: 2199 >X-UIDL: 786046744.019 > >Hi Larry > >Have the following comments regarding the DIET 0.9 Format Ref Manual > >1-on pg 7, Output Hold Time is actualy minimal delay time. ie the > outputs will NOT change befor the hold time. > >2-There should be a notes section in the ACTUAL_COMPONENT section > for multi vender diet stuff. > >3-We should allow nc -no connect, and vcc,gnd etc pins in the > PACKAGE setting > >4-on pg 42, Why is the hold_time_spec order different from the > setup_time_spec, ie data ->clock. > >5-on pg 42, should include CHANGE, ie both rising/falling > >6-on pg 42, should include ANY, ie both rising/falling > >7-on pg 51, v_m0 and v_m1 should be v_mo and v_mi > ie Voltage_measurement_output and voltage_measurement_input > The order should also be reversed to input first, then output. > >8-on pg 51, the Capacitive values must be defined in units of FARADS??? > Can we change this default? Seems to be a easy mistake to make. > >9-We are missing some common test conditions, ie Tr (rise time) and > Tf (fall time). There is a second order (analog) effect between rise time > and propgation delay time. This is important! > >10-We are missing Vin for Logic low and Vin for logic high for test conditions. > >11-An additional use of the data_stream construct could be the timing diagrams. > These could provide a pictioral information on how the timing data should > be interperted. > >12-General comment. There seems to be redudency in the diet format with > respect to operating_condition and test_condition. ie both specify the > ambient tempeture range, and voltage range. Infact, the operating > condition setting seems to be a subset of the test_condition setting. > This duplication of data might be OK since the data book duplicates > the data also. > > >PS. There is a product called TimingDesigner from Chronology that seems to > address some of the timing issues. In particualar, there is an > interactive databook from intel. Chronology's email address is > chronco!sales@uunet.uu.net. Phone 1-800-800-6494. Am getting a > free evaluation kit to check it out. If we could get them to output > data in DIET format?? > > >P.Ting > > Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-965-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From lfs@Synopsys.COM Mon Nov 28 12:32:29 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04946; Mon, 28 Nov 94 12:32:29 PST Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA01199 (5.65c/IDA-1.4.4); Mon, 28 Nov 1994 12:19:59 -0800 Received: from clotho.synopsys.com (clotho.synopsys.com [146.225.64.24]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id MAA27216; Mon, 28 Nov 1994 12:19:57 -0800 Received: from tahiti-pc.synopsys.com (tahiti-pc.synopsys.com [146.225.82.18]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id MAA14554; Mon, 28 Nov 1994 12:19:55 -0800 Date: Mon, 28 Nov 1994 12:19:55 -0800 Message-Id: <199411282019.MAA14554@clotho.synopsys.com> X-Sender: lfs@po1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rstrong@lmc.com From: lfs@Synopsys.COM (Larry Saunders) Subject: Re: parser for DIET 0.9 Cc: billd@reprise.com, randy.harr@vhdl.org, billl@Synopsys.COM, stan@nchip.com, die-info@vhdl.org, plippe@Synopsys.COM, huangchi@idtinc.com, westbrook@mms.com, blakkan@mms.com, marnow@mms.com, ting@atb.teradyne.com, concha@el.wpafb.af.mil, craig@idtinc.com, harryw@nchip.com, rjg570@email.sps.mot.com, dietech@vhdl.com, ede@Synopsys.COM, kevinh@Synopsys.COM, jayh@Synopsys.COM, stank@compass-da.com, randy.harr@vhdl.org, 544-6089@mcimail.com, omf@cfi.org, vital@vhdl.org, ibis@vhdl.org, billd@reprise.com, steve_sherwood@mentorg.com, ross_nelson@mentorg.com, frank_binnendyk@mentorg.com, dan_milliron@mentorg.com, archie_lachner@mentorg.com, greg_seltzer@mentorg.com, sherman@netcad.enet.dec.com, biro@ecadsr.enet.dec.com, bandali@lsil.com, ritag@doc.com, wdb@vhdl.com, cpk@cadence.com, filano@vhdl.lmc.com, graham@cfi.org, Will_Hobbs@ccm2.jf.intel.com, subbu@india.ti.com, mano@india.ti.com, vijay@india.ti.com, geoff@cadence.com, gilman@wash.inmet.com, gurup@ichips.intel.com, hnosrat@scdt.intel.com, marc@ichips.intel.com, pkukkal@ichips.intel.com, sankar@ichips.intel.com, wickart@ichips.intel.com, xwang@ichips.intel.com, vmartin@dtc.hp.com, eeteam@pdesds2.scra.org, julianm@lmc.com, christop@vnet.ibm.com, dave@icx.com, peter@icx.com, wasco@icx.com, bob@icx.com, mick@hpfcla.fc.hp.com, marc.laurent@matramhs.fr, apte@omnivw.com, kahn@cs.man.ac.uk, mick@neptune.fc.hp.com X-Mailer: At 10:48 AM 11/28/94 PST, rstrong@lmc.com wrote: >Will the parser_v2 in /pub/die support DIET 0.9? >Please elaborate. > >Thanks! > >Rich Strong (rstrong@lmc.com) I Wish!! The parser you refer to is only for DIE Format data. It does not work with DIET Format data. As you may already know the DIE Format syntax provides a medium for exchanging IC die physical and electrical characteristics. Most all of the information is manufacturing oriented. This information is a useful selling aid to companies that manufacture and sell IC die. And obviously the information is also useful to companies that design and manufacture products that contain IC die. For instance: MCMs! (Sorry, I had to include that short word from our sponser!) The DIET Format syntax, on the other hand, is a medium for exchanging timing information about IC components. While the inital focus has been on supporting IC die components, timing for most any IC is describable within the format. The DIET Format timing information is again intended to be created by IC vendors and used by designers that are incorporating the IC into their products. The timing information is extracted from the format and incorporated into the design database for use during the timing analysis process - either static timing analysis or simulation based timing analysis. Although the syntax of the two formats is superficially similar, they are different languages. Both were designed as part of the ARPA ASEM contract that Synopsys, LMG has with nCHIP. Unfortunately there is no work item in the contract, that I'm aware of, to build a parser for the DIET Format. Either the contract will have to be modified to add such a work item or someone else will have to take on the job of building the DIET Parser - either as a public service or as a product for sale. Hope this is the elaboration you were looking for. If you have any other questions, please let me know. Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-965-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From lfs@Synopsys.COM Tue Nov 29 16:49:04 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29692; Tue, 29 Nov 94 16:49:04 PST Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA07852 (5.65c/IDA-1.4.4); Tue, 29 Nov 1994 16:35:41 -0800 Received: from clotho.synopsys.com (clotho.synopsys.com [146.225.64.24]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id QAA02868; Tue, 29 Nov 1994 16:35:39 -0800 Received: from tahiti-pc.synopsys.com (tahiti-pc.synopsys.com [146.225.82.18]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id QAA14238; Tue, 29 Nov 1994 16:35:37 -0800 Date: Tue, 29 Nov 1994 16:35:37 -0800 Message-Id: <199411300035.QAA14238@clotho.synopsys.com> X-Sender: lfs@po1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rharr@mojave.stanford.edu (Randolph E. "Randy" Harr), Werner Ron From: lfs@Synopsys.COM (Larry Saunders) Subject: Re: Spring VIUF EIA567A tutorial Cc: "Rusher Patti (EIA)" <0005446089@mcimail.com>, chein@atl.ge.com, falco@rocket.sanders.lockheed.com, huangchi@idtinc.com, westbrook@mms.com, blakkan@mms.com, marnow@mms.com, ting@atb.teradyne.com, concha@el.wpafb.af.mil, craig@idtinc.com, harryw@nchip.com, rjg570@email.sps.mot.com, dietech@vhdl.org, ede@Synopsys.COM, kevinh@Synopsys.COM, jayh@Synopsys.COM, stank@compass-da.com, randy.harr@vhdl.org, 544-6089@mcimail.com, omf@cfi.org, vital@vhdl.org, ibis@vhdl.org, billd@reprise.com, steve_sherwood@mentorg.com, ross_nelson@mentorg.com, frank_binnendyk@mentorg.com, dan_milliron@mentorg.com, archie_lachner@mentorg.com, greg_seltzer@mentorg.com, sherman@netcad.enet.dec.com, biro@ecadsr.enet.dec.com, bandali@lsil.com, ritag@doc.com, wdb@vhdl.com, cpk@cadence.com, filano@vhdl.lmc.com, graham@cfi.org, Will_Hobbs@ccm2.jf.intel.com, subbu@india.ti.com, mano@india.ti.com, vijay@india.ti.com, geoff@cadence.com, gilman@wash.inmet.com, gurup@ichips.intel.com, hnosrat@scdt.intel.com, marc@ichips.intel.com, pkukkal@ichips.intel.com, sankar@ichips.intel.com, wickart@ichips.intel.com, xwang@ichips.intel.com, vmartin@dtc.hp.com, eeteam@pdesds2.scra.org, julianm@lmc.com, christop@vnet.ibm.com, dave@icx.com, peter@icx.com, wasco@icx.com, bob@icx.com, mick@hpfcla.fc.hp.com, marc.laurent@matramhs.fr, apte@omnivw.com, kahn@cs.man.ac.uk, mick@neptune.fc.hp.com, rstrong@lmc.com, Lauro_Rizzatti@pdxml1.mentorg.com X-Mailer: >On a different note, this may be the time to start considering the marriage >of 567A and the DIET work. The intent from the beginning (and a plan of Ed >Evans) was to generate 567A timing shells from DIET files. See the >document on-line in the directory >gopher://gopher.vhdl.org:70/pub/die/diet0-9/. Also, the next workshop is >on the 15-16 Dec in the Bay Area. Two thoughts: The current DIET Format spec says nothing about the kind, type, number or required coverage of the timing specifications that should be included within a DIET Format datastream. It's totally left up to the creator to decide what to include. Since the EIA 567A spec has a few things to say about simulation model content, we should consider somehow linking the two specs so that Ed (or anyone else) could write a timing shell generator program secure in the knowledge that all the timing information necessary to create a valid and complete, EIA 567A compliant simulation model will be right there in the DIET datastream, exactly where it should be. No need for last minute chasing around looking for timing numbers that somebody forgot to include. The DIET Format spec includes a very well researched, widely accepted definition of how the various timing specifications (setup, hold, etc.) work. Perhaps the EIA should develop some VHDL and/or Verilog models of the DIET timing specifications that mirror the standalone nature of the DIET definitions and somehow include them in the 567A Standard. As I view it the models would have to be either VHDL concurrent procedure calls or Verilog tasks to work properly. I know there are 57 different ways to write these programs but I am envisioning an implementation where the timing shell generator simply needs to create a VHDL/Verilog program call with parameters matching the DIET timing_specification settings. Larry Saunders lfs@synopsys.com or lfs@mcimail.com or lfs@seva.com 415-694-1837 408-263-0790 510-249-9085 415-694-4009 (fax) 408-263-0790 (fax) 510-249-9082 (fax) Synopsys, LMG Bldg B SEVA Technologies 700 East Middlefield Rd 1775 Milmont Dr, #C106 200 Brown Rd, #103 Mountain View, CA 94043 Milpitas, CA 95035 Fremont, CA 94539 From rkelley@hsv21.pcmail.ingr.com Wed Nov 30 06:19:29 1994 Return-Path: Received: from pcout.pcmail.ingr.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10083; Wed, 30 Nov 94 06:19:29 PST Received: from hubsmp3.pcmail.ingr.com by pcout.pcmail.ingr.com (5.65c/1.921207) id AA01753; Wed, 30 Nov 1994 08:15:15 -0600 Received: by hubsmp3.pcmail.ingr.com with Microsoft Mail id <2EDC8AED@hubsmp3.pcmail.ingr.com>; Wed, 30 Nov 94 08:23:41 CST From: "Kelley, Rob" To: IBIS , SI mailing list Subject: WinEDA Call For Papers Date: Wed, 30 Nov 94 08:14:00 CST Message-Id: <2EDC8AED@hubsmp3.pcmail.ingr.com> Encoding: 50 TEXT X-Mailer: Microsoft Mail V3.0 CALL FOR PAPERS WinEDA Conference & Exhibition The EDA integration and interoperability conference. Sponsored by EE Times and Microsoft Corp. April 26, 27, 1995 Santa Clara Convention Center, Santa Clara, Calif. Held in conjunction with the fifth annual PLDCon: the programmable logic design conference & exhibit. This will be the first WinEDA, a conference for EDA users, CAD managers and EDA developers, with a focus on Windows and alternative operating systems. Papers are solicited, to be given on the topics of: Behavioral design ASIC design PCB, MCM, SMT design High-speed digital design (signal integrity) Analog and mixed signal design The paper is to describe how Windows-based EDA is integrated into the design flow or the local design environment and how it is used to perform the particular design tasks that are the subjects of the session rather than describe a particular design problem. The Conference is looking for innovations in integrating, configuring or tailoring your design environment using Windows-based programs. Work based on alternative integration technologies and operating systems and successes in integrating multi-platform environments are of a great deal of interest. For more information about the conference, for more details about the topics of your interest or to send an abstract, please contact: Stan Baker, WinEDA program developement director stanbaker@aol.com ph. 408-356-5119 fx. 408-356-9018 thanks for listening. WinEDA is a trademark of EE Times.