From huq@rockie.nsc.com Wed Jul 6 09:25:09 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08028; Wed, 6 Jul 94 09:25:09 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA18943 for ibis@vhdl.org; Wed, 6 Jul 94 09:22:10 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA15336 for ibis@vhdl.org; Wed, 6 Jul 94 09:22:09 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA17948; Wed, 6 Jul 94 09:23:15 PDT Date: Wed, 6 Jul 94 09:23:14 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9407061623.AA17948@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS parameters.. Cc: huq@rockie.nsc.com, cjfgsc@tevm2.nsc.com Hi, Some questions about the IBIS parameters: When we specify R_pkg, Do we really mean the Resistance of the pin or the Impedence of the pin. This makes a lot of difference in calculation of R_pkg. Impedence is an easy calculation(based on L & C) but something like Resistance needs Bond wire length, Area of wire, resistivity of the wire etc to get R_pkg. Any idea how someone gets these R_pkg numbers. Don't say from the packaging group !! Also, the C_comp. How does one measure this ? I know of measuring this using TDR method and comparing with known capacitance curves but that is not too straight forward. Any ideas !! Regards, Syed Huq National Semiconductor Corp. From Derrick_Duehren@ccm2.jf.intel.com Thu Jul 7 17:05:22 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22413; Thu, 7 Jul 94 17:05:22 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qM3Mg-000MObC; Thu, 7 Jul 94 17:00 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qM3Nq-000twoC; Thu, 7 Jul 94 17:01 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 7 Jul 94 17:01:38 PST Date: Thu, 7 Jul 94 17:01:38 PST From: Derrick Duehren Message-Id: <940707170138_6@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS meeting bridge numbers Text item: Text_1 In case you missed it in the last meeting minutes, the bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 7/8/94 (916) 356-9999 361301 (GP discussion) 7/15/94 (415) 904-8944 792456 (General Meeting) All meetings begin at 8:00 am PDT. - Derrick From Will_Hobbs@ccm2.jf.intel.com Fri Jul 8 12:59:36 1994 Return-Path: Received: from aurora.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01562; Fri, 8 Jul 94 12:59:36 PDT Received: from ormail.intel.com by aurora.intel.com (5.65/10.0i); Fri, 8 Jul 94 12:56:35 -0700 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qMHYl-000MTFC; Fri, 8 Jul 94 08:09 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qMHZv-000twdC; Fri, 8 Jul 94 08:11 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 8 Jul 94 08:11:02 PST Date: Fri, 8 Jul 94 08:11:02 PST From: Will Hobbs Message-Id: <940708081102_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: IBIS_CHK 2.0 ---------------------------- Forwarded with Changes --------------------------- From: 73053.721@compuserve.com at SMTPGATE Date: 7/6/94 11:29PM To: Will Hobbs at JFCCM2 Subject: IBIS_CHK 2.0 ------------------------------------------------------------------------------- Everyone, I was OOP when Paul sent me this. Apparently we missed connections, and he didn't realize he was to post this to ibis reflector. In hopes that this goes out quickly, here it is. Will Hi Will, I tried to copy the following information to the vhdl.org machine, but didn't have permissions to write in any of the appropriate directories. It seemed that someone might want this information before Friday, so I thought I'd atleast mail it to you so that you might direct it to the necessary people. I left you a voice mail message today but didn't hear back. I'm wondering what's happening this Friday, as I had the impression that there would be some phone conference to discuss IBIS_CHK 2.0. I'll expect to hear from you if I'm to have any involvement in that meeting. The following is my list of items that I saw required for modifing the 1.1 IBIS_CHK program for 2.0. Paul Munsey ------------------------------------------------------------------------------ ---------------------------- Golden Parser Additions/Modifications for 2.0 ============================================= by Paul Munsey & Ron Neville The following is a list of additions and modifications that need to take place to the 1.1.a IBIS_CHK program in order to bring it upto the 2.0 version. Note: 'Optional' is used to indicate that the keyword or sub-param is not required. *) Parse 1.0, and 1.1 files without changing ver 1.1.a code. *) Filenames are no longer case sensitive. (This needs to be clarified) *) Underscores and spaces are equivalent in keywords. *) Add (T)era, (G)iga, and (f)emto to the list of valid scaling factors. *) Add '+' and '-' to the list of disallowed comment characters. *) Add 'Copyright' keyword (Optional). *) Add 'Package Model' keyword (Optional). *) Add 'Pin Mapping' keyword (Optional). (The contents of the sub-param columns needs to be clarified) *) Add 'Diff Pin' keyword (Optional). The 5 sub-params can each contain 'NA'. The 'tdelay-min' and 'tdelay_max' sub-params are optional, but must be specified if their columns will contain any data. *) Add 'Vmeas', 'Cref', 'Rref', and 'Vref' sub-params to the Model keyword (Optional). *) Add the following Model_type's to the Model keyword: - I/O_open_drain - Open_sink - I/O_open_sink - Open_source - I/O_open_source - Input_ECL - Output_ECL - I/O_ECL - Terminitor *) Require 'Vinl' and 'Vinh' sub-params for Model_type 'Input', 'I/O', 'I/O_open_drain', 'I/O_open_sink', 'I/O_open_source', 'Input_ECL', and 'I/O_ECL'. *) Check the V/I table for 'I' sign errors. *) Add 'Temperature Range' keyword (Optional). *) 'Voltage Range' keyword is only required if no reference keywords are present. *) Add 'Pullup Reference', 'Pulldown Reference', 'POWER Clamp Reference', and 'GND Clamp Reference' keywords. These are required only if the 'Voltage Range' keyword is not present. *) Check and warn for non-monotonic data in the V/I curves. *) Add 'Rgnd', 'Rpower', 'Rac', and 'Cac' keywords (Optional). *) Modify 'Ramp' keyword to not be required if the model_type is 'Terminator'. *) Add 'R_load' sub-param to 'Ramp' keyword (Optional). *) Add 'Rising Waveform' and 'Falling Waveform' keywords (Optional). *) Add Package Model keyword's, which are: - Define Package Model - Manufacturer - OEM - Description - Number of Pins - Pin Numbers - Model Data - Resistance Matrix - Inductance Matrix - Capacitance Matrix - Bandwidth - Row - End Model Data - End Package Model *) Allow Package Model definitions to exist in a '.pkg' file within the same directory as the '.ibs' file. *) Add 'beyond 1.1 keyword display'. (Didn't undestand what this meant. It was mentioned in the minutes of the last meeting) From britta@qdt.com Fri Jul 8 13:49:40 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01831; Fri, 8 Jul 94 13:49:40 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP (relay) id QQwxsd11021; Fri, 8 Jul 1994 16:46:38 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 8 Jul 1994 16:46:47 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01000; Fri, 8 Jul 94 13:35:30 PDT Received: from p38.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA11677; Fri, 8 Jul 94 13:35:29 PDT Date: Fri, 8 Jul 94 13:35:29 PDT From: britta@qdt.com (Britta Sullivan) Message-Id: <9407082035.AA11677@sal.qdt.com> To: ibis@vhdl.org Subject: Re: [uunet!acuson.com!brien: ] TO: Brien Anderson RE: Quad Design Pricing for Zeelan Models Brien, Jon Powell asked that I get in touch with you regarding pricing on our Zeelan Models. Zeelan Mastermodel Digital Logic Library $6,000 (Single) 9,000 (Floating) If I can be of further assistance, please let me know. Thank you. Britta Sullivan Quad Design From speters@ichips.intel.com Fri Jul 8 17:26:48 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03622; Fri, 8 Jul 94 17:26:48 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 8 Jul 94 17:23:46 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 8 Jul 94 17:22:28 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 8 Jul 94 17:23:25 PDT Message-Id: <9407090023.AA26006@xtg801.intel.com> To: huq@rockie.nsc.com (Syed Huq) Cc: ibis@vhdl.org Subject: IBIS parameters.... Date: Fri, 08 Jul 1994 17:23:24 -0700 From: Stephen Peters Hello Syed: My answers are below, prefixed with a >>.... Hi, Some questions about the IBIS parameters: When we specify R_pkg, Do we really mean the Resistance of the pin or the Impedence of the pin. This makes a lot of difference in calculation of R_pkg. Impedence is an easy calculation(based on L & C) but something like Resistance needs Bond wire length, Area of wire, resistivity of the wire etc to get R_pkg. >> I have always taken R_pkg as the DC resistance of either the >> bond wire/pin or the trace resistance of a trace in a PGA package. Any idea how someone gets these R_pkg numbers. Don't say from the packaging group !! >> OK, I won't say it :-). If you have a mechanical sample perhaps >> you could use a low ohm meter and make a direct measurment. Also, the C_comp. How does one measure this ? I know of measuring this using TDR method and comparing with known capacitance curves but that is not too straight forward. Any ideas !! >> If you have a tristateable device you can hook the output thru a >> resistor to a very fast (pS) rise time pulse generator. Send a >> pulse thru the resistor and into the output then measure the RC >> time constant. (This is what I do in a simulation environment.) >> I hope these sugestions help. Best Regards, Stephen Peters Intel Corp. Regards, Syed Huq National Semiconductor Corp. From bward@dadhb1.ti.com Mon Jul 11 11:42:51 1994 Return-Path: Received: from lobby2b.ti.com ([192.94.94.33]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00662; Mon, 11 Jul 94 11:42:51 PDT Received: from tilde.csc.ti.com by lobby2b.ti.com with SMTP (8.6.8.1/LAI-3.2) id NAA18603; Mon, 11 Jul 1994 13:37:01 -0500 Received: from isis.dadhb1.ti.com ([128.247.82.12]) by tilde.csc.ti.com id AA13622; Mon, 11 Jul 1994 13:39:09 -0500 Received: from emu.dadhb1.ti.com by isis.dadhb1.ti.com with SMTP (1.37.109.4/IDA1.4.4.1-Domain/OS) id AA26254; Mon, 11 Jul 94 13:38:44 -0500 From: Bob Ward Received: by emu.dadhb1.ti.com id ; Mon, 11 Jul 94 13:38:43 -0500 Date: Mon, 11 Jul 94 13:38:43 -0500 Message-Id: <9407111838.AA27250@emu.dadhb1.ti.com> To: ibis@vhdl.org Subject: data table format convention? Fellow birds of ibis - As I sit staring at the set of ibis models I have I notice that data tables are in the form independent variable typ min max. But I also note that there is always a comment bearing headings above the data columns. Is the sequence typ min max mandated somewhere and I missed it, is it merely conventional, or is the comment bearing headings significant in the parse? Please reply to my neosoft address, as our internal network is EXTREMELY unstable just now, and I may never see replies to TI. Thanks, Bob bward@neosoft.com From Derrick_Duehren@ccm2.jf.intel.com Mon Jul 11 14:25:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01815; Mon, 11 Jul 94 14:25:08 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qNSnj-000MPGC; Mon, 11 Jul 94 14:22 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qNSmq-000twcC; Mon, 11 Jul 94 14:21 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 11 Jul 94 14:21:16 PST Date: Mon, 11 Jul 94 14:21:16 PST From: Derrick Duehren Message-Id: <940711142116_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS reflector e-mail list Text item: Text_1 For your information: IBIS reflector alias list as of 7/11/94 ======================================= 71436.1314@compuserve.com 74012.21@CompuServe.COM andy@symmetry.com andy_critcher@mentorg.com arpad_muranyi@ccm.hf.intel.com arthur.wong@microsim.com belkin@gmesc.com benny.leveille@amuc.mtroyal.ab.ca bernard@icx.com bert@ibmoto.com billg@metasw.com billp@ATC.Olivetti.Com blooms@icx.com bob@icx.com bracken@performance.com brien@acuson.com bw@cypress.com bward@neosoft.com canright@convex.com canyimi@pcocd2.intel.com cer@cadence.com coleman@SSD.intel.com cormack@sequent.com cpk@cadence.com david.moxley@columbiasc.ncr.com david_reha@quickmail.apple.com davide@cadence.com dennis@ece.cmu.edu dermott@contec.com Derrick_Duehren@ccm.jf.intel.com dmannion@chipcom.com don_a_telian@ccm.hf.intel.com duane@lake-george.apple.com edmond@asicsv.mela.com farhada@metasw.com fkai@simulate.us.dell.com gdoyle@intgrty.mn.org giolitti@iconet.olivetti.com greg_seltzer@mentorg.com huq@lightning.nsc.com idodd@ingr.com jay@ansoft.com jayd@ralvm29.vnet.ibm.com jcahill@vnet.ibm.com john.hamre@network.com johnb@redact.co.uk jonb@sphinx.sps.mot.com jonp@qdt.com jrbren@vnet.ibm.com jyhe@nmoy.nmp.nokia.com katz@decsim.enet.dec.com kaveh@radius.com keith@hk.super.net kirchman@acuson.com klaus@SSD.intel.com kurobe@asic.mtv.nec.com lebrun@sctf.thomsom.fr less@metasw.com lum@unicad.com maah@contec.com mac@libtech.com maramis@maxwell.ansoft.com marty@symmetry.com mat@lsi.tmg.nec.co.jp mbs@ncsu.edu mei@metasw.com meiling@metasw.com mu@quantic.mb.ca neven@icx.com paige@qlogic.com paulf@ncsu.edu perlman@acuson.com pigna@king.ico.olivetti.com raghavan@performance.com randyh ravender_goyal@mentorg.com rdk@VNET.IBM.COM rkelley@tarheel.b23b.ingr.com robinr@ichips.intel.com rodney.nelson@network.com sandeep@cadence.com sergio@flash.ATC.Olivetti.Com slipa@eos.ncsu.edu speters@ichips.intel.com sr@anacad.de stramond@teleport.com tclark@pcocd2.intel.com Tim_A_Schreyer_at_jfccm7@ccm.hf.intel.com tom.lane@network.com ttrieu@pcocd2.intel.com ventham@quantic.mb.ca wei@metasw.com weston.beal@sun.com Will_Hobbs@ccm2.jf.intel.com wr@cadlab.cadlab.de xuan@sr.hp.com zeelan@netcom.com From Derrick_Duehren@ccm2.jf.intel.com Mon Jul 11 14:25:12 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01820; Mon, 11 Jul 94 14:25:12 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qNSnk-000MPJC; Mon, 11 Jul 94 14:22 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qNSmr-000twcC; Mon, 11 Jul 94 14:21 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 11 Jul 94 14:21:17 PST Date: Mon, 11 Jul 94 14:21:17 PST From: Derrick Duehren Message-Id: <940711142117_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 7/15 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 7/15/94 Bridge: Res: (415) 904-8944 792456 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in Intros of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/announcements Hobbs Opens for new issues All Press updates Hobbs/All Progress toward enlisting new IC vendors All New models available All Golden Parser, 2.1 plans Hobbs 8:40 IBIS Librarian Powell IBIS Cookbook Peters Standards body affiliation Hobbs Spice-to-IBIS converter Ross Pending BIRDs Hobbs 9:55 Wrap-up, next meeting plans Hobbs From Derrick_Duehren@ccm2.jf.intel.com Mon Jul 11 16:34:48 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02482; Mon, 11 Jul 94 16:34:48 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qNUpB-000MPFC; Mon, 11 Jul 94 16:31 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qNUoJ-000twcC; Mon, 11 Jul 94 16:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 11 Jul 94 16:30:55 PST Date: Mon, 11 Jul 94 16:30:55 PST From: Derrick Duehren Message-Id: <940711163055_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Cookbook now on tap Text item: Text_1 The IBIS Cookbook, ver 1.0, is now available on vhdl.org in the /pub/ibis/documents directory in a variety of flavors. cookbk.wfw Word for Windows 2.0 (Chocolate) cookbk.rtf Rich Text Format (Strawberry) cookbk.txt ASCII text file (Vanilla) Comments, changes, and additions should be forwarded to Stephen Peters (speters@ichips.intel.com). PS: I also moved the overview documents to this new /documents subdirectory. - Derrick Duehren Intel Corp. From Derrick_Duehren@ccm2.jf.intel.com Tue Jul 12 10:11:20 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11076; Tue, 12 Jul 94 10:11:20 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qNlJc-000MQ7C; Tue, 12 Jul 94 10:08 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qNlIk-000twcC; Tue, 12 Jul 94 10:07 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 12 Jul 94 10:07:25 PST Date: Tue, 12 Jul 94 10:07:25 PST From: Derrick Duehren Message-Id: <940712100725_43@ccm.hf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, IBIS@vhdl.org Subject: VHDL.ORG IBIS map to commonly used files Text item: Text_1 VHDL.ORG IBIS map to commonly used files (as of 7/12/94) ======================================================== I/O Buffer Information Specification (IBIS) Open Forum The IBIS Open Forum meets once every 2-3 weeks (Friday's, 8-10am PDT) via a conference call. See the previous discussions in the email.archive file for the mechanism to link in. All material is open freely to anyone except the source code for the golden parser. To obtain a copy, you must join the Open Forum (fee involved). Send an email to ibis-info@vhdl.org for more information. Directory Contents: pub/ibis/ birds/ Buffer Issue Resolution Document's (BIRD's) documents/ Overview, cookbook, and other IBIS documents email.archive Latest discussions on ibis@vhdl.org reflector email93/ 1993 reflector discussion archive email94/ 1994 reflector discussion archive minute93/ 1993 minutes (Microsoft WORD format) models/ IBIS models available pressrel.{rtf,ps} 1.0 Press Release (Aug 1993) (RTF and Postscript) roster.txt Participation roster of IBIS Open Forum s2ibis/ SPICE to IBIS converter (from N.C.State) summit93/ Nov 1993 IBIS Summit ver1.0/ IBIS specification Version 1.0 directory ver1.1/ IBIS specification Version 1.1 directory ver2.0/ IBIS specification Version 2.0 directory Directory Contents: pub/ibis/ver2.0/ chk-note.txt Parser changer notes for version 2.0 ver2_0.txt IBIS version 2.0 specification ver2_0rn.txt IBIS version 2.0 Release notes Directory Contents: pub/ibis/docs/ cookbk.wfw IBIS cookbook (Microsoft WORD 2.0) cookbk.txt IBIS cookbook (ASCII text file) cookbk.rtf IBIS cookbook (Rich Text Format) overview.wfw Overview document (Microsoft WORD 2.0) overview.ps Overview document (Postscript Print File) overview.rtf Overview document (Rich Text Format) overview.z Overview document (UNIX Z compressed RTF) pub/ibis/models/ This directory is provided by VHDL International as a free service for IBIS users. All the files within this directory are provided as is. The user assumes all responsibility for using these files. Directory Contents: disclaim.txt Disclaimer text intel/ Intel's directory of IBIS models pub/ibis/models/intel/ Intel Corporation IBIS Files on vhdl.org as of 6/17/94 Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes -------------------------------------------------------------------------- 82425ex.ibs chipset PSC 06-17-94 R0.93 V1.1 Aries chipset 82426ex.ibs chipset IB 06-17-94 R0.93 V1.1 Aries chipset 82374eb.ibs chipset ESC 05-13-94 R2.11 V1.1 PCI-EISA Bridge 82374sb.ibs chipset ESC 06-17-94 R0.93 V1.1 PCI-EISA Bridge 82375eb.ibs chipset PCEB 05-13-94 R2.11 V1.1 PCI-EISA Bridge 82375sb.ibs chipset PCEB 06-17-94 R0.93 V1.1 PCI-EISA Bridge 82378ib.ibs chipset SIO 05-13-94 R2.11 V1.1 PCI-ISA Bridge 82378zb.ibs chipset SIOZ 06-17-94 R0.93 V1.1 PCI-ISA Bridge 82433lx.ibs chipset LBX 05-13-94 R2.11 V1.1 Mercury chipset 82434lx.ibs chipset PCMC 05-13-94 R2.11 V1.1 Mercury chipset 82433nx.ibs chipset LBX 06-17-94 R0.94 V1.1 Neptune chipset 82434nx.ibs chipset PCMC 06-17-94 R0.94 V1.1 Neptune chipset 82423tx.ibs chipset DPU 05-13-94 R2.11 V1.1 Saturn chipset 82424zx.ibs chipset CDC 05-13-94 R2.11 V1.1 Saturn chipset dx4pga.ibs cpu DX4 05-04-94 R2.0 V1.1 IntelDX4(TM) uP From jonp@qdt.com Tue Jul 12 18:20:53 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14426; Tue, 12 Jul 94 18:20:53 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP (relay) id QQwyhp20764; Tue, 12 Jul 1994 21:17:45 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 12 Jul 1994 21:17:35 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01416; Tue, 12 Jul 94 17:34:52 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA22266; Tue, 12 Jul 94 17:34:52 PDT Date: Tue, 12 Jul 94 17:34:51 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9407130034.AA22266@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA23372; Tue, 12 Jul 94 17:34:58 PDT To: ibis@vhdl.org Subject: IBIS Librarian Fellow ibisheads, I note that I am on the schedule for this Friday to discuss the issue of "IBIS LIBRARIAN" I thought I might warm up the mental juices with a few thoughts. This is what I think about the IBIS library and the IBIS librarian: 1) Models that do not pass the golden parser should not be in the IBIS sanctioned library (ie. vhdl). We may not be able to guarantee that all IBIS models are good but we can at least make sure the ones that we distribute pass the parser. 2) This means that we cannot allow just anyone to put models on the reflector. Not even just anyone from any given company. Some small subset of responsible persons need to be in charge or releasing "good" models. 3) I have heard it said on the ibis phone meetings that having a rotating librarian position would not be good because we wouldn't know if we could trust the librarian. Why is it we trust the librarian now? It seems that an elected position in the group would be adequate until such a time that we decided to become real and then hired someone to do it. I, for one, would trust any of the people on the committee to be the librarian (or I wouldn't vote for them). 4) The librarian would also be reasponsible for some sort of taging on the IBIS files (changing their revision numbers). It would be good if the IBIS sanctioned models did not change unless their model version numbers changed. (This will save our customers a lot of headache). Take it easy, jon powell From schmahl@slszwat Thu Jul 14 07:49:45 1994 Return-Path: Received: from slsa02t.stgl.netd.alcatel.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02344; Thu, 14 Jul 94 07:49:45 PDT Received: from slssn1t.stgl.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <29341-0@slsa02t.stgl.netd.alcatel.de>; Thu, 14 Jul 1994 16:47:19 +0200 Received: from slszwat.stgl.sel.alcatel.de by slssn1t.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI-7.0.1) id AA12753; Thu, 14 Jul 94 16:47:55 +0200 Received: from slszwbt.ehc6 by slszwat.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI) id AA00969; Thu, 14 Jul 94 16:49:48 +0200 Received: by slszwbt.ehc6 (4.1/SMI-4.1-DNI-7.0.1) id AA00569; Thu, 14 Jul 94 16:49:54 +0200 Date: Thu, 14 Jul 1994 16:47:16 +0200 (MET DST) From: Gerhard Schmahl Subject: Subscription for emails To: ibis@vhdl.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, we are very interested in any progress regarding IBIS. Could you please add me to your mailing list? Thanks in advance Best regards, Gerhard Schmahl ======================================================================= Gerhard Schmahl Phone: (+49) 711 821 - 5526 Alcatel SEL AG Fax: (+49) 711 821 - 3415 Dept. VS/ETCE1 Internet: GSchmahl@stgl.sel.alcatel.de Lorenzstrasse 10 70435 Stuttgart, Germany =========================== End of Email ============================== From Will_Hobbs@ccm2.jf.intel.com Thu Jul 14 08:49:46 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02886; Thu, 14 Jul 94 08:49:46 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qOSzS-000MNaC; Thu, 14 Jul 94 08:46 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qOSye-000twdC; Thu, 14 Jul 94 08:45 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 14 Jul 94 08:45:36 PST Date: Thu, 14 Jul 94 08:45:36 PST From: Will Hobbs Message-Id: <940714084536_6@ccm.jf.intel.com> To: ibis@vhdl.org, graham@cfi.org Cc: Derrick_Duehren@ccm2.jf.intel.com Subject: Re[2]: Re[2]- Re[3]- EIA info f IBIS-ers, Andy Graham, chairman of CFI will be joining us tomorrow to give us an overview of CFI for our standards organization discussion. I've asked him to join us at 9:00 PDT (or earlier if he wants to listen in). Below is a summary of what CFI is. "See" you tomorrow. Will CFI Mission: Provide industry accepted standards and technology that enable interoperability of electronic design automation applications and data for end-users and suppliers worldwide. Accomplishments: - Staged prototype demonstrations involving 20+ companies 90-92 - Released first balloted design representation PI standard 1/93 - Released first Developers toolkit 5/93 - Joined ARPA RASSP program to provide EDA standards 9/93 - Certified first DRPI compliance 6/94 Membership: 40 companies worldwide (12 Japanese/7 European) - all major semiconductor companies - all major EDA vendors - computer and telecommunications companies Process: Majority rule vote by company with appeal provision Resources: 11 dedicated staff with 7K sq/ft facility and equipment Capabilities: - Technical publication - Internet server for doc distribution, conferencing, reflectors Mosaic home pages etc. - Developer Toolkit development and distribution - Certification test development and administration - Multicompany project management - Finance, legal, and government contracts administration Budget: $2.2M in CY '94 Accreditation: Filed under the National Cooperative Research Act along with other consortia such as Sematech and MCC. Current activities: - CFI Submicron interoperability project - ASIC library standardization (timing and functional models) - ARPA RASSP program (involving many EDA vendors) - OMF facilitation Legal status: Delaware membership owned corporation since 2/89 Governance: 11 member Board elected at large from membership ************************************************** From paulf@eos.ncsu.edu Fri Jul 15 12:33:17 1994 Return-Path: Received: from c11059-364dan.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16688; Fri, 15 Jul 94 12:33:17 PDT Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA00583; Fri, 15 Jul 1994 15:30:02 -0400 From: paulf@eos.ncsu.edu Message-Id: <9407151930.AA00583@c11059-364dan.ece.ncsu.edu> To: ibis@vhdl.org Subject: Who is using S2IBIS please? Date: Fri, 15 Jul 94 15:30:02 EDT As most of you know, the Spice to IBIS was produced by your tax dollars through ARPA. We are writing our annual report to ARPA and they require the following: --------------- TECHNOLOGY TRANSITION: A brief description of specific technology transition activities (military/civilian). (1) State specifically how results of this research are being exploited by others, including other researchers. (It is not sufficient just to say which sites have your technology.) (2) How is the impact of this work measured? (3) What key technologies are exported, including to other ARPA, Service, commericial, or university efforts. (4) For each system or prototype available for dissemination, provide system name, purpose, environment requirements, and point of contact phone and email address. ---------------- If you are using or intend to use our Spice to IBIS code, could you please provide me with a one-line description of how you are using it, as well as the POC, phone and email address? If you know of someone not on this list who is using it, that would be appreciated too. This enables ARPA to tell others that they are spending your tax dollars properly and helps us get similar $$ in the future. Other comments (eg. regarding (2)) are also welcome. Thanks Paul Franzon 919 515 7351 From bob@icx.com Fri Jul 15 13:44:36 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17169; Fri, 15 Jul 94 13:44:36 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22964 for ; Fri, 15 Jul 94 16:33:40 -0400 Date: Fri, 15 Jul 94 13:20:45 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA12239; Fri, 15 Jul 94 13:20:45 PDT Message-Id: <9407152020.AA12239@icx.com> To: 73053.721@compuserve.com, ibis@vhdl.org Subject: IBIS_CHK 2.0 COMMENTS Paul Munsey and IBIS committee: Your list looks complete. Here are a few comments on your list of proposed changes: 1. Filenames remain case sensitve and lower case. 2. Regarding [Pin Mapping] columns, the first column entry is required to be a pin number string corresponding to one of the numbers in the [Pin] list. Of the last 4 column all must contain strings or "NC". The last two column entries may be omitted. If the "gnd_clamp_ref" and "power_clamp_ref" subparameters of the [Pin Mapping] keyword are omitted, there cannot be any entries in the last two columns. (This is somewhat analogous to the optional usage of R_pin, L_pin and C_pin subparameters for [Pin].) 3. Regarding [Diff pin], only the last 4 subparameter column entries can use NA. The first two columns must have pin number strings corresponding to the pin numbers in the [Pin] list. Each of the last 4 columns can contain a number or "NA". Any data line may omit both of the last 2 columns for tdelay_min and tdelay_max values. 4. When any of the [Rgnd], [Rpower], [Rac], or [Cac] keywords exist in a [Model], then the Model_type must be "Terminator". Also for the AC terminator spec, both [Rac] and [Cac] must be specified. 5. I believe the "keyword" display was intended to be a tabulation of all of the keywords that a file contains so that the Simulator could be alerted that the file may contain some keywords that are not processed fully by the Simulator. (The keyword may be ignored and some alternative, lower level method of handling the feature may be done). Let me know if you have any questions. Bob Ross Interconnectix, Inc. (503) 684-6641 From Will_Hobbs@ccm2.jf.intel.com Tue Jul 19 08:30:46 1994 Return-Path: Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26739; Tue, 19 Jul 94 08:30:46 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qQH3V-000MNuC; Tue, 19 Jul 94 08:26 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qQH2Z-000tweC; Tue, 19 Jul 94 08:25 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 19 Jul 94 08:25:07 PST Date: Tue, 19 Jul 94 08:25:07 PST From: Will Hobbs Message-Id: <940719082507_4@ccm.jf.intel.com> To: ibis@vhdl.org Subject: EIA proposal Text item: Text_1 IBISers, Here is the letter that Patti Rusher sent to me regarding IBIS affiliation with EIA. Will Hobbs Intel Corp. Mr. William Hobbs XTG Modeling Manager Intel Corporation 5200 NE Elam Young Parkway Hillsboro, OR 97214 Dear Mr. Hobbs: Thank you for the opportunity to discuss the possibility of IBIS Open Forum becoming affiliated with the EIA's Electronic Information Group (EIG) during last Friday's teleconference. As we discussed, I would propose that the IBIS Open Forum become a Committee under the Design Automation Division of the EIG. This will permit the Forum to do the following: 1. Submit its document to become an ANSI accredited standard by using the EIA accredited standards organization procedures. Under these procedures you can put your document through EIA as an Interim Standard that has a finite life of three years after which you can upgrade to an ANSI/EIA standard, or do them both simultaneously. EIA full standards have to be reconfirmed, revised or rescinded every five years. 2. Maintain your current method of operation without having the burden of large overhead expenditures. By being a Committee, you don't have to belong to the Design Automation Division, but could pay a very reasonable committee fee. Divisional membership is desirable, but not mandatory! Members of the Design Automation would not have to pay Committee fees. EIA budgets are run Jan-Dec on an accrual basis. Your committee income and expenses would be rolled into the Design Automation Division, however, it is possible to set up special accounts for projects such as future parser development/contractor expense. EIA only asks that each Group be self liquidating and I believe we can work this issue to be advantageous for you and keep your costs to a minimum. Before putting any amount on this I would like to know what your current operational expenses are. As I indicated during the teleconference, my expenses have already been budgeted this year, but I cannot imagine that IBIS would take up more than 1-2% of my time during 1995. 3. If IBIS Open Forum does decide to become a part EIA you will have access to our legal department, marketing service department, engineering, and we would be your official administrative arm alleviating this burden from the volunteer resources. EIA is a non-profit organization. 4. EIA will have to maintain the copyright of any documents you decide to put forth as a standard for legal reasons. Distribution of information through the EIG will ensure that you can maintain cost controls, however, they will be advertised nationally and internationally through EIA's distributors. 5. Since EIG is involved in other areas such as EDIF, VHDL component modeling as well as CASE exchange format standards, and future work such as the DIE, IBIS is a natural fit. EIG was created to help foster the growth of these exchange standards and help promote them throughout the industry. 6. EIA's membership base is approximately 1100 companies. Our engineering department alone has approximately 275 committees with over 6,000 individuals participating, providing you with lots of exposure. Please feel free to contact me should you have any additional questions. Again, I fuel we can work together to promote IBIS. Sincerely, Patti Rusher Director Electronic Information Group CC: Gene Lussier Randy Hart Ron Werner From huq@rockie.nsc.com Tue Jul 19 15:12:57 1994 Return-Path: Received: from gatekeeper.nsc.com ([139.187.71.2]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29420; Tue, 19 Jul 94 15:12:57 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20135 for ibis@vhdl.org; Tue, 19 Jul 94 15:08:19 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA08440 for ibis@vhdl.org; Tue, 19 Jul 94 15:08:18 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA16883; Tue, 19 Jul 94 15:09:33 PDT Date: Tue, 19 Jul 94 15:09:33 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9407192209.AA16883@rockie.nsc.com> To: ibis@vhdl.org Subject: V/I table in Bench measurements Cc: huq@rockie.nsc.com, cjfgsc@tevm2.nsc.com Hi fellow gurus: Got two questions about the V/I table. 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it be from +ve to -ve number as well ? Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V 2) For most of the V/I table, IBIS shows that the voltage range should go from +10V to -5V. Problem is, there are devices whose I/O structure cannot handle swings that large. In that case, since we should not test a device beyond it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing the I/O all the way to +10 to -5V ??? Regards, Syed huq National Semiconductor From Will_Hobbs@ccm2.jf.intel.com Wed Jul 20 08:08:03 1994 Return-Path: Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10168; Wed, 20 Jul 94 08:08:03 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qQdB3-000MNXC; Wed, 20 Jul 94 08:03 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qQdA6-000twfC; Wed, 20 Jul 94 08:02 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 20 Jul 94 08:02:22 PST Date: Wed, 20 Jul 94 08:02:22 PST From: Will Hobbs Message-Id: <940720080222_7@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Next four IBIS Bridge numbers Text item: Text_1 Greetings, The next meeting numbers are as follows: Date: Time (PDT) Res. # Bridge # 8/5/94 8:00 - 9:00 am 809164 415-904-8944 (short meeting) 8/26/94 8:00 - 10:00 am 809164 415-904-8944 9/16/94 8:00 - 10:00 am 809164 415-904-8944 10/7/94 8:00 - 10:00 am 809164 415-904-8944. (Notice any pattern?) Dial in, ask for the IBIS Open Forum, give the reservation number, and you're in. Regards, Will Hobbs Intel Corp. From cer@Cadence.COM Wed Jul 20 10:20:28 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11753; Wed, 20 Jul 94 10:20:28 PDT Received: (from uucp@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id KAA14376 for ; Wed, 20 Jul 1994 10:17:21 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma014317; Wed Jul 20 10:16:44 1994 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA15804; Wed, 20 Jul 94 09:36:16 -0700 Received: by oahu (5.65+/1.5) id AA01365; Wed, 20 Jul 94 13:16:41 -0400 Date: Wed, 20 Jul 94 13:16:41 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9407201716.AA01365@oahu> To: ibis@vhdl.org Subject: Column Headers Hello, Just a point of clarification please. I'm reading the v2.0 spec. and find the same question I had with the v1.0 spec unanswered. I ASSUME that column headings must appear in the specified order. In other words, [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max is the specified syntax, so [Diff Pin] tdelay_typ inv_pin tdelay_min vdiff tdelay_max or any other rearrangement is illegal. Right? Chris cer@cadence.com From bob@icx.com Wed Jul 20 12:25:36 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12765; Wed, 20 Jul 94 12:25:36 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04628 for ; Wed, 20 Jul 94 15:07:36 -0400 Date: Wed, 20 Jul 94 11:56:15 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA28247; Wed, 20 Jul 94 11:56:15 PDT Message-Id: <9407201856.AA28247@icx.com> To: cer@cadence.com, ibis@vhdl.org Subject: Re: Column Headers Chris The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). Bob Ross Interconnectix, Inc. > Hello, > Just a point of clarification please. I'm reading the v2.0 spec. > and find the same question I had with the v1.0 spec unanswered. > I ASSUME that column headings must appear in the specified order. > In other words, > [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max > is the specified syntax, so > [Diff Pin] tdelay_typ inv_pin tdelay_min vdiff tdelay_max > or any other rearrangement is illegal. Right? > Chris > cer@cadence.com From mbs@eos.ncsu.edu Wed Jul 20 13:55:07 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 AA13214; Wed, 20 Jul 94 13:55:07 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA14954; Wed, 20 Jul 1994 16:51:58 -0400 From: mbs@eos.ncsu.edu Message-Id: <9407202051.AA14954@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: Librarian Proposal Date: Wed, 20 Jul 94 16:51:58 EDT As discussed in the last IBIS Open Forum Call (on July 15) I raised the suggestion that NCSU could act as the IBIS librarian and a proposal was requested. Here it is. IBIS LIBRARIAN PROPOSAL The Electronics Research Laboratory in the Department of Electrical and Computer Engineering at North Carolina State University proposes to maintain the IBIS library and act as the IBIS librarian. 1. An IBIS mosaic home page. A temporary page has been created and can be accessed by selecting North Carolina State University College of Engineering Departments and Programs Electrical and Computer Engineering ECE Department Research Centers Electronics Research Laboratory IBIS The URL is http://www2.ncsu.edu/eos/project/erl_html/erl_ibis.html It is very unlikely that this address will change so feel free to link to it. 2. An IBIS anonymous ftp site. basically everything available through mosaic will be on the ftp site (most of the files will be identical). The address is ftp.eos.ncsu.edu The directory will be pub/ibis 3. The library will contain IBIS models that have been validated by the IBIS librarian. Models are valid if they they can be parsed (without error) by the Golden Parser. 4. The library will contain source code such as the Spice-to-IBIS code and other bits and pieces currently maintained on vhdl.org:/pub/ibis 5. The librarian will be Michael Steer (Associate Professor, Department of Electrical and Computer Engineering, NCSU --- phone +1-919-515-5191, fax +1-919-515-3027, email mbs@ncsu.edu) 6. We will seek US government funds to support activities such as Spice-to-IBIS for IBIS2.0 . (The development of Spice-to-IBIS for IBIS1.1 was supported by ARPA.) 7. The server will be run at no charge. Eventually, if the space utilized grows to 500 MB+ or if the traffic becomes enormous we expect to acquire government funding to provide a dedicated server and disk space. Running an IBIS server and functioning as librarian fits in well with our CAD benchmarking activities. We welcome the opportunity to participate and contribute. Michael Steer mbs@ncsu.edu From whobbs@ichips.intel.com Wed Jul 20 13:57:57 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13220; Wed, 20 Jul 94 13:57:57 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Wed, 20 Jul 94 13:54:49 -0700 Received: from pdxgp1 by ichips.intel.com (5.64+/10.0i); Wed, 20 Jul 94 13:51:56 -0700 Received: by pdxgp1 (5.64+/10.0i); Wed, 20 Jul 94 13:54:36 -0700 Date: Wed, 20 Jul 94 13:54:36 -0700 From: whobbs@ichips.intel.com (Will Hobbs) Message-Id: <9407202054.AA07404@pdxgp1> To: ibis@vhdl.org Subject: Bird 17, 101 points in tables Hello IBIS members: This BIRD extends the number of points from 100 to 101 per last IBIS Forum discussion. Upon further reflection, the proposed number of points for the [Pullup] and [Pulldown] tables is increased to 151 since they are mandated to extend of larger voltage ranges. The primary reason for these extensions is to allow automated IBIS file creation programs to sweep over the entire voltage data range of -5V to 10V at .1V increments, capture the endpoints and the 0V and 5V points. Scott Bloom, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 17 ISSUE TITLE: Number of Points REQUESTOR: Scott Bloom, Interconnectix, Inc. DATE SUBMITTED: 17 July 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The limits on the number of points for the [Pullup] and [Pulldown] keywords is increased from 100 to 151 to allow automated and simulated capture routines to sweep from -5V to +10V at .1V increments. Similarly the number of points for [GND clamp] and [POWER clamp] tables is increased from 100 to 101, again allowing .1V increments for the [GND clamp] table from -5V to 5V. Also the the number of points for [Rising Waveform] and [Falling Waveform] tables is increased from 100 to 101 to allow, for example, time sweeps from 0 to 10ns at .1ns increments. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: For the keywords [Pulldown], [Pullup], [GND Clamp], and [POWER Clamp], under Usage Rules, the last sentence of the second paragraph is changed into two sentences. The second paragraph becomes: | 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 [Pullup] | and [Pulldown] V/I curve must have at least 2, but not more | than 151, voltage points. Each [GND Clamp] and [POWER Clamp] | V/I curve must have at least 2, but not more than 101, voltage | points. For the keywords [Rising Waveform] and [Falling Waveform], the second to last sentence of the first paragraph of Usage Rules is changed: It now becomes: | 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 101 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Automated generation of IBIS file VI and time tables typically can be done with linear voltage and linear time sweeps over the entire required range. A typical range for CMOS and TTL devices with Vcc = 5V is from -5V to 10V at .1V increments. This would require 151 points for the [Pullup] and [Pulldown] tables. Similarly, the [GND Clamp] tables would be tabulated from -5V to 5V at .1V increments, requiring 101 points. The [Rising Waveform] and [Falling Waveform] could be presented with some utilities at constant time increments. In order to capture a typical range such as 0 to 10ns at .1ns increments, 101 points would be needed. Even though there may be unnecessary points, this proposal increases the limits in a proportional manner. It allows typical ranges that align the V/I tables to be presented without requiring any further processing. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION ****************************************************************************** From bob@icx.com Wed Jul 20 14:04:23 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13285; Wed, 20 Jul 94 14:04:23 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22510 for ; Wed, 20 Jul 94 16:53:45 -0400 Date: Wed, 20 Jul 94 13:45:31 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA29031; Wed, 20 Jul 94 13:45:31 PDT Message-Id: <9407202045.AA29031@icx.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: V/I table in Bench measurements Cc: cjfgsc@tevm2.nsc.com Syed: Here are my views on your questions: (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. (2) The table itself must go to at least the specified limits. It is permissible to do the measurements over a reasonable range and then extrapolate to the end points. For example, you man not want to measure below -2V, but you still need to provide at least one extrapolated data point out to -5V if Vcc is 5V. Bob Ross, Interconnectix, Inc. > Hi fellow gurus: > Got two questions about the V/I table. > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > be from +ve to -ve number as well ? > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > 2) For most of the V/I table, IBIS shows that the voltage range should go from > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > swings that large. In that case, since we should not test a device beyond > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > the I/O all the way to +10 to -5V ??? > Regards, > Syed huq > National Semiconductor From Will_Hobbs@ccm2.jf.intel.com Wed Jul 20 14:05:31 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13302; Wed, 20 Jul 94 14:05:31 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qQimM-000MO6C; Wed, 20 Jul 94 14:02 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qQilO-000twcC; Wed, 20 Jul 94 14:01 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 20 Jul 94 14:01:14 PST Date: Wed, 20 Jul 94 14:01:14 PST From: Will Hobbs Message-Id: <940720140114_6@ccm.jf.intel.com> To: bob@icx.com, cer@cadence.com, ibis@vhdl.org Subject: Re[2]: Column Headers Chris, Bob, Sounds like another Bird, #18? Bob, since the bulk of the Bird is contained in the paragraph you just wrote, do you want to post it? Will Chris The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). Bob Ross Interconnectix, Inc. > Hello, > Just a point of clarification please. I'm reading the v2.0 spec. > and find the same question I had with the v1.0 spec unanswered. > I ASSUME that column headings must appear in the specified order. > In other words, > [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max > is the specified syntax, so > [Diff Pin] tdelay_typ inv_pin tdelay_min vdiff tdelay_max > or any other rearrangement is illegal. Right? > Chris > cer@cadence.com From speters@ichips.intel.com Wed Jul 20 15:47:33 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14336; Wed, 20 Jul 94 15:47:33 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Wed, 20 Jul 94 15:44:16 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 20 Jul 94 15:41:20 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 20 Jul 94 15:44:01 PDT Message-Id: <9407202244.AA24049@xtg801.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re[1]: V/I table in Bench measurements Date: Wed, 20 Jul 1994 15:43:59 -0700 From: Stephen Peters Hello Bob, Syed: You know, Syed's question brings up an interesting point. Suppose the VCC of a device is at +5V but the output is TTL and the maximum swing is, say 3.5V. Should the output be characterises from -3.5 to 7.0v (the maximum voltage range that the output would ever realistically see) or does one still have to do the -5 to +10v range? Best Regards, Stephen Peters Intel Corp. Syed: Here are my views on your questions: (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. (2) The table itself must go to at least the specified limits. It is permissible to do the measurements over a reasonable range and then extrapolate to the end points. For example, you man not want to measure below -2V, but you still need to provide at least one extrapolated data point out to -5V if Vcc is 5V. Bob Ross, Interconnectix, Inc. > Hi fellow gurus: > Got two questions about the V/I table. > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > be from +ve to -ve number as well ? > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > 2) For most of the V/I table, IBIS shows that the voltage range should go from > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > swings that large. In that case, since we should not test a device beyond > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > the I/O all the way to +10 to -5V ??? > Regards, > Syed huq > National Semiconductor From bob@icx.com Wed Jul 20 16:19:03 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14472; Wed, 20 Jul 94 16:19:03 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA11531 for ; Wed, 20 Jul 94 19:03:41 -0400 Date: Wed, 20 Jul 94 15:47:17 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA29837; Wed, 20 Jul 94 15:47:17 PDT Message-Id: <9407202247.AA29837@icx.com> To: Will_Hobbs!ccm2.jf.intel.ccer@cadence.com, ibis@vhdl.org Subject: Re: Re[2]: Column Headers Will, I will formulate a formal bird18 and then distribute it to the committee. It will appear shortly. Bob Ross > Chris, Bob, > Sounds like another Bird, #18? Bob, since the bulk of the Bird is > contained in the paragraph you just wrote, do you want to post it? > Will From bob@icx.com Wed Jul 20 16:46:10 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14605; Wed, 20 Jul 94 16:46:10 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15220 for ; Wed, 20 Jul 94 19:33:36 -0400 Date: Wed, 20 Jul 94 16:24:04 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA29989; Wed, 20 Jul 94 16:24:04 PDT Message-Id: <9407202324.AA29989@icx.com> To: ibis@vhdl.org Subject: BIRD18 Column Headers for IBIS Ver. 2.1 Hello IBIS members: This BIRD extends the number of points from 100 to 101 per last IBIS Forum discussion. Upon further reflection, the proposed number of points for the [Pullup] and [Pulldown] tables is increased to 151 since they are mandated to extend of larger voltage ranges. The primary reason for these extensions is to allow automated IBIS file creation programs to sweep over the entire voltage data range of -5V to 10V at .1V increments, capture the endpoints and the 0V and 5V points. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 18 ISSUE TITLE: Number of Points REQUESTOR: Scott Bloom, Interconnectix, Inc. DATE SUBMITTED: 20 July 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is no statement in the [Diff Pin] specification which specifies the order of the columns, in contrast to specifications for other keywords. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The first paragraph of Usage Rules is modified using language similar to that in the [Pin Mapping] keyword to state that the column order is fixed. |============================================================================== | 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 |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 ont of 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. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION For reference, the original Usage Rule text is presented here: |Usage Rules: Enter only differential pin pairs. The [Diff Pin] column | contains a non-inverting pin number and the inv_pin column | always contains the corresponding inverting pin number for | I/O output. The vdiff column 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 tdelay columns | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). ****************************************************************************** ANY OTHER BACKGROUND INFORMATION ****************************************************************************** From bob@icx.com Wed Jul 20 17:13:41 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14703; Wed, 20 Jul 94 17:13:41 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17962 for ; Wed, 20 Jul 94 19:48:50 -0400 Date: Wed, 20 Jul 94 16:34:09 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00136; Wed, 20 Jul 94 16:34:09 PDT Message-Id: <9407202334.AA00136@icx.com> To: ibis@vhdl.org Subject: Retransmit of BIRD18 Column Headers for IBIS Ver. 2.1 Hello IBIS members: Disregard previous BIRD18, I tranmitted it before finishing the cutting and pasting Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 18 ISSUE TITLE: Number of Points REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 20 July 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is no statement in the [Diff Pin] specification which specifies the order of the columns, in contrast to specifications for other keywords. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The first paragraph of Usage Rules is modified using language similar to that in the [Pin Mapping] keyword to state that the column order is fixed. |============================================================================== | 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 |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 ont of 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. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION For reference, the original Usage Rule text is presented here: |Usage Rules: Enter only differential pin pairs. The [Diff Pin] column | contains a non-inverting pin number and the inv_pin column | always contains the corresponding inverting pin number for | I/O output. The vdiff column 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 tdelay columns | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). ****************************************************************************** ANY OTHER BACKGROUND INFORMATION ****************************************************************************** From randyh@Synopsys.COM Wed Jul 20 17:36:29 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14893; Wed, 20 Jul 94 17:36:29 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA12434 (5.65c/IDA-1.4.4 for ); Wed, 20 Jul 1994 17:33:11 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA18780 (5.65c/IDA-1.4.4); Wed, 20 Jul 1994 17:33:08 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id RAA25110; Wed, 20 Jul 1994 17:33:07 -0700 Date: Wed, 20 Jul 1994 17:33:07 -0700 Message-Id: <199407210033.RAA25110@clotho.synopsys.com> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbs@eos.ncsu.edu, ibis@vhdl.org From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: Librarian Proposal X-Mailer: Sorry I missed the meeting. Would this involve taking over the reflector also, providing email archive access, and public dial-in phone access? If so, it sounds like you are volunteering to take over all the activities regarding IBIS from the vhdl.org machine. Not a problem, just trying to understand the thought process. IBIS is in the top three groups of the most accessed set of files on the vhdl.org machine. A majority of the accesses are via anonymous FTP. The next largest set is via the email archive mechanism. Public dial-up comes in 3rd or 4th with gopher and WWW/Mosaic/HTTP being last (HTTP mostly because our server is not well linked in to the WWW lists yet.). To see more info, look at the monthly logs in /vi/misc on the vhdl.org machine. The files are named "stat.MMMYYYY" where MMM is the month and YYYY the year. At 04:51 PM 7/20/94 EDT, mbs@eos.ncsu.edu wrote: > >As discussed in the last IBIS Open Forum Call (on July 15) I raised the >suggestion that NCSU could act as the IBIS librarian and a proposal was >requested. Here it is. > > > IBIS LIBRARIAN PROPOSAL > >The Electronics Research Laboratory in the Department of Electrical and >Computer Engineering at North Carolina State University proposes to >maintain the IBIS library and act as the IBIS librarian. > >1. An IBIS mosaic home page. A temporary page has been created and > can be accessed by selecting > North Carolina State University > College of Engineering > Departments and Programs > Electrical and Computer Engineering > ECE Department Research Centers > Electronics Research Laboratory > IBIS > > The URL is http://www2.ncsu.edu/eos/project/erl_html/erl_ibis.html > > It is very unlikely that this address will change so feel free > to link to it. > >2. An IBIS anonymous ftp site. basically everything available through mosaic > will be on the ftp site (most of the files will be identical). > The address is ftp.eos.ncsu.edu The directory will be pub/ibis > >3. The library will contain IBIS models that have been validated by the > IBIS librarian. Models are valid if they they can be parsed (without > error) by the Golden Parser. > >4. The library will contain source code such as the Spice-to-IBIS code > and other bits and pieces currently maintained on vhdl.org:/pub/ibis > >5. The librarian will be Michael Steer (Associate Professor, Department of > Electrical and Computer Engineering, NCSU --- phone +1-919-515-5191, > fax +1-919-515-3027, email mbs@ncsu.edu) > >6. We will seek US government funds to support activities such as > Spice-to-IBIS for IBIS2.0 . > (The development of Spice-to-IBIS for IBIS1.1 was supported by ARPA.) > >7. The server will be run at no charge. Eventually, if the space utilized > grows to 500 MB+ or if the traffic becomes enormous we expect to acquire > government funding to provide a dedicated server and disk space. > >Running an IBIS server and functioning as librarian fits in well >with our CAD benchmarking activities. We welcome the opportunity to >participate and contribute. > > > >Michael Steer >mbs@ncsu.edu > > > Randolph E. (randy) Harr Senior Scientist and Program Manager Logic Modeling Group, Synopsys Inc. randyh@synopsys.com, (415) 694-1835 (voice) From bob@icx.com Wed Jul 20 18:32:46 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15215; Wed, 20 Jul 94 18:32:46 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA29773 for ; Wed, 20 Jul 94 21:18:49 -0400 Date: Wed, 20 Jul 94 18:10:43 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00545; Wed, 20 Jul 94 18:10:43 PDT Message-Id: <9407210110.AA00545@icx.com> To: huq@rockie.nsc.com, ibis@vhdl.org, speters@ichips.intel.com Subject: Re: Re[1]: V/I table in Bench measurements Stephen: For compliance with all versions of IBIS, the tables need to extend (even by extrapolation) to the full -5V to 10V range. I agree, you will never see the full range in practice. Since open collector versions of TTL could swing from Vcc (say 5V) to nearly 0V, I would not want to complicate the range specification at this point. (I personally favor not forcing the tables to be at the specified IBIS limits, but that is a separate issue and not the IBIS position.) With some simulators, there are some subtle behavior effects which could give significantly different simulations for what appear to be negligible IBIS differences. If for TTL the [Pullup] table has an I = 0 point at say 3.5V (actual voltage, not table voltage), and a [Pulldown] I = 0 point at say .2V, then the [Ramp] rise and fall transitions can extend over a 3.3V range with some simulators. However, if the [Pullup] table has a current of I = -1e-6 at 3.5V and I = 0 at 5V, then the [Ramp] rise and fall transitions can extend over a 4.8V range (some of which is in the 3.5V to 5V high Z region). This can cause a long time-constant dribble up in the low to high transition into a high resistance load. It may also give a different effective ramp rate. Related to this is the extraction of the dV/dt_f ramp rates with 50 ohms to Vcc = 5V versus 50 ohms to say Vcc - 1.5 = 3.5V. Some Spice simulations give much slower ramp rates under the first condition than under the second, more realistic situaton which does not force a transition through the high impedance region. So, with TTL there can be some practical considerations which do not apply for CMOS Logic. Along with the range question you raise, IBIS does not address these concerns. Bob Ross, Interconnectix, Inc. > Hello Bob, Syed: > You know, Syed's question brings up an interesting point. Suppose the > VCC of a device is at +5V but the output is TTL and the maximum swing > is, say 3.5V. Should the output be characterises from -3.5 to 7.0v > (the maximum voltage range that the output would ever realistically see) > or does one still have to do the -5 to +10v range? > Best Regards, > Stephen Peters > Intel Corp. > Syed: > Here are my views on your questions: > (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. > (2) The table itself must go to at least the specified limits. It is > permissible to do the measurements over a reasonable range and then extrapolate > to the end points. For example, you man not want to measure below -2V, but you > still need to provide at least one extrapolated data point out to -5V if Vcc > is 5V. > Bob Ross, > Interconnectix, Inc. > > Hi fellow gurus: > > Got two questions about the V/I table. > > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > > be from +ve to -ve number as well ? > > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > > 2) For most of the V/I table, IBIS shows that the voltage range should go from > > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > > swings that large. In that case, since we should not test a device beyond > > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > > the I/O all the way to +10 to -5V ??? > > Regards, > > Syed huq > > National Semiconductor From Derrick_Duehren@ccm2.jf.intel.com Thu Jul 21 10:29:55 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03017; Thu, 21 Jul 94 10:29:55 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qR1tK-000MQDC; Thu, 21 Jul 94 10:26 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qR1sL-000twjC; Thu, 21 Jul 94 10:25 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 21 Jul 94 10:25:40 PST Date: Thu, 21 Jul 94 10:25:40 PST From: Derrick Duehren Message-Id: <940721102540_10@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Re: Librarian Proposal IBISians, As acting librarian, this proposal sounds good to me. We'll need to find out how this proposal fits with whatever standards body we decide on. Mike, will NCSU be taking over all vhdl.org activities, including the reflector, or just the database of files? - Derrick Duehren Intel Corp. ______________________________ Reply Separator _________________________________ Subject: Librarian Proposal Author: mbs@eos.ncsu.edu at SMTPGATE Date: 7/20/94 2:28 PM As discussed in the last IBIS Open Forum Call (on July 15) I raised the suggestion that NCSU could act as the IBIS librarian and a proposal was requested. Here it is. IBIS LIBRARIAN PROPOSAL The Electronics Research Laboratory in the Department of Electrical and Computer Engineering at North Carolina State University proposes to maintain the IBIS library and act as the IBIS librarian. 1. An IBIS mosaic home page. A temporary page has been created and can be accessed by selecting North Carolina State University College of Engineering Departments and Programs Electrical and Computer Engineering ECE Department Research Centers Electronics Research Laboratory IBIS The URL is http://www2.ncsu.edu/eos/project/erl_html/erl_ibis.html It is very unlikely that this address will change so feel free to link to it. 2. An IBIS anonymous ftp site. basically everything available through mosaic will be on the ftp site (most of the files will be identical). The address is ftp.eos.ncsu.edu The directory will be pub/ibis 3. The library will contain IBIS models that have been validated by the IBIS librarian. Models are valid if they they can be parsed (without error) by the Golden Parser. 4. The library will contain source code such as the Spice-to-IBIS code and other bits and pieces currently maintained on vhdl.org:/pub/ibis 5. The librarian will be Michael Steer (Associate Professor, Department of Electrical and Computer Engineering, NCSU --- phone +1-919-515-5191, fax +1-919-515-3027, email mbs@ncsu.edu) 6. We will seek US government funds to support activities such as Spice-to-IBIS for IBIS2.0 . (The development of Spice-to-IBIS for IBIS1.1 was supported by ARPA.) 7. The server will be run at no charge. Eventually, if the space utilized grows to 500 MB+ or if the traffic becomes enormous we expect to acquire government funding to provide a dedicated server and disk space. Running an IBIS server and functioning as librarian fits in well with our CAD benchmarking activities. We welcome the opportunity to participate and contribute. Michael Steer mbs@ncsu.edu From Derrick_Duehren@ccm2.jf.intel.com Thu Jul 21 10:29:59 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03021; Thu, 21 Jul 94 10:29:59 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qR1tL-000MOYC; Thu, 21 Jul 94 10:26 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qR1sM-000twnC; Thu, 21 Jul 94 10:25 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 21 Jul 94 10:25:41 PST Date: Thu, 21 Jul 94 10:25:41 PST From: Derrick Duehren Message-Id: <940721102541_49@ccm.hf.intel.com> To: Jerry_Budelman@ccm2.jf.intel.com, Randy_L_Wilhelm@ccm.fm.intel.com, IBIS@vhdl.org Subject: IBIS 7/15 Meeting Minutes Text item: Text_1 Date: July 20, 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 7/15/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*, John Keifer* 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* Symmetry Martin Walker Synopsys, Logic Modeling G. Randy Harr Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum* Zeelan Technology George Opsahl, Hiro Moriyasu 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 # 8/5/94 (415) 904-8944 #809164 (1 hour only) 8/26/94 (415) 904-8944 #809164 9/16/94 (415) 904-8944 #809164 10/7/94 (415) 904-8944 #809164 (Yes, the phone and reservation numbers are the same for all these meetings!) 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. 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ Meeting Agenda -------------- Check-in Intros of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements/Treasurer's report Hobbs Opens for new issues All Press updates Hobbs/All Progress toward enlisting new IC vendors All New models available All Golden Parser, 2.1 plans Hobbs IBIS Librarian Powell IBIS Cookbook Peters Standards body affiliation Hobbs Spice-to-IBIS Converter Ross Pending BIRDs Hobbs Wrap-up, Next Meeting Plans Hobbs Intros of new IBIS participants None. Review of previous meeting's minutes There were no corrections made to last month's minutes. Miscellany/Announcements/Treasurer's report Nothing new to report on finances. Opens for new issues Bob Ross -- Number of Data Points in a Table. Press updates Nothing new to report. Progress toward enlisting new IC vendors Dave Moxeley will be working to get ASIC vendors to provide IBIS models. New models available None. Golden Parser, 2.1 Paul Munsey, who wrote the V1.1 golden parser, spoke to the task. Paul estimates 2x work/cost involved in creating the 2.1 parser. Paul can have the work completed by Sept 30th. This schedule skips an official Beta phase. Cadence, Interconnectix, HyperLynx, and Intel volunteered to help evaluate the parser during the process. Beta test was debated. Kellee recommended doing the Beta test. Consensus on Beta testing reached later in the meeting. With Beta starting Sept. 30, final release and ratification will occur in mid Nov. Will took a quick roll-call to see if companies are willing to fund the work at $500 each. 7 volunteered, 3 more are tentative. Since >20 V1.1 licenses were sold, we should have no problem raising the extra $5,000 needed (we have $4,000 in the bank). Vote taken to hire Paul Munsey and co. with a Sept. 30 Beta due, and $9,000 fee. Unanimously approved. Paul does not need any funding upfront, so we can decide the details of collecting the money later. Kellee recommends programming the parser to be fast, where reasonably possible. Also, per our discussion at DAC, new data structures need to be created for V2.0. Otherwise there were no comments on Paul's published list of issues. Several people volunteered to supply test files and statements of what is wrong with them. AR Stephen: Generate V2.0 test files for Paul by Aug. 1. AR Kumar: Generate V2.0 package test files for Paul by Aug. 1. Paul can be reached at (916) 784-7821, 73053.721@compuserve.com. AR Derrick: Put Paul on the reflector. [Request submitted] We need a parser evaluation plan. No one volunteered to do this task. We need someone to own the validation effort. AR Stephen: Start an evaluation/validation-plan discussion on the reflector. Bob Ross volunteered to be the single point of contact for Paul. Paul will also give status reports at each upcoming IBIS open forum meetings. IBIS Librarian Derrick proposed that it be left as is for now and reevaluated when we affiliate and formalize ourselves. Then Michael Steer of NCSU volunteered to handle the librarian task, including creating the scripts needed to automatically parse incoming models. NCSU has servers that could probably handle the database. Thank you Michael! AR Michael: Post a proposal to the reflector. [Done] IBIS Cookbook Stephen and Derrick posted the cookbook to vhdl.org this week. Standards Body Affiliation Andy Graham of CFI (CAD Framework Initiative, graham@cfi.org) gave a quick overview of CFI, which is interested in IBIS because it is a standard related to modeling standards and the EDA industry. 40 CFI members represent 2x the number of companies in other standards bodies. Most IC vendors already are affiliated with CFI. CFI believes they can help us on EDA and semiconductor vendor fronts, certification, marketing, legal, and financial. Matched ARPA funding a possibility. He recommends going after standards affiliation after we have wide acceptance. Andy questions our assumption that associating with a standards body will help get more semiconductor vendors producing IBIS models. Cost issues are critical to the IBIS forum. We want to maintain easy access by any company or group. Andy mentioned an example fee structure: a compliance tool kit. Vendor pays fee, gets tool kit, gets reference implementation, and a set of tests that can be used to verify compliance. When passed, they get to advertise, using a brand mark. Certification costs $5K for small guys for each major rev. For perspective, the average tool street price is $20 - $30K. Certification is a quality issue. AR Andy: Publish a two-page proposal for CFI affiliation. Andy thinks Sematech should recognize IBIS. Regarding copyright issues, CFI would own them. Otherwise, it would be considered to be in the public domain. Copyright enables CFI to indemnify people against claims of ownership of the standard. Patti Rusher of the EIA sent Will Hobbs a proposal. AR Will H: Post the proposal to the reflector. [Done] Spice-to-IBIS Converter Bob Ross and Scott Bloom are debugging the converter and adding some features. It is looking pretty good. NCSU should be able to post this out on the reflector within the next few weeks. Spice-to-IBIS2.0 will be a significant challenge. Bob wants the 2.0 converter work to proceed after the 1.1 converter is completed. Number of Data Points Bob Ross proposed increasing the 100 datapoint limit to 101. Everyone agreed that it makes sense. It will allow 100 points with 0 and 100 ends. AR Bob: Publish a BIRD for this change. [ Done] Pending BIRDs Not discussed. Wrap-up, Next Meeting Plans Will Hobbs and Derrick Duehren will be at a face-to-face Open Model Forum meeting in San Jose. They can attend for only the first hour. We decided to hold a one-hour meeting on 8/5/95 and regular meetings every third week through October 7th. From mbs@eos.ncsu.edu Thu Jul 21 13:02:25 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 AA04162; Thu, 21 Jul 94 13:02:25 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA19418; Thu, 21 Jul 1994 15:59:17 -0400 From: mbs@eos.ncsu.edu Message-Id: <9407211959.AA19418@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: IBIS Librarian and Reflector Date: Thu, 21 Jul 94 15:59:17 EDT Derrick Duehren writes >Mike, will NCSU be taking over all vhdl.org activities, including the reflector, >or just the database of files? We can provide the full services of vhdl.org (WWW/mosaic/http/gopher/reflector (i.e. list_server)/ftp with the exception of dial-up/guest log-in privleges. This exception is fairly major. The reason for this is that it violates many of the site licenses for software on our network. The only way we can provide dial-up is with a dedicated server which will be minus licensed software. We are in the process of negotiating the acquisition of such a server but we do not have it now. Currently free dial-up facilities would be available but eventually we may need to install a phone line. On the plus side the service will be provided at no cost now and at least not for many years into the future. We can almost be certain that SEMATECH will sponsor the effort eventually no matter where vhdl.org::/pub/ibis goes. The impression I got in the Open Forum is that some day we may grow into an albatross (as opposed to a humingbird) so that our currently free-as-a-bird access to vhdl.org may be reconsidered. Do we need to move now? As Derrick says should we wait until we ally with a standards-type organization. The other impression is that we need to run IBIS as cheaply as possible for a one or two years if it is to take off. I would like to see as much information freely available as possible. Independent of where the files are we are prepared to be the ``independent'' IBIS librarian. Michael Steer Associate Professor Electrical and Computer Engineering North Carolina State University mbs@ncsu.edu ________________________________________________________________________________ The original Librarian Proposal Follows As discussed in the last IBIS Open Forum Call (on July 15) I raised the suggestion that NCSU could act as the IBIS librarian and a proposal was requested. Here it is. IBIS LIBRARIAN PROPOSAL The Electronics Research Laboratory in the Department of Electrical and Computer Engineering at North Carolina State University proposes to maintain the IBIS library and act as the IBIS librarian. 1. An IBIS mosaic home page. A temporary page has been created and can be accessed by selecting North Carolina State University College of Engineering Departments and Programs Electrical and Computer Engineering ECE Department Research Centers Electronics Research Laboratory IBIS The URL is http://www2.ncsu.edu/eos/project/erl_html/erl_ibis.html It is very unlikely that this address will change so feel free to link to it. 2. An IBIS anonymous ftp site. basically everything available through mosaic will be on the ftp site (most of the files will be identical). The address is ftp.eos.ncsu.edu The directory will be pub/ibis 3. The library will contain IBIS models that have been validated by the IBIS librarian. Models are valid if they they can be parsed (without error) by the Golden Parser. 4. The library will contain source code such as the Spice-to-IBIS code and other bits and pieces currently maintained on vhdl.org:/pub/ibis 5. The librarian will be Michael Steer (Associate Professor, Department of Electrical and Computer Engineering, NCSU --- phone +1-919-515-5191, fax +1-919-515-3027, email mbs@ncsu.edu) 6. We will seek US government funds to support activities such as Spice-to-IBIS for IBIS2.0 . (The development of Spice-to-IBIS for IBIS1.1 was supported by ARPA.) 7. The server will be run at no charge. Eventually, if the space utilized grows to 500 MB+ or if the traffic becomes enormous we expect to acquire government funding to provide a dedicated server and disk space. Running an IBIS server and functioning as librarian fits in well with our CAD benchmarking activities. We welcome the opportunity to participate and contribute. Michael Steer mbs@ncsu.edu From Derrick_Duehren@ccm2.jf.intel.com Thu Jul 21 19:51:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08113; Thu, 21 Jul 94 19:51:18 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qRAec-000MOgC; Thu, 21 Jul 94 19:48 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qRAdc-000twcC; Thu, 21 Jul 94 19:47 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 21 Jul 94 19:47:04 PST Date: Thu, 21 Jul 94 19:47:04 PST From: Derrick Duehren Message-Id: <940721194704_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Re: IBIS Librarian and Reflector, cost Mike, Your offer is sounding better all the time. Regarding costs, we will likely have extra $ from Golden Parser 2.1 sales that could be used to purchase, or help purchase, a dedicated server. In my opinion, guest log-in is required. - Derrick ______________________________ Forward Header __________________________________ Subject: IBIS Librarian and Reflector Author: mbs@eos.ncsu.edu at SMTPGATE Date: 7/21/94 1:26 PM Derrick Duehren writes >Mike, will NCSU be taking over all vhdl.org activities, including >the reflector, or just the database of files? We can provide the full services of vhdl.org (WWW/mosaic/http/gopher/reflector (i.e. list_server)/ftp with the exception of dial-up/guest log-in privleges. This exception is fairly major. The reason for this is that it violates many of the site licenses for software on our network. The only way we can provide dial-up is with a dedicated server which will be minus licensed software. We are in the process of negotiating the acquisition of such a server but we do not have it now. Currently free dial-up facilities would be available but eventually we may need to install a phone line. On the plus side the service will be provided at no cost now and at least not for many years into the future. We can almost be certain that SEMATECH will sponsor the effort eventually no matter where vhdl.org::/pub/ibis goes. The impression I got in the Open Forum is that some day we may grow into an albatross (as opposed to a humingbird) so that our currently free-as-a-bird access to vhdl.org may be reconsidered. Do we need to move now? As Derrick says should we wait until we ally with a standards-type organization. The other impression is that we need to run IBIS as cheaply as possible for a one or two years if it is to take off. I would like to see as much information freely available as possible. Independent of where the files are we are prepared to be the ``independent'' IBIS librarian. Michael Steer Associate Professor Electrical and Computer Engineering North Carolina State University mbs@ncsu.edu From huq@rockie.nsc.com Fri Jul 22 12:44:41 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19382; Fri, 22 Jul 94 12:44:41 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20075 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:33 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09133 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:32 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA08716; Fri, 22 Jul 94 12:42:48 PDT Date: Fri, 22 Jul 94 12:42:48 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9407221942.AA08716@rockie.nsc.com> To: huq@rockie.nsc.com, ibis@vhdl.org, speters@ichips.intel.com Subject: Re: Re[1]: V/I table in Bench measurements Cc: cjfgsc@tevm2.nsc.com Hello: I think bench data should be taken without exceeding the ABS MAX rating of the device. This could mean a swing smaller than the specified -5V to +10V. Maybe, the simulator can extrapolate the data point to the desired level. I am not sure if all simulators can do that or not. Regards, Syed Huq National Semiconductor > From speters@ichips.intel.com Wed Jul 20 16:15:25 1994 > To: huq@rockie.nsc.com, ibis@vhdl.org > Subject: Re[1]: V/I table in Bench measurements > Date: Wed, 20 Jul 1994 15:43:59 -0700 > From: Stephen Peters > Content-Length: 1624 > > > Hello Bob, Syed: > > You know, Syed's question brings up an interesting point. Suppose the > VCC of a device is at +5V but the output is TTL and the maximum swing > is, say 3.5V. Should the output be characterises from -3.5 to 7.0v > (the maximum voltage range that the output would ever realistically see) > or does one still have to do the -5 to +10v range? > > Best Regards, > Stephen Peters > Intel Corp. > > > > Syed: > > Here are my views on your questions: > > (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. > (2) The table itself must go to at least the specified limits. It is > permissible to do the measurements over a reasonable range and then extrapolate > to the end points. For example, you man not want to measure below -2V, but you > still need to provide at least one extrapolated data point out to -5V if Vcc > is 5V. > > Bob Ross, > Interconnectix, Inc. > > > Hi fellow gurus: > > > Got two questions about the V/I table. > > > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > > be from +ve to -ve number as well ? > > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > > > > 2) For most of the V/I table, IBIS shows that the voltage range should go from > > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > > swings that large. In that case, since we should not test a device beyond > > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > > the I/O all the way to +10 to -5V ??? > > > Regards, > > Syed huq > > National Semiconductor > > > From Will_Hobbs@ccm2.jf.intel.com Fri Jul 22 13:31:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19720; Fri, 22 Jul 94 13:31:05 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qRRBx-000MOlC; Fri, 22 Jul 94 13:27 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qRRAP-000twgC; Fri, 22 Jul 94 13:26 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 22 Jul 94 13:26:01 PST Date: Fri, 22 Jul 94 13:26:01 PST From: Will Hobbs Message-Id: <940722132601_1@ccm.jf.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org, speters@ichips.intel.com Cc: cjfgsc@tevm2.nsc.com Subject: Re[3]: V/I table in Bench measurements Text item: Syed, I agree that you should not try to sweep beyond what you think the part can safely handle. I suggest you do the extraploation, however, as that will give you the control over what the customers see. Consceivably a simulator might not extrapolate in the way you would want, or not do so at all. Will Hobbs Intel Corp. Hello: I think bench data should be taken without exceeding the ABS MAX rating of the device. This could mean a swing smaller than the specified -5V to +10V. Maybe, the simulator can extrapolate the data point to the desired level. I am not sure if all simulators can do that or not. Regards, Syed Huq National Semiconductor > From speters@ichips.intel.com Wed Jul 20 16:15:25 1994 > To: huq@rockie.nsc.com, ibis@vhdl.org > Subject: Re[1]: V/I table in Bench measurements > Date: Wed, 20 Jul 1994 15:43:59 -0700 > From: Stephen Peters > Content-Length: 1624 > > > Hello Bob, Syed: > > You know, Syed's question brings up an interesting point. Suppose the > VCC of a device is at +5V but the output is TTL and the maximum swing > is, say 3.5V. Should the output be characterises from -3.5 to 7.0v > (the maximum voltage range that the output would ever realistically see) > or does one still have to do the -5 to +10v range? > > Best Regards, > Stephen Peters > Intel Corp. > > > > Syed: > > Here are my views on your questions: > > (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. > (2) The table itself must go to at least the specified limits. It is > permissible to do the measurements over a reasonable range and then extrapolate > to the end points. For example, you man not want to measure below -2V, but you > still need to provide at least one extrapolated data point out to -5V if Vcc > is 5V. > > Bob Ross, > Interconnectix, Inc. > > > Hi fellow gurus: > > > Got two questions about the V/I table. > > > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > > be from +ve to -ve number as well ? > > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > > > > 2) For most of the V/I table, IBIS shows that the voltage range should go from > > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > > swings that large. In that case, since we should not test a device beyond > > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > > the I/O all the way to +10 to -5V ??? > > > Regards, > > Syed huq > > National Semiconductor > > > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: cjfgsc@tevm2.nsc.com Subject: Re: Re[1]: V/I table in Bench measurements To: huq@rockie.nsc.com, ibis@vhdl.org, speters@ichips.intel.com Message-Id: <9407221942.AA08716@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Fri, 22 Jul 94 12:42:48 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA08716; Fri, 22 Jul 94 12:42:48 PDT Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09133 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:32 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20075 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:33 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19382; Fri, 22 Jul 94 12:44:41 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 22 Jul 94 12 Received: from hermes by ichips.intel.com (5.64+/10.0i); Fri, 22 Jul 94 12:52:51 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRQgW-000twdC; Fri, 22 Jul 94 12:55 PDT From Will_Hobbs@ccm2.jf.intel.com Fri Jul 22 17:53:19 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21736; Fri, 22 Jul 94 17:53:19 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qRVHy-000MOMC; Fri, 22 Jul 94 17:50 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qRVGx-000tweC; Fri, 22 Jul 94 17:49 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 22 Jul 94 17:49:02 PST Date: Fri, 22 Jul 94 17:49:02 PST From: Will Hobbs Message-Id: <940722174902_1@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re[2]: IBIS Librarian and Reflector, cost Text item: Michael and other IBIS-folk, I like most of what Michael proposes, but I would prefer the main server to be vhdl.org, since that is widely known and established. Is there any problem with providing these services on vhdl.org? Will Hobbs Intel Corp. Mike, Your offer is sounding better all the time. Regarding costs, we will likely have extra $ from Golden Parser 2.1 sales that could be used to purchase, or help purchase, a dedicated server. In my opinion, guest log-in is required. - Derrick ______________________________ Forward Header _________________________________ _ Subject: IBIS Librarian and Reflector Author: mbs@eos.ncsu.edu at SMTPGATE Date: 7/21/94 1:26 PM Derrick Duehren writes >Mike, will NCSU be taking over all vhdl.org activities, including >the reflector, or just the database of files? We can provide the full services of vhdl.org (WWW/mosaic/http/gopher/reflector (i.e. list_server)/ftp with the exception of dial-up/guest log-in privleges. This exception is fairly major. The reason for this is that it violates many of the site licenses for software on our network. The only way we can provide dial-up is with a dedicated server which will be minus licensed software. We are in the process of negotiating the acquisition of such a server but we do not have it now. Currently free dial-up facilities would be available but eventually we may need to install a phone line. On the plus side the service will be provided at no cost now and at least not for many years into the future. We can almost be certain that SEMATECH will sponsor the effort eventually no matter where vhdl.org::/pub/ibis goes. The impression I got in the Open Forum is that some day we may grow into an albatross (as opposed to a humingbird) so that our currently free-as-a-bird access to vhdl.org may be reconsidered. Do we need to move now? As Derrick says should we wait until we ally with a standards-type organization. The other impression is that we need to run IBIS as cheaply as possible for a one or two years if it is to take off. I would like to see as much information freely available as possible. Independent of where the files are we are prepared to be the ``independent'' IBIS librarian. Michael Steer Associate Professor Electrical and Computer Engineering North Carolina State University mbs@ncsu.edu Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: IBIS Librarian and Reflector, cost To: IBIS@vhdl.org Message-Id: <940721194704_2@ccm.hf.intel.com> From: Derrick Duehren Date: Thu, 21 Jul 94 19:47:04 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 21 Jul 94 19:47:04 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qRAdc-000twcC; Thu, 21 Jul 94 19:47 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qRAec-000MOgC; Thu, 21 Jul 94 19:48 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08113; Thu, 21 Jul 94 19:51:18 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 21 Jul 94 19 Received: from hermes by ichips.intel.com (5.64+/10.0i); Thu, 21 Jul 94 19:53:38 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRAlz-000twcC; Thu, 21 Jul 94 19:55 PDT From uunet!qdt.com!jonp@uunet.uu.net Fri Jul 22 18:18:55 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21930; Fri, 22 Jul 94 18:18:55 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQwzsn20318; Fri, 22 Jul 1994 21:15:32 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 22 Jul 1994 21:15:20 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01322; Fri, 22 Jul 94 17:41:12 PDT Received: from qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA28061; Fri, 22 Jul 94 17:41:11 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQwzsh17775; Fri, 22 Jul 1994 19:54:26 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 22 Jul 1994 19:54:38 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01296; Fri, 22 Jul 94 16:51:01 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA28014; Fri, 22 Jul 94 16:51:00 PDT Date: Fri, 22 Jul 94 16:51:00 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9407222351.AA28014@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00446; Fri, 22 Jul 94 16:51:10 PDT To: uunet!uunet!rockie.nsc.com!huq@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: [uunet!ccm2.jf.intel.com!Will_Hobbs: Re[3]: V/I table in Bench measurements] Syed, I agree that you should not try to sweep beyond what you think the part can safely handle. I suggest you do not do the extraploation, however, as that will not give you the control over what the customers see. Consceivably a simulator vendor might know what he was doing and be able to extrapolate in the way best suited for his simulator. only partly in jest, jonp >Return-Path: >Date: Fri, 22 Jul 94 13:26:01 PST >From: Will Hobbs >To: > uunet!ichips.intel.com!speters >Cc: uunet!tevm2.nsc.com!cjfgsc >Subject: Re[3]: V/I table in Bench measurements >Text item: >Syed, >I agree that you should not try to sweep beyond what you think the part can >safely handle. I suggest you do the extraploation, however, as that will give >you the control over what the customers see. Consceivably a simulator might not >extrapolate in the way you would want, or not do so at all. >Will Hobbs >Intel Corp. Hello: I think bench data should be taken without exceeding the ABS MAX rating of the device. This could mean a swing smaller than the specified -5V to +10V. Maybe, the simulator can extrapolate the data point to the desired level. I am not sure if all simulators can do that or not. Regards, Syed Huq National Semiconductor > From speters@ichips.intel.com Wed Jul 20 16:15:25 1994 > To: huq@rockie.nsc.com, ibis@vhdl.org > Subject: Re[1]: V/I table in Bench measurements > Date: Wed, 20 Jul 1994 15:43:59 -0700 > From: Stephen Peters > Content-Length: 1624 > > > Hello Bob, Syed: > > You know, Syed's question brings up an interesting point. Suppose the > VCC of a device is at +5V but the output is TTL and the maximum swing > is, say 3.5V. Should the output be characterises from -3.5 to 7.0v > (the maximum voltage range that the output would ever realistically see) > or does one still have to do the -5 to +10v range? > > Best Regards, > Stephen Peters > Intel Corp. > > > > Syed: > > Here are my views on your questions: > > (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. > (2) The table itself must go to at least the specified limits. It is > permissible to do the measurements over a reasonable range and then extrapolate > to the end points. For example, you man not want to measure below -2V, but you > still need to provide at least one extrapolated data point out to -5V if Vcc > is 5V. > > Bob Ross, > Interconnectix, Inc. > > > Hi fellow gurus: > > > Got two questions about the V/I table. > > > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > > be from +ve to -ve number as well ? > > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > > > > 2) For most of the V/I table, IBIS shows that the voltage range should go from > > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > > swings that large. In that case, since we should not test a device beyond > > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > > the I/O all the way to +10 to -5V ??? > > > Regards, > > Syed huq > > National Semiconductor > > > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: cjfgsc@tevm2.nsc.com Subject: Re: Re[1]: V/I table in Bench measurements To: huq@rockie.nsc.com, ibis@vhdl.org, speters@ichips.intel.com Message-Id: <9407221942.AA08716@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Fri, 22 Jul 94 12:42:48 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA08716; Fri, 22 Jul 94 12:42:48 PDT Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09133 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:32 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20075 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:33 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19382; Fri, 22 Jul 94 12:44:41 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 22 Jul 94 12 Received: from hermes by ichips.intel.com (5.64+/10.0i); Fri, 22 Jul 94 12:52:51 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRQgW-000twdC; Fri, 22 Jul 94 12:55 PDT From mbs@eos.ncsu.edu Sat Jul 23 07:49:54 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 AA29167; Sat, 23 Jul 94 07:49:54 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA25528; Sat, 23 Jul 1994 10:46:45 -0400 From: mbs@eos.ncsu.edu Message-Id: <9407231446.AA25528@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: RE: IBIS LIBRARIAN PROPOSAL Date: Sat, 23 Jul 94 10:46:44 EDT It seems that there is no need to move from vhdl.org and it make more sense for IBIS to stay there. There is no need for NCSU to provide a home for IBIS. Modified Librarian Proposal (7/23/94) As discussed in the last IBIS Open Forum Call (on July 15) I raised the suggestion that NCSU could act as the IBIS librarian and a proposal was requested. It has been modified to reflect issues raised in email discussions since the original posting of the proposal. IBIS LIBRARIAN PROPOSAL July 23, 1994 The Electronics Research Laboratory in the Department of Electrical and Computer Engineering at North Carolina State University proposes to act as the IBIS librarian. The responsible person will be Michael Steer. 1. The IBIS library will be managed. 2. The library will contain IBIS models that have been validated by the IBIS librarian. Models are valid if they they can be parsed (without error) by the Golden Parser. Models will be treated as confidential until they have been validated and publicly released. 3. Scripts will be developed to facilitate automated model check-in as much as possible. 4. The library will contain source code such as the Spice-to-IBIS code. Golden parser executables will be maintained. Since Golden Parser source code is not publicly released I guess that they do not fit in the IBIS library. 5. The librarian will be Michael Steer (Associate Professor, Department of Electrical and Computer Engineering, NCSU --- phone +1-919-515-5191, fax +1-919-515-3027, email mbs@ncsu.edu) 6. WHAT OTHER DUTIES SHOULD GO HERE. I think that the librarian should not be the IBIS sysop. -------- END ------ QUESTION 1 ========== What shall we do in the rare event that golden parser bugs are detected while validating models. It is likely that many of these will be due to valid interpretations of the spec that were not previously considered. I think that we need a quick turn-around for addressing such problems. Possible procedures are: 1. The librarian throws his/her hands up in the air and reports the problem to the IBIS specification watchdogs who update the spec or golden parser. (Yeah, I know we like to say that the golden parser is the spec but the spec does have to be written down somewhere and there could be a discrepancy between the two.) 2. The librarian isolates the problem and produces a minimum IBIS file that demonstrates the problem. The IBIS file is doctored so as to preserve confidentiality. The file is then sent to the spec watchdogs. QUESTION 2 ========== I think that there needs to be an IBIS disclaimer regarding the models since we are providing them. Vendors put in their own disclaimer but we need something as well regarding the library. Any thoughts? From bob@icx.com Sat Jul 23 19:08:24 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03146; Sat, 23 Jul 94 19:08:24 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15144 for ; Sat, 23 Jul 94 22:03:39 -0400 Date: Sat, 23 Jul 94 18:48:09 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA14530; Sat, 23 Jul 94 18:48:09 PDT Message-Id: <9407240148.AA14530@icx.com> To: ibis@vhdl.org Subject: [Manufacturer] To Ibis Committee: Does anyone know of an "official" or "standardized" listing of manufacturer's names? In all version of IBIS, the [Manufacturer] keyword is required. Unless there are some guidelines, this "required" parameter would be hard to use other than for documentation. Bob Ross, Interconnectix, Inc. From speters@ichips.intel.com Sun Jul 24 16:36:26 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12931; Sun, 24 Jul 94 16:36:26 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Sun, 24 Jul 94 16:33:16 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Sun, 24 Jul 94 16:29:17 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Sun, 24 Jul 94 16:33:09 PDT Message-Id: <9407242333.AA14043@xtg801.intel.com> To: ibis@vhdl.org Subject: IBIS 2.1 testing/validation Date: Sun, 24 Jul 1994 16:33:08 -0700 From: Stephen Peters Hello fellow IBISans: These are my thoughts on what will be required to test/validate version 2.1 of the IBIS golden parser (Bob Ross also added a few comments). In no particulare order: 1. Run all existing 1.1 models -- both the ones publicly available on vhdl.org and any un-released models people my have -- against the 2.1 parser. Here we are looking to see that the 2.1 parser handles 1.1 files correctly. 1a. Take any existing/created IBIS files that contain 2.1 version features, designate them as ver1.1, and see that both parsers produce the same faliure indications. 2. Since the code for the new parser will be different, a '1.1 test suite' will have to be created and run against the ver1.1 parser. The purpose of this test suite is to test each aspect of the 1.1 spec. This includes both using all the possible keywords/parameters/choices available in ver_1.1 and (gulp!) testing to see that it detects missing stuff and errors. I'm not sure how one can test all the possible universe of errors so we may have to limit the error/screw-up testing to common cases. A thought just occured to me: this should be done soon, BEFORE Paul gets going on the 2.1 code so that weird corner cases can be found and brought to his attention. 3. Write a '2.1 test suite' that tests the features added in ver_2.0. As before, we need to test the features themselves and some common error cases. The 2.1 golden parser will have to pass both the 1.1 test suite and the 2.1 test suite. Passing is defined as: a) The 2.1 golden parser reacts the same way as the current 1.1 parser when parsing the 1.1 test suite. b) The 2.1 golden parser reacts in the expected/agreed-apon-way when parsing the 2.1 test suite. The tests suites are based upon Paul Munsay's list and a test matrix created by reading the specification. From the above, there are three major tasks that need to be accomplished: creating the test matrix, writing the ver1.1 test suite and writing the ver2.1 test suite. I would imagine that the 'early testers' have there own test that they run (or specific things that they look for) and gathering these test together may be a good place to start. Does anyone have any comments? Specifically, is this the right approach and, if it is, is anything missing? Best Regards, Stephen Peters Intel Corp. From Will_Hobbs@ccm2.jf.intel.com Mon Jul 25 08:46:44 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21608; Mon, 25 Jul 94 08:46:44 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSSBW-000MNuC; Mon, 25 Jul 94 08:43 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSSAR-000twdC; Mon, 25 Jul 94 08:42 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 08:42:14 PST Date: Mon, 25 Jul 94 08:42:14 PST From: Will Hobbs Message-Id: <940725084214_2@ccm.jf.intel.com> To: randyh@Synopsys.COM Cc: ibis@vhdl.org Subject: Re: FYI: On vhdl.org and IBIS Text item: Randy, Thanks for your mail. It prompts me to do something I've been intending to do for a long time, which is to heartily thank you and VHDL International for your tremendous support of IBIS. Will Hobbs Intel Corp. >To: mbs@eos.ncsu.edu >From: randyh@synopsys.com (Randolph E. "Randy" Harr) >Subject: Re: IBIS Librarian and Reflector >Cc: >Bcc: >X-Attachments: > >If you would like to talk verbally, call at the number listed below. > >I am all for a transfer, if there is value added. Your offer of providing more volunteer effort is tremendous. I would caution about committing though with monies or resources not yet obtained or in place (sematech, etc.). I have absolutely the best interests for IBIS in mind and would be more than supportive to move it off of vhdl.org but would want to make sure it is not dependent on resources not in place. > >As founder/funder/Sysop of VUG/VIUF and the vhdl.org machine; I can guarantee the support (hardware, etc.) wise for now and the future. In fact, we have just reduced our costs while increasing our reliability by moving the machine onto Synopsys' T1 (soon to be T3) line and increased our redundancy connections from 2 sites to 3 (BARRNet, Alternet and NWNet). We have been trying to provide one-stop shopping for EDA standards because, face it, we do not live in just a VHDL world -- we have many facets to our need. For this reason, we have gopher/ftp-mirror/URL links to all over the World. (Actually we purposely delayed our HTTP server until recently and are now just in the process of creating home pages for all the groups. Would you like to do the one for IBIS?) > >Vhdl.org sysops are all experts in the industry -- trying to assure up-time and quality of service. The vhdl.org volunteer sysops are Randy Kirchof, Sys Admin, CFI; Steve Grout, Sys Admin, PDES Inc.; Mark Clem, Sys Admin, IKOS; Mitch Wyle and Paul Evans, Sys Admins, Synopsys, and myself. We also have paid service backup / critical support from Lloyd Internetworking (consulting group made up of sysadmins from BARRNet, CERFNet, and MERITNet). We concentrate on keeping the general services up, current and working. As volunteers, we spread the load and responsibility around so it is not too much for any of us. With all our "volunteer" time spent supporting basic services, we do not have time to support individual group efforts. > >But many groups need a home; like IBIS did. Therefore, we provide a "group" support service. All we need know is who is/are the "sysop's" of the group. They are then all given accounts and full access to the vhdl.org machine and expected to maintain their own directory areas and reflectors. The vhdl.org sysops then concentrate on providing general support services to the groups such as gopher, mosaic, RCS, Gnu programs, custom scripts, listserv, backup/recovery, etc. Currently, Derrick Duehren and I are sysop'ing the IBIS group -- Derrick the directory and I keeping the reflector up-to-date. > >We are more than happy to expand/transfer the IBIS sysop'ing to utilize your volunteer efforts. Given the ease of global Internet connection, it should be just as easy for you to maintain and do your work on vhdl.org as from your own machine (I can attest to that). I propose that you start immediately with the "Librarian" function on vhdl.org. > >If you need additional, special services we can work with you to support. For example, many of the stds group are asking for secure (authorized) access via email to RCS (ci, co, etc.) to deal with their equivalent of BIRDS. This allows thems to email the BIRD (or rev of it), have it "checked in" and made available on the machine to others to access. As we get this service up for VITAL and the VHDL standards group, we can provide it to IBIS also. > >As it makes sense in the future, the complete IBIS services can be physically moved to your host. For the moment though, I would like to encourage your assistance directly on the vhdl.org IBIS sysop'ing. > Randolph E. (randy) Harr Senior Scientist and Program Manager Logic Modeling Group, Synopsys Inc. randyh@synopsys.com, (415) 694-1835 (voice) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. X-Mailer: Subject: FYI: On vhdl.org and IBIS From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) To: will_hobbs@ccm2.jf.intel.com Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Sender: randyh@engr.synopsys.com Message-Id: <199407230207.TAA02598@clotho.synopsys.com> Date: Fri, 22 Jul 1994 19:07:44 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id TAA02598 for ; Fri, 22 Jul 1994 19:07:44 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA23711 (5.65c/IDA-1.4.4 for ); Fri, 22 Jul 1994 19:07:4 Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA00683 (5.65c/IDA-1.4.4 for ); Fri, 22 Jul 1994 19:07:4 Received: from chronos.synopsys.com by hermes.intel.com (5.65/10.0i); Fri, 22 Ju Received: from hermes by ichips.intel.com (5.64+/10.0i); Fri, 22 Jul 94 19:05:58 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRWVi-000twdC; Fri, 22 Jul 94 19:08 PDT From Will_Hobbs@ccm2.jf.intel.com Mon Jul 25 09:16:02 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21941; Mon, 25 Jul 94 09:16:02 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSS4d-000MOmC; Mon, 25 Jul 94 08:36 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSS3X-000twdC; Mon, 25 Jul 94 08:35 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 08:35:07 PST Date: Mon, 25 Jul 94 08:35:07 PST From: Will Hobbs Message-Id: <940725083507_3@ccm.jf.intel.com> To: ibis@vhdl.org, ssm@mlb.semi.harris.com, si-list@android.EBay.Sun.COM Subject: Re: Help with package measurement Text item: Greetings, I took up the invitation to join the si-list reflector, and this mail appeared there. I thought it would be a good discussion to have on the ibis reflector, too. Steve, I hope you don't mind my cross-posting this, and would like to know if you are interested in getting onto the IBIS reflectors? Regards, Will Hobbs Intel Corp. I am on a team that has been developing IC package models at Harris for about a year. We have established a methodology for generating models with EM simulation that we are very comfortable with. Up to now we have been verifying the package models by measuring key parameters with a Tektronix TDR based system. We are now looking for alternative measurement methods so that we can also establish a standard methodology for model verification. I was wondering first of all if this is possible. That is, are some measurement methods better suited for particular package styles or particular ranges of frequency, so that more than one system is needed for good coverage. Any advice would be greatly appreciated. If you have any experience you would like to share, that would be great. If your work is proprietary, just some vendor contacts or references would be very helpful. We are currently interested in a system that results in lumped element SPICE models for: < 64 lead packages for high performance analog or RF applications (100 MHz - 5 GHz) ------------------------------------------------------------- Steve S. Majors | Harris Semiconductor Internet: ssm@mlb.semi.harris.com | PO Box 883 MS 62B-022 Phone: (407) 724-7432 | Melbourne, Fla. 32902 ------------------------------------------------------------- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Length: 1369 Subject: Help with package measurement To: si-list@android.EBay.Sun.COM Message-Id: <9407251256.AA27790@harris.mlb.semi.harris.com> From: ssm@mlb.semi.harris.com (Steve Majors) Date: Mon, 25 Jul 94 08:56:09 EDT Received: from phakt.mlb.semi.harris.com by harris.mlb.semi.harris.com (4.1/SMI- id AA27790; Mon, 25 Jul 94 08:56:09 EDT Received: from harris.mlb.semi.harris.com by slopoke.mlb.semi.harris.com (4.0/SM id AA11146; Mon, 25 Jul 94 08:56:10 EDT Received: from slopoke.mlb.semi.harris.com by Sun.COM (sun-barr.Sun.COM) id AA16045; Mon, 25 Jul 94 05:56:13 PDT Received: from Sun.COM by EBay.Sun.COM (8.6.9/SMI-5.3) id FAA21562; Mon, 25 Jul 1994 05:55:55 -0700 Received: from EBay.Sun.COM (postman) by android.EBay.Sun.COM (5.0/SMI-SVR4) id AA09175; Mon, 25 Jul 94 05:49:09 PDT Received: from android.EBay.Sun.COM by EBay.Sun.COM (5.0/SMI-5.3) id AA20700; Mon, 25 Jul 1994 05:59:20 +0800 Received: from EBay.Sun.COM (female.EBay.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16691; Mon, 25 Jul 94 05:59:25 PDT Received: from Sun.COM by hermes.intel.com (5.65/10.0i); Mon, 25 Jul 94 06:10:09 Received: from hermes by ichips.intel.com (5.64+/10.0i); Mon, 25 Jul 94 06:06:15 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qSPmO-000twcC; Mon, 25 Jul 94 06:09 PDT From Arpad_Muranyi@ccm.fm.intel.com Mon Jul 25 10:07:34 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22349; Mon, 25 Jul 94 10:07:34 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSTRr-000MOzC; Mon, 25 Jul 94 10:04 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSTQe-000twcC; Mon, 25 Jul 94 10:03 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 10:03:04 PST Date: Mon, 25 Jul 94 10:03:04 PST From: Arpad Muranyi Message-Id: <940725100304_1@ccm.hf.intel.com> To: ibis@vhdl.org, whobbs@ichips.intel.com Subject: Re: Bird 17, 101 points in tables Hi all, Since I missed the last IBIS open forum meeting due to vacationing, I am not sure what the background of BIRD 17 is. Even though I do not like the 100 point limitation in some ways, I still think it might be necessary because of the 100 point limit in the SPICE PWL sources. As far as I understand, if we allow more than 100 points, we would automatically exclude IBIS models to be used under SPICE platforms. (Let me know if I am wrong). Since most curves have slowly changing (less sharp corners), or flat regions, I think it is not necessary to use fine (0.1V) increments throughout the whole range of a curve. Even though it is additional work, it is possible to write a simple algorythm which increases the data points in quickly changing areas and reduces them elsewhere. Arpad Muranyi Intel Corporation From Arpad_Muranyi@ccm.fm.intel.com Mon Jul 25 10:35:39 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22631; Mon, 25 Jul 94 10:35:39 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qST4m-000MQvC; Mon, 25 Jul 94 09:40 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qST3h-000twdC; Mon, 25 Jul 94 09:39 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 09:39:21 PST Date: Mon, 25 Jul 94 09:39:21 PST From: Arpad Muranyi Message-Id: <940725093921_1@ccm.hf.intel.com> To: speters@ichips.intel.com, ibis@vhdl.org, huq@rockie.nsc.com Subject: Re: V/I table in Bench measurements Steven, Syed, Now that I am back from my vacation, here is my opinion on these questions: The reason we require these "extreme" ranges in the models is to make sure that all simulators handle the curves as they should in such extreme situations. If you can not measure that far, make an intelligent extrapolation to extend the data to the required range. Regarding the TTL device in a 5V environment, in my opinion, it should still use -5V to +10V, because there might be another device in the system that is CMOS, and very well overshoot beyond 7V. I feel that the ordering of the voltage should go from -V to +V and not +V to -V, because SPICE can not handle decreasing voltage tables in their PWL sources. For those who are using IBIS models on SPICE platforms this is important. Arpad Muranyi Intel Corporation Hello Bob, Syed: You know, Syed's question brings up an interesting point. Suppose the VCC of a device is at +5V but the output is TTL and the maximum swing is, say 3.5V. Should the output be characterises from -3.5 to 7.0v (the maximum voltage range that the output would ever realistically see) or does one still have to do the -5 to +10v range? Best Regards, Stephen Peters Intel Corp. Hi fellow gurus: Got two questions about the V/I table. 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it be from +ve to -ve number as well ? Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V 2) For most of the V/I table, IBIS shows that the voltage range should go from +10V to -5V. Problem is, there are devices whose I/O structure cannot handle swings that large. In that case, since we should not test a device beyond it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing the I/O all the way to +10 to -5V ??? Regards, Syed huq National Semiconductor From Arpad_Muranyi@ccm.fm.intel.com Mon Jul 25 10:45:20 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22766; Mon, 25 Jul 94 10:45:20 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSU2V-000MOeC; Mon, 25 Jul 94 10:42 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSU1Q-000twjC; Mon, 25 Jul 94 10:41 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 10:41:04 PST Date: Mon, 25 Jul 94 10:41:04 PST From: Arpad Muranyi Message-Id: <940725104104_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: BIRD18 Column Headers for IBIS Ver. 2.1 So is BIRD 17 or 18 the same thing? One more comment I forgot in my last EMAIL: If anything, I would like to see both clamps have the same range, -Vcc to Vcc, or even -Vcc to (2 x Vcc). Currently, the POWER clamp is only -Vcc to 0V, and the GND clamp is -Vcc to Vcc. We all agreed on earlier open forums that the clamp curves can also be used for internal pullup or pulldown structures ("resistors") for devices that have it. These "resistors" are usually weak transistors which are always ON. Since they are transistors, they have an I-V curve, not a straight resistive line. The best place to put these in an IBIS model is the clamp curve. Hovever, currently there is only one place to put such curves, the GND_clamp curve. This creates a few problems when I have a pullup "resistor" (which I have to make VCC relative) and I have to put it into the GND_clamp curve. If we extend the Vcc_clamp range to the same coverage as the GND_clamp, I could put the pullup "resistors" into the POWER_clamp, and the pulldown "resistors" into the GND_clamp curve and my problems would be gone. Arpad Muranyi Intel Corporation From Arpad_Muranyi@ccm.fm.intel.com Mon Jul 25 13:24:21 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24178; Mon, 25 Jul 94 13:24:21 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSWWN-000MQcC; Mon, 25 Jul 94 13:21 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSWVH-000twmC; Mon, 25 Jul 94 13:20 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 13:20:02 PST Date: Mon, 25 Jul 94 13:20:02 PST From: Arpad Muranyi Message-Id: <940725132002_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: [uunet!ccm2.jf.intel.com!Will_Hobbs: Re[3]: V/I table in Text item: Syed and Jon, As far as we are concerned, these tests are distructive, so why not sweep it to the fullest? What if the simulation tool does NOT know better, or care to extrapolate correctly (maybe because they think it is not necessary) but you need it because you think it is necessary? I suspect you would want to extrapolate then. Arpad Muranyi Intel Corporation Syed, I agree that you should not try to sweep beyond what you think the part can safely handle. I suggest you do not do the extraploation, however, as that will not give you the control over what the customers see. Consceivably a simulator vendor might know what he was doing and be able to extrapolate in the way best suited for his simulator. only partly in jest, jonp >Return-Path: >Date: Fri, 22 Jul 94 13:26:01 PST >From: Will Hobbs >To: > uunet!ichips.intel.com!speters >Cc: uunet!tevm2.nsc.com!cjfgsc >Subject: Re[3]: V/I table in Bench measurements >Text item: >Syed, >I agree that you should not try to sweep beyond what you think the part can >safely handle. I suggest you do the extraploation, however, as that will give >you the control over what the customers see. Consceivably a simulator might not >extrapolate in the way you would want, or not do so at all. >Will Hobbs >Intel Corp. Hello: I think bench data should be taken without exceeding the ABS MAX rating of the device. This could mean a swing smaller than the specified -5V to +10V. Maybe, the simulator can extrapolate the data point to the desired level. I am not sure if all simulators can do that or not. Regards, Syed Huq National Semiconductor > From speters@ichips.intel.com Wed Jul 20 16:15:25 1994 > To: huq@rockie.nsc.com, ibis@vhdl.org > Subject: Re[1]: V/I table in Bench measurements > Date: Wed, 20 Jul 1994 15:43:59 -0700 > From: Stephen Peters > Content-Length: 1624 > > > Hello Bob, Syed: > > You know, Syed's question brings up an interesting point. Suppose the > VCC of a device is at +5V but the output is TTL and the maximum swing > is, say 3.5V. Should the output be characterises from -3.5 to 7.0v > (the maximum voltage range that the output would ever realistically see) > or does one still have to do the -5 to +10v range? > > Best Regards, > Stephen Peters > Intel Corp. > > > > Syed: > > Here are my views on your questions: > > (1) The Voltage table can be presented in any order: -ve to +ve or +ve to -ve. > (2) The table itself must go to at least the specified limits. It is > permissible to do the measurements over a reasonable range and then extrapolate > to the end points. For example, you man not want to measure below -2V, but you > still need to provide at least one extrapolated data point out to -5V if Vcc > is 5V. > > Bob Ross, > Interconnectix, Inc. > > > Hi fellow gurus: > > > Got two questions about the V/I table. > > > 1) Does the Voltage table need to ramp down from a -ve number to a +ve or can it > > be from +ve to -ve number as well ? > > Ex: For [Pulldown] the Voltage table goes from -5.0V to +10.0V > > > > 2) For most of the V/I table, IBIS shows that the voltage range should go from > > +10V to -5V. Problem is, there are devices whose I/O structure cannot handle > > swings that large. In that case, since we should not test a device beyond > > it's Absolute Recommended Operating(ABS Max) range, is it O.K NOT to swing > > the I/O all the way to +10 to -5V ??? > > > Regards, > > Syed huq > > National Semiconductor > > > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: cjfgsc@tevm2.nsc.com Subject: Re: Re[1]: V/I table in Bench measurements To: huq@rockie.nsc.com, ibis@vhdl.org, speters@ichips.intel.com Message-Id: <9407221942.AA08716@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Fri, 22 Jul 94 12:42:48 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA08716; Fri, 22 Jul 94 12:42:48 PDT Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09133 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:32 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20075 for ibis@vhdl.org; Fri, 22 Jul 94 12:41:33 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19382; Fri, 22 Jul 94 12:44:41 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 22 Jul 94 12 Received: from hermes by ichips.intel.com (5.64+/10.0i); Fri, 22 Jul 94 12:52:51 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRQgW-000twdC; Fri, 22 Jul 94 12:55 PDT Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: [uunet!ccm2.jf.intel.com!Will_Hobbs: Re[3]: V/I table in Bench measurem To: uunet!uunet!rockie.nsc.com!huq@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Received: by f14.qdt.com (4.1/SMI-4.1) id AA00446; Fri, 22 Jul 94 16:51:10 PDT Message-Id: <9407222351.AA28014@sal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Fri, 22 Jul 94 16:51:00 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA28014; Fri, 22 Jul 94 16:51:00 PDT Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01296; Fri, 22 Jul 94 16:51:01 PDT Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 22 Jul 1994 19:54:38 -0400 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQwzsh17775; Fri, 22 Jul 1994 19:54:26 -0400 Received: from qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA28061; Fri, 22 Jul 94 17:41:11 PDT Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01322; Fri, 22 Jul 94 17:41:12 PDT Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 22 Jul 1994 21:15:20 -0400 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQwzsn20318; Fri, 22 Jul 1994 21:15:32 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21930; Fri, 22 Jul 94 18:18:55 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 22 Jul 94 18 Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qRVpB-000MNPC; Fri, 22 Jul 94 18:24 PDT Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRVoB-000twdC; Fri, 22 Jul 94 18:23 PDT From blooms@icx.com Mon Jul 25 13:44:22 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24297; Mon, 25 Jul 94 13:44:22 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA24847 for ; Mon, 25 Jul 94 16:33:50 -0400 Received: from localhost.ARPA by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA19016; Mon, 25 Jul 94 13:17:57 PDT Message-Id: <9407252017.AA19016@icx.com> To: Arpad Muranyi Cc: ibis@vhdl.org, whobbs@ichips.intel.com, blooms@icx.com, bob@icx.com Subject: Re: Bird 17, 101 points in tables In-Reply-To: Your message of "Mon, 25 Jul 1994 10:03:04 PST." <940725100304_1@ccm.hf.intel.com> Date: Mon, 25 Jul 1994 13:17:56 -0700 From: Scott Aron Bloom Arpad, Thank you for your feedback. After speaking with a Spice Simulator vendor, you concern was verified. There is a 100 point voltage pair limit on PWL power supplies. Based on this new information :^), Bob and I would now oppose BIRD 17. Therefore, the bird will be revoked. Scott Bloom InterConnectiX, Inc. >Hi all, >Since I missed the last IBIS open forum meeting due to vacationing, I am not >sure what the background of BIRD 17 is. > >Even though I do not like the 100 point limitation in some ways, I still think >it might be necessary because of the 100 point limit in the SPICE PWL sources. >As far as I understand, if we allow more than 100 points, we would automatically >exclude IBIS models to be used under SPICE platforms. (Let me know if I am >wrong). >Since most curves have slowly changing (less sharp corners), or flat regions, I >think it is not necessary to use fine (0.1V) increments throughout the whole >range of a curve. Even though it is additional work, it is possible to write a >simple algorythm which increases the data points in quickly changing areas and >reduces them elsewhere. >Arpad Muranyi >Intel Corporation From bob@icx.com Mon Jul 25 14:23:28 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24648; Mon, 25 Jul 94 14:23:28 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA28964 for ; Mon, 25 Jul 94 17:04:06 -0400 Date: Mon, 25 Jul 94 13:52:07 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA19219; Mon, 25 Jul 94 13:52:07 PDT Message-Id: <9407252052.AA19219@icx.com> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re: BIRD18 Column Headers for IBIS Ver. 2.1 Arpad Here are my views on the questions you raise: 1) BIRD18 applies only to [Diff Pin] and is totally unrelated to BIRD17 While cutting and pasting, I accidentally tranmitted a BIRD18 which had some BIRD17 verbage, and have subsequently retranmitted BIRD18. If you need the correct copy, I can send it to you. 2) Regarding the range of any VI table in IBIS, I interpret the mandated ranges as the Minimum ranges for IBIS compliant models. I believe there is nothing to prevent the [Power_clamp] table to be extended on either end. So IBIS does not prevent you from putting in a "weak", non-linear always on pullup resistor using the [Power_clamp] keyword for any range including to 0 or -Vcc. The [Gnd_clamp] data from 0 to Vcc (and beyond) would be set to 0 since the clamping curve currents are added. 3) For normal IBIS buffer applications, you would not need to extend the clamp ranges beyond what is specified (beyond Vcc for [Gnd_clamp] and below Vcc for [Power_clamp] because the clamping currents in these regions are typically negligible. So even if simulators do not do extroplation, the error would be neglibible. Your pullup resistor is an example where you need to extend the IBIS range because the currents are not negligible, and I believe IBIS already supports this application. Bob Ross, Interconnectix, Inc. > So is BIRD 17 or 18 the same thing? > One more comment I forgot in my last EMAIL: > If anything, I would like to see both clamps have the same range, -Vcc to Vcc, > or even -Vcc to (2 x Vcc). Currently, the POWER clamp is only -Vcc to 0V, and > the GND clamp is -Vcc to Vcc. > We all agreed on earlier open forums that the clamp curves can also be used for > internal pullup or pulldown structures ("resistors") for devices that have it. > These "resistors" are usually weak transistors which are always ON. Since they > are transistors, they have an I-V curve, not a straight resistive line. The > best place to put these in an IBIS model is the clamp curve. > Hovever, currently there is only one place to put such curves, the GND_clamp > curve. This creates a few problems when I have a pullup "resistor" (which I > have to make VCC relative) and I have to put it into the GND_clamp curve. If we > extend the Vcc_clamp range to the same coverage as the GND_clamp, I could put > the pullup "resistors" into the POWER_clamp, and the pulldown "resistors" into > the GND_clamp curve and my problems would be gone. > Arpad Muranyi > Intel Corporation From Arpad_Muranyi@ccm.fm.intel.com Mon Jul 25 15:51:40 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25284; Mon, 25 Jul 94 15:51:40 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSYJQ-000MPuC; Mon, 25 Jul 94 15:15 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSYIK-000twlC; Mon, 25 Jul 94 15:14 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 15:14:48 PST Date: Mon, 25 Jul 94 15:14:48 PST From: Arpad Muranyi Message-Id: <940725151448_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re[2]: BIRD18 Column Headers for IBIS Ver. 2.1 Text item: Bob, Thanks for your response. I would appreciate if you could resend BIRD 18 for me to make sure I got the right one. Regarding point 2) below, I wish everyone agreed with what you say, but since I am not sure, I feel it should be brought up in the Open Forum meetings. I am just afraid that if I put something in the POWER_clamp section into a range that is not specified now, someone might ignore it because it is outside the specified region. I agree with you on point 3) completely. Arpad Muranyi Intel Corporation Arpad Here are my views on the questions you raise: 1) BIRD18 applies only to [Diff Pin] and is totally unrelated to BIRD17 While cutting and pasting, I accidentally tranmitted a BIRD18 which had some BIRD17 verbage, and have subsequently retranmitted BIRD18. If you need the correct copy, I can send it to you. 2) Regarding the range of any VI table in IBIS, I interpret the mandated ranges as the Minimum ranges for IBIS compliant models. I believe there is nothing to prevent the [Power_clamp] table to be extended on either end. So IBIS does not prevent you from putting in a "weak", non-linear always on pullup resistor using the [Power_clamp] keyword for any range including to 0 or -Vcc. The [Gnd_clamp] data from 0 to Vcc (and beyond) would be set to 0 since the clamping curve currents are added. 3) For normal IBIS buffer applications, you would not need to extend the clamp ranges beyond what is specified (beyond Vcc for [Gnd_clamp] and below Vcc for [Power_clamp] because the clamping currents in these regions are typically negligible. So even if simulators do not do extroplation, the error would be neglibible. Your pullup resistor is an example where you need to extend the IBIS range because the currents are not negligible, and I believe IBIS already supports this application. Bob Ross, Interconnectix, Inc. > So is BIRD 17 or 18 the same thing? > One more comment I forgot in my last EMAIL: > If anything, I would like to see both clamps have the same range, -Vcc to Vcc, > or even -Vcc to (2 x Vcc). Currently, the POWER clamp is only -Vcc to 0V, and > the GND clamp is -Vcc to Vcc. > We all agreed on earlier open forums that the clamp curves can also be used for > internal pullup or pulldown structures ("resistors") for devices that have it. > These "resistors" are usually weak transistors which are always ON. Since they > are transistors, they have an I-V curve, not a straight resistive line. The > best place to put these in an IBIS model is the clamp curve. > Hovever, currently there is only one place to put such curves, the GND_clamp > curve. This creates a few problems when I have a pullup "resistor" (which I > have to make VCC relative) and I have to put it into the GND_clamp curve. If we > extend the Vcc_clamp range to the same coverage as the GND_clamp, I could put > the pullup "resistors" into the POWER_clamp, and the pulldown "resistors" into > the GND_clamp curve and my problems would be gone. > Arpad Muranyi > Intel Corporation Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: BIRD18 Column Headers for IBIS Ver. 2.1 To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Message-Id: <9407252052.AA19219@icx.com> Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA19219; Mon, 25 Jul 94 13:52:07 PDT From: bob@icx.com ( Bob Ross) Date: Mon, 25 Jul 94 13:52:07 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA28964 for ; Mon, 25 Jul 94 17:04:06 -0400 Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24648; Mon, 25 Jul 94 14:23:28 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 25 Jul 94 14 Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSXZm-000MNvC; Mon, 25 Jul 94 14:28 PDT Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qSXYh-000twlC; Mon, 25 Jul 94 14:27 PDT From randyh@Synopsys.COM Mon Jul 25 17:57:13 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26799; Mon, 25 Jul 94 17:57:13 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA12720 (5.65c/IDA-1.4.4 for ); Mon, 25 Jul 1994 17:53:56 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA04630 (5.65c/IDA-1.4.4); Mon, 25 Jul 1994 17:53:55 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id RAA26636; Mon, 25 Jul 1994 17:53:54 -0700 Date: Mon, 25 Jul 1994 17:53:54 -0700 Message-Id: <199407260053.RAA26636@clotho.synopsys.com> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bob@icx.com ( Bob Ross) From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: [Manufacturer] Cc: ibis@vhdl.org X-Mailer: Having worked with many in the industry on this very issue (Information Handling Services with a database of 1.5 mil semiconductor parts; 450k+ are IC's, Aspect Development, ExpertViews/Viewpoint International, and a few large electronics producers (IC consumers)); experience tells me "do not even attempt to ...". It becomes a major database issue just to keep the manufacturer names up-to-date and correct! This is because of the constant mergers, spin-offs, and sell-off of companies and product lines. Each issue of EE Times details 3-5 (on average) division / product-line sell-offs to another company; etc. If you wish to use anything other then uninterpreted text, I would suggest CAGE (Commercial and Government Entity) codes. This is the closest you will get to a "defined" list of manufacturers associated with a given component / product-line. Otherwise, until it becomes a problem or large, let each manufacturer introduce their own name in a format they desire -- with or without division qualification. >To Ibis Committee: > >Does anyone know of an "official" or "standardized" listing of manufacturer's >names? > >In all version of IBIS, the [Manufacturer] keyword is required. Unless >there are some guidelines, this "required" parameter would be hard >to use other than for documentation. > >Bob Ross, >Interconnectix, Inc. > > Randolph E. (randy) Harr Senior Scientist and Program Manager Logic Modeling Group, Synopsys Inc. randyh@synopsys.com, (415) 694-1835 (voice) From bob@icx.com Mon Jul 25 18:06:22 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26878; Mon, 25 Jul 94 18:06:22 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA29799 for ; Mon, 25 Jul 94 20:37:29 -0400 Date: Mon, 25 Jul 94 17:25:24 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA20048; Mon, 25 Jul 94 17:25:24 PDT Message-Id: <9407260025.AA20048@icx.com> To: ibis@vhdl.org Subject: BIRD18.1 [Diff Pin] Parameter Order Arpad and IBIS members: BIRD18 reissued as BIRD18.1 because found another error in title causing confusion. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 18.1 ISSUE TITLE: [Diff Pin] Parameter Order REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 20 July 1994 DATE REVISED: 25 July 1984 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is no statement in the [Diff Pin] specification which specifies the order of the columns, in contrast to specifications for other keywords. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The first paragraph of Usage Rules is modified using language similar to that in the [Pin Mapping] keyword to state that the column order is fixed. |============================================================================== | 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 |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 ont of 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. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION For reference, the original Usage Rule text is presented here: |Usage Rules: Enter only differential pin pairs. The [Diff Pin] column | contains a non-inverting pin number and the inv_pin column | always contains the corresponding inverting pin number for | I/O output. The vdiff column 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 tdelay columns | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). ****************************************************************************** ANY OTHER BACKGROUND INFORMATION ****************************************************************************** From Derrick_Duehren@ccm2.jf.intel.com Mon Jul 25 18:36:30 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27069; Mon, 25 Jul 94 18:36:30 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSbOI-000MOYC; Mon, 25 Jul 94 18:33 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSbND-000twmC; Mon, 25 Jul 94 18:32 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 25 Jul 94 18:32:03 PST Date: Mon, 25 Jul 94 18:32:03 PST From: Derrick Duehren Message-Id: <940725183203_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Re: [Manufacturer] Text item: Bob, The only control here is that we request each company to use the same name variation. I can't imagine how some standard list could be collected, other than by, maybe, the IRS. - Derrick ______________________________ Reply Separator _________________________________ Subject: [Manufacturer] Author: bob@icx.com at SMTPGATE Date: 7/23/94 7:19 PM To Ibis Committee: Does anyone know of an "official" or "standardized" listing of manufacturer's names? In all version of IBIS, the [Manufacturer] keyword is required. Unless there are some guidelines, this "required" parameter would be hard to use other than for documentation. Bob Ross, Interconnectix, Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: [Manufacturer] To: ibis@vhdl.org Message-Id: <9407240148.AA14530@icx.com> Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA14530; Sat, 23 Jul 94 18:48:09 PDT From: bob@icx.com ( Bob Ross) Date: Sat, 23 Jul 94 18:48:09 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15144 for ; Sat, 23 Jul 94 22:03:39 -0400 Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03146; Sat, 23 Jul 94 19:08:24 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Sat, 23 Jul 94 19 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qRtA2-000twcC; Sat, 23 Jul 94 19:19 PDT From uunet!qdt.com!jonp@uunet.uu.net Tue Jul 26 06:51:19 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04516; Tue, 26 Jul 94 06:51:19 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQxafn08680; Tue, 26 Jul 1994 09:46:30 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 26 Jul 1994 09:46:32 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01153; Mon, 25 Jul 94 17:47:44 PDT Received: from qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA02355; Mon, 25 Jul 94 17:47:43 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxadn16014; Mon, 25 Jul 1994 20:46:05 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 25 Jul 1994 20:46:08 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01091; Mon, 25 Jul 94 17:07:15 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA02212; Mon, 25 Jul 94 17:07:15 PDT Date: Mon, 25 Jul 94 17:07:15 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9407260007.AA02212@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00688; Mon, 25 Jul 94 17:07:26 PDT To: uunet!uunet!icx.com!blooms@uunet.uu.net Cc: uunet!uunet!ccm.fm.intel.com!Arpad_Muranyi@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!ichips.intel.com!whobbs@uunet.uu.net, uunet!uunet!icx.com!blooms@uunet.uu.net, uunet!uunet!icx.com!bob@uunet.uu.net In-Reply-To: Scott Aron Bloom's message of Mon, 25 Jul 1994 13:17:56 -0700 <9407252017.AA19016@icx.com> Subject: Bird 17, 101 points in tables About SPICE limitations etc: I don't really care if we allow more than 100 points but I don't think that SPICE (or any other simulator) limitations should be a consideration when making IBIS rules. If data wants to be in a certain format we should let it be that way and let the simulator companies force it into the proper format. I bet that if the SPICE companies got 200 point arrays they would figure out a way to get 100 good points out of it. jonp From Arpad_Muranyi@ccm.fm.intel.com Tue Jul 26 09:29:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05689; Tue, 26 Jul 94 09:29:05 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qSoko-000MRyC; Tue, 26 Jul 94 08:49 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qSojh-000twlC; Tue, 26 Jul 94 08:48 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 26 Jul 94 08:48:09 PST Date: Tue, 26 Jul 94 08:48:09 PST From: Arpad Muranyi Message-Id: <940726084809_1@ccm.hf.intel.com> To: jonp@qdt.com_ _at_smtpgate@ccm.hf.intel.com(Jon_Powell), ibis@vhdl.org Subject: Re: Bird 17, 101 points in tables Text item: Text Item Jon, I guess we are back to the good old question again: do we provide data as it comes off of the measurements, or do we make it easier for the tool to use it. In other words, should the person making the measurements extract the best 100 points or the (SPICE) tool vendor in the software. It seems to me that you like the beef as red as possible (raw data) which is good for those making the measurements. I am just wondering, do all the (SPICE) vendors subscribe to this? Arpad Muranyi Intel Corporation Subject: Bird 17, 101 points in tables About SPICE limitations etc: I don't really care if we allow more than 100 points but I don't think that SPICE (or any other simulator) limitations should be a consideration when making IBIS rules. If data wants to be in a certain format we should let it be that way and let the simulator companies force it into the proper format. I bet that if the SPICE companies got 200 point arrays they would figure out a way to get 100 good points out of it. jonp From bob@icx.com Wed Jul 27 10:40:48 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19413; Wed, 27 Jul 94 10:40:48 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA13080 for ; Wed, 27 Jul 94 13:19:34 -0400 Date: Wed, 27 Jul 94 10:02:45 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA26455; Wed, 27 Jul 94 10:02:45 PDT Message-Id: <9407271702.AA26455@icx.com> To: ibis@vhdl.org Subject: Librarian Questions Michael Steer and IBIS Committee: I also like your recent revised Librarian proposal of July 23, 1994. Here are my thoughts on your questions: QUESTION 1 ========== What shall we do in the rare event that golden parser bugs are detected while validating models. It is likely that many of these will be due to valid interpretations of the spec that were not previously considered.I think that we need a quick turn-around for addressing such problems. Possible procedures are: 1. The librarian throws his/her hands up in the air and reports the problem to the IBIS specification watchdogs who update the spec or golden parser. (Yeah, I know we like to say that the golden parser is the spec but the spec does have to be written down somewhere and there could be a discrepancy between the two.) 2. The librarian isolates the problem and produces a minimum IBIS file that demonstrates the problem. The IBIS file is doctored so as to preserve confidentiality. The file is then sent to the spec watchdogs. My response is that ibis files containing parser errors should be returned to the originator for resolution. The librarian and/or the originator can raise the issue with the IBIS committee. The BIRD process can be used to clarify the issue, or some similar process can be used to provisionally accept the parser error or modify the parser. The originator should control how the files get "doctored" if they need to be examined outside of his/her organization. The librarian could get involved either by working with the originator to raise the issue, or if possible, by generating a totally independent illustrative test case. QUESTION 2 ========== I think that there needs to be an IBIS disclaimer regarding the models since we are providing them. Vendors put in their own disclaimer but we need something as well regarding the library. Any thoughts? You raise a very good point. Would a general "README" in each directory suffice, or should each file contain such a disclaimer? If the second choice is the case, then the wording should be provided. I do not think the librarian should be responsible for any textual changes or additions to supplied IBIS files, but this may be an agreed upon check and exception case to control the disclaimer and expedite posting. Bob Ross, Interconnectix, Inc. From Derrick_Duehren@ccm2.jf.intel.com Wed Jul 27 13:49:55 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21370; Wed, 27 Jul 94 13:49:55 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qTEvo-000MSbC; Wed, 27 Jul 94 12:46 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qTEug-000twlC; Wed, 27 Jul 94 12:45 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 27 Jul 94 12:45:14 PST Date: Wed, 27 Jul 94 12:45:14 PST From: Derrick Duehren Message-Id: <940727124514_2@ccm.hf.intel.com> To: bob@icx.com_at_smtpgate@ccm.hf.intel.com, IBIS@vhdl.org Subject: Re: Librarian Questions/Disclaimer For what it's worth, there is a disclaimer in the 00readme file in the \models directory on vhdl.org. - Derrick ______________________________ Reply Separator _________________________________ Subject: Librarian Questions Author: bob@icx.com at SMTPGATE Date: 7/27/94 10:57 AM QUESTION 2 ========== I think that there needs to be an IBIS disclaimer regarding the models since we are providing them. Vendors put in their own disclaimer but we need something as well regarding the library. Any thoughts? You raise a very good point. Would a general "README" in each directory suffice, or should each file contain such a disclaimer? If the second choice is the case, then the wording should be provided. I do not think the librarian should be responsible for any textual changes or additions to supplied IBIS files, but this may be an agreed upon check and exception case to control the disclaimer and expedite posting. Bob Ross, Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Fri Jul 29 12:38:19 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19179; Fri, 29 Jul 94 12:38:19 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qTwrq-000MaQC; Fri, 29 Jul 94 11:41 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qTwqf-000twfC; Fri, 29 Jul 94 11:40 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 29 Jul 94 11:40:01 PST Date: Fri, 29 Jul 94 11:40:01 PST From: Will Hobbs Message-Id: <940729114001_1@ccm.jf.intel.com> To: ibis@vhdl.org, jrbren@VNET.IBM.COM Subject: Re: V_fixture Text item: John, I've forwarded this question on to hte IBIS reflector for general comment. Regards, Will Hobbs Intel Corp. Greetings, I have a question on the V_fixture ibis sub-keyword for [Falling Waveform]. This variable appears to expect 1 value, ie, typically the nominal power supply value. Since I use the same deck to measure [Ramp] as [Falling Waveform], my deck has the load resistor hooked to the power supply, which will be different for typ, min and max. Does this present a problem to the simulation vendor that V_fixture cannot handle a min and max value, or If I enter three values will they be handled correctly. Should I change my deck so the the load resistor is hooked to the nominal supply value and not vary it for min and max? How important is V_fixture? Also, are the values in the example in spec ver2.0 backwards? Wouldn't a [Falling Waveform] be pulling against a logic "1" voltage, and a [Rising waveform] be pulling against a GND type voltage? Please advise. Thanks, John Brennan Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: V_fixture To: ibis-info@vhdl.org From: "John Brennan (446-6982)" Date: Fri, 29 Jul 94 14:31:35 EDT Received: from BTVLABVM by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1585; Fri, 29 Jul 94 14:28:31 EDT Message-Id: <9407291835.AA18827@vhdl.vhdl.org> Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18827; Fri, 29 Jul 94 11:35:47 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 29 Jul 94 11 Received: from hermes by ichips.intel.com (5.64+/10.0i); Fri, 29 Jul 94 11:32:56 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qTwjn-000twdC; Fri, 29 Jul 94 11:32 PDT From bob@icx.com Fri Jul 29 19:38:56 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22354; Fri, 29 Jul 94 19:38:56 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA27589 for ; Fri, 29 Jul 94 22:33:59 -0400 Date: Fri, 29 Jul 94 19:24:51 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA04437; Fri, 29 Jul 94 19:24:51 PDT Message-Id: <9407300224.AA04437@icx.com> To: ibis@vhdl.org, jrbren@VNET.IBM.COM Subject: Re: V_fixture John: My initial response is that you uncovered a valid condition which we did not consider fully. We should have allowed a V_fixture_min, and V_fixture_max for cases where the fixture is tied to Vcc or for cases where it represents the Thevenin voltage (and can change). The same will apply for the [Model] subparameter Vref. It may need a Vref_min and Vref_max also. This should be the subject for further consideration and probably a BIRD. Bob Ross, Interconnectix, Inc. > Greetings, > I have a question on the V_fixture ibis sub-keyword for > [Falling Waveform]. This variable appears to expect > 1 value, ie, typically the nominal power supply value. > Since I use the same deck to measure [Ramp] as [Falling > Waveform], my deck has the load resistor hooked to the power > supply, which will be different for typ, min and max. > Does this present a problem to the simulation vendor that > V_fixture cannot handle a min and max value, or If I enter > three values will they be handled correctly. Should I change > my deck so the the load resistor is hooked to the nominal supply > value and not vary it for min and max? > How important is V_fixture? Also, are the values in the example > in spec ver2.0 backwards? Wouldn't a [Falling Waveform] be > pulling against a logic "1" voltage, and a [Rising waveform] > be pulling against a GND type voltage? > Please advise. > Thanks, > John Brennan