From owner-ibis Thu May 2 17:13:06 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA19906 for ; Thu, 2 May 1996 17:12:49 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 2 May 96 17:03 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 2 May 96 17:05 PDT Message-Id: Date: Thu, 2 May 96 17:05 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD34.1 SPICE PROGRAM To IBIS Committee: Below is an HSPICE program which demonstrates the transit time stored charge effect that BIRD34.1 is addressing. You can vary the Rdiode and TTdiode parameters. Bob Ross Interconnectix, Inc. * STORED CHARGE DEMONSTRATION PROGRAM 1 * * 5 V 10 ohm 1 nS Source, Z0 = 50, Td = 1 n Line: * * DUT with [Gnd Clamp] * ____________ | /| * o---/\/\/\--O____________)---o--|< |--o GND * 10 ohms Z0 = 1 nS | | \| | * TD = 50 ohms | | * |-/\/\/\-| * | 500 ohm Load for Probing * Vcc ---\ ------\ | * \ \ o /--\ * 0 V \------ \ / \------- * | | \---------/ * 1 nS |<----------->| * 1 nS, 10 ohm Choose TTgnd that matches the measured * Source Signal delay with the IBIS model simulation delay * * Example of TTgnd Extraction Setup * * * * Intrinsic * RS Diode +-----+ * |\ | ----> Id | | ----> Id * o---/\/\/\--+--| >|--+----o +-----|Clamp|-----+ * | |/ | | | | | | * | | o----| +-----+ |----o * | | | | | | | | * +---| |--+ +-------| |-------+ * | | | | * * Cj + Ct C_comp + Ct * * * Spice Model Vs IBIS Model Structure * * * * IBIS Ct EQUATION: * * Ct = TT * (q/KT) * Id * = TT * (38.4) * Id * at T = 27 deg C (300 deg K) * * Note, Cj and C_comp = 0 in this example * * REFERENCE OUTPUTS * * V(11) Unterminated line * RS TT * V(21) Default Diode 0 0 * V(31) Default Diode 0 TTdiode * V(41) Default Diode Rdiode 0 * V(51) Default Diode Rdiode TTdiode * * IBIS EQUIVALENT OUTPUTS * RS_Ext TT Equivalence * V(61) Default Diode 0 0 Rdiode Ct V(51) * (TT across Diode Only) * V(71) Default Diode 0 0 Rdiode Ct * (TT across Diode and RS_ext) * V(81) Table Diode 0 0 Rdiode Ct V(71) * (TT across Table Diode and RS_ext) * V(91) Table RS Diode 0 0 0 Ct V(71) with * (TT across Table Diode including RS=10 RS=10 * * DIODE PARAMETERS * .PARAM Rdiode = 10 .PARAM TTdiode = 10n * INPUT PULSE VIN 1 0 PULSE (5 0 0 1n 1n 15n 100n) ****** REFERENCE SIMULATIONS *********** * NO TERMINATION RS1 1 10 10 T1 10 0 11 0 Z0=50 TD=1n RL1 11 0 500 * DEFAULT DIODE RS2 1 20 10 T2 20 0 21 0 Z0=50 TD=1n RL2 21 0 500 D2 0 21 D1 * DEFAULT DIODE, TT=TTdiode RS3 1 30 10 T3 30 0 31 0 Z0=50 TD=1n RL3 21 0 500 D3 0 31 D2 * DEFAULT DIODE, RS=Rdiode RS4 1 40 10 T4 40 0 41 0 Z0=50 TD=1n RL4 41 0 500 D4 0 41 D3 * DEFAULT DIODE, TT=TTdiode, RS=Rdiode RS5 1 50 10 T5 50 0 51 0 Z0=50 TD=1n RL5 51 0 500 D5 0 51 D4 ******* IBIS EQUIVALENT SIMULATIONS ********* * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=RSdiode * Ct ACROSS DIODE ONLY RS6 1 60 10 T6 60 0 61 0 Z0=50 TD=1n R6 61 62 Rdiode V6 63 62 0 D6 0 63 D1 RL6 61 0 500 C6 62 0 C='(TTdiode*I(V6)*38.4+1e-15)' * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=RSdiode * Ct ACROSS TOTAL STRUCTURE RS7 1 70 10 T7 70 0 71 0 Z0=50 TD=1n R7 71 72 Rdiode V7 73 72 0 D7 0 73 D1 RL7 71 0 500 C7 71 0 C='(TTdiode*I(V7)*38.4+1e-15)' * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=RSdiode * Ct ACROSS TOTAL STRUCTURE RS8 1 80 10 T8 80 0 81 0 Z0=50 TD=1n R8 81 82 Rdiode V8 83 82 0 XD8 0 83 D1TABLE RL8 81 0 500 C8 81 0 C='(TTdiode*I(V8)*38.4+1e-15)' * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=0 * TABLE BASED ON 10 OHMS IN SERIES * Ct ACROSS TOTAL STRUCTURE RS9 1 90 10 T9 90 0 91 0 Z0=50 TD=1n V9 93 91 0 XD9 0 93 D3TABLE RL9 91 0 500 C9 91 0 C='(TTdiode*I(V9)*38.4+1e-15)' .MODEL D1 D( TT=0n RS=0 ) .MODEL D2 D( TT=TTdiode RS=0 ) .MODEL D3 D( TT=0n RS=Rdiode ) .MODEL D4 D( TT=TTdiode RS=Rdiode ) * D1 DIODE TABLE .SUBCKT D1TABLE 2 1 G1 1 2 PWL(1) 1 2 + -5.00000 -1.288e+17 + -1.50000 -226.9724g + -1.40000 -4.6299g + -1.30000 -94.4445e6 + -1.20000 -1.9265e6 + -1.10000 -39.2989k + -1.00000 -801.6450 + -900.00000m -16.3525 + -800.00000m -333.5690m + -700.00000m -6.8044m + -600.00000m -138.7999u + -500.00000m -2.8313u + -400.00000m -57.7558n + -300.00000m -1.1784n + -200.00000m -24.2224p + -100.00000m -580.2281f + 0. 0. + 5 0. .ENDS * D3 DIODE TABLE WITH FIXED 10 Ohm Series R .SUBCKT D3TABLE 2 1 G3 1 2 PWL(1) 1 2 + -5.00000 -419.4116m + -4.90000 -409.4733m + -4.80000 -399.5364m + -4.70000 -389.6011m + -4.60000 -379.6674m + -4.50000 -369.7355m + -4.40000 -359.8055m + -4.30000 -349.8774m + -4.20000 -339.9513m + -4.10000 -330.0274m + -4.00000 -320.1058m + -3.90000 -310.1867m + -3.80000 -300.2702m + -3.70000 -290.3564m + -3.60000 -280.4457m + -3.50000 -270.5381m + -3.40000 -260.6339m + -3.30000 -250.7334m + -3.20000 -240.8369m + -3.10000 -230.9446m + -3.00000 -221.0570m + -2.90000 -211.1745m + -2.80000 -201.2976m + -2.70000 -191.4268m + -2.60000 -181.5627m + -2.50000 -171.7061m + -2.40000 -161.8579m + -2.30000 -152.0190m + -2.20000 -142.1907m + -2.10000 -132.3745m + -2.00000 -122.5721m + -1.90000 -112.7859m + -1.80000 -103.0186m + -1.70000 -93.2739m + -1.60000 -83.5565m + -1.50000 -73.8730m + -1.40000 -64.2322m + -1.30000 -54.6473m + -1.20000 -45.1383m + -1.10000 -35.7386m + -1.00000 -26.5064m + -900.00000m -17.5637m + -800.00000m -9.2196m + -700.00000m -2.5359m + -600.00000m -131.8561u + -500.00000m -2.8282u + -400.00000m -57.7545n + -300.00000m -1.1784n + -200.00000m -24.2224p + -100.00000m -580.2281f + 0. 0. + 5 0. .ENDS .TRAN 10P 15N .OPTIONS POST METHOD=GEAR .END From owner-ibis Thu May 2 17:18:13 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA19956 for ; Thu, 2 May 1996 17:17:54 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 2 May 96 17:08 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 2 May 96 17:11 PDT Message-Id: Date: Thu, 2 May 96 17:11 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD34.1 2ND SPICE PROGRAM To IBIS Committee: This test program uses a different test setup. With this setup, the simlation output V(81) appears to be sensitive to the discrete diode table representation. It should be very close to V(71) and V(91) for Rdiode = 10 ohms. Bob Ross, Interconnectix, Inc. * STORED CHARGE DEMONSTRATION PROGRAM 2 * * -2 V to Vcc 50 ohm 1 nS Source, 50 ohm Load: * * * DUT with [Gnd Clamp] * 50 ohms | /| * Pulse Source o---/\/\/\----o--|< |--o GND * -2 V to Vcc | | \| | * | | * |-/\/\/\-| * | 50 ohm Probe Load * * Vcc/2 /----- /------- * / / * Without DUT -> / / <- With DUT * ___/------/ * -1 V * | | Choose TTgnd such that measured delay * equals IBIS model simulation delay * * Example of TTgnd Extraction * * * Intrinsic * RS Diode +-----+ * |\ | ----> Id | | ----> Id * o---/\/\/\--+--| >|--+----o +-----|Clamp|-----+ * | |/ | | | | | | * | | o----| +-----+ |----o * | | | | | | | | * +---| |--+ +-------| |-------+ * | | | | * * Cj + Ct C_comp + Ct * * * Spice Model Vs IBIS Model Structure * * * * IBIS Ct EQUATION: * * Ct = TT * (q/KT) * Id * = TT * (38.4) * Id * at T = 27 deg C (300 deg K) * * Note, Cj and C_comp = 0 in this example * * REFERENCE OUTPUTS * * V(11) Unterminated line * RS TT * V(21) Default Diode 0 0 * V(31) Default Diode 0 TTdiode * V(41) Default Diode Rdiode 0 * V(51) Default Diode Rdiode TTdiode * * IBIS EQUIVALENT OUTPUTS * RS_Ext TT Equivalence * V(61) Default Diode 0 0 Rdiode Ct V(51) * (TT across Diode Only) * V(71) Default Diode 0 0 Rdiode Ct * (TT across Diode and RS_ext) * V(81) Table Diode 0 0 Rdiode Ct V(71) * (TT across Table Diode and RS_ext) * V(91) Table RS Diode 0 0 0 Ct V(71) with * (TT across Table Diode including RS=10 RS=10 * * DIODE PARAMETERS * .PARAM Rdiode = 10 .PARAM TTdiode = 10n * INPUT PULSE .PARAM VCC = 5 VIN 1 0 PULSE (-2 VCC 0 1n 1n 15n 100n) ****** REFERENCE SIMULATIONS *********** * NO TERMINATION RS1 1 11 50 RL1 11 0 50 * DEFAULT DIODE RS2 1 21 50 RL2 21 0 50 D2 0 21 D1 * DEFAULT DIODE, TT=TTdiode RS3 1 31 50 RL3 31 0 50 D3 0 31 D2 * DEFAULT DIODE, RS=Rdiode RS4 1 41 50 RL4 41 0 50 D4 0 41 D3 * DEFAULT DIODE, TT=TTdiode, RS=Rdiode RS5 1 51 50 RL5 51 0 50 D5 0 51 D4 ******* IBIS EQUIVALENT SIMULATIONS ********* * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=RSdiode * Ct ACROSS DIODE ONLY RS6 1 61 50 R6 61 62 Rdiode V6 63 62 0 D6 0 63 D1 RL6 61 0 50 C6 62 0 C='(TTdiode*I(V6)*38.4+1e-15)' * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=RSdiode * Ct ACROSS TOTAL STRUCTURE RS7 1 71 50 R7 71 72 Rdiode V7 73 72 0 D7 0 73 D1 RL7 71 0 50 C7 71 0 C='(TTdiode*I(V7)*38.4+1e-15)' * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=RSdiode * Ct ACROSS TOTAL STRUCTURE RS8 1 81 50 R8 81 82 Rdiode V8 83 82 0 XD8 0 83 D1TABLE RL8 81 0 50 C8 81 0 C='(TTdiode*I(V8)*38.4+1e-15)' * DEFAULT DIODE, RS=0, TT=0, Ct Equation, External RS=0 * TABLE BASED ON 10 OHMS IN SERIES * Ct ACROSS TOTAL STRUCTURE RS9 1 91 50 V9 93 91 0 XD9 0 93 D3TABLE RL9 91 0 50 C9 91 0 C='(TTdiode*I(V9)*38.4+1e-15)' .MODEL D1 D( TT=0n RS=0 ) .MODEL D2 D( TT=TTdiode RS=0 ) .MODEL D3 D( TT=0n RS=Rdiode ) .MODEL D4 D( TT=TTdiode RS=Rdiode ) * D1 DIODE TABLE .SUBCKT D1TABLE 2 1 G1 1 2 PWL(1) 1 2 + -5.00000 -1.288e+17 + -1.50000 -226.9724g + -1.40000 -4.6299g + -1.30000 -94.4445e6 + -1.20000 -1.9265e6 + -1.10000 -39.2989k + -1.00000 -801.6450 + -900.00000m -16.3525 + -800.00000m -333.5690m + -700.00000m -6.8044m + -600.00000m -138.7999u + -500.00000m -2.8313u + -400.00000m -57.7558n + -300.00000m -1.1784n + -200.00000m -24.2224p + -100.00000m -580.2281f + 0. 0. + 5 0. .ENDS * D3 DIODE TABLE WITH FIXED 10 Ohm Series R .SUBCKT D3TABLE 2 1 G3 1 2 PWL(1) 1 2 + -5.00000 -419.4116m + -4.90000 -409.4733m + -4.80000 -399.5364m + -4.70000 -389.6011m + -4.60000 -379.6674m + -4.50000 -369.7355m + -4.40000 -359.8055m + -4.30000 -349.8774m + -4.20000 -339.9513m + -4.10000 -330.0274m + -4.00000 -320.1058m + -3.90000 -310.1867m + -3.80000 -300.2702m + -3.70000 -290.3564m + -3.60000 -280.4457m + -3.50000 -270.5381m + -3.40000 -260.6339m + -3.30000 -250.7334m + -3.20000 -240.8369m + -3.10000 -230.9446m + -3.00000 -221.0570m + -2.90000 -211.1745m + -2.80000 -201.2976m + -2.70000 -191.4268m + -2.60000 -181.5627m + -2.50000 -171.7061m + -2.40000 -161.8579m + -2.30000 -152.0190m + -2.20000 -142.1907m + -2.10000 -132.3745m + -2.00000 -122.5721m + -1.90000 -112.7859m + -1.80000 -103.0186m + -1.70000 -93.2739m + -1.60000 -83.5565m + -1.50000 -73.8730m + -1.40000 -64.2322m + -1.30000 -54.6473m + -1.20000 -45.1383m + -1.10000 -35.7386m + -1.00000 -26.5064m + -900.00000m -17.5637m + -800.00000m -9.2196m + -700.00000m -2.5359m + -600.00000m -131.8561u + -500.00000m -2.8282u + -400.00000m -57.7545n + -300.00000m -1.1784n + -200.00000m -24.2224p + -100.00000m -580.2281f + 0. 0. + 5 0. .ENDS .TRAN 10P 5N .OPTIONS POST METHOD=GEAR .END From owner-ibis Fri May 3 15:37:21 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA05219 for ; Fri, 3 May 1996 15:31:54 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 3 May 96 15:20 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 3 May 96 15:23 PDT Message-Id: Date: Fri, 3 May 96 15:23 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MODEL SOURCES To IBIS Committee: Here is a start at a list of possible IBIS model sources and contact people. Please let know if there are errors. Some more companies have IBIS models, but I do not have confirmation of a contact. So this list should be update shortly. Please let me know if there are other sources or future sources of IBIS models. In most cases the contact person would like to hear from you and of your requests since they may be the internal champion of IBIS. Bob Ross, Interconnectix, Inc. Altera (Future IBIS development planned) Gary Sugita 3 W. Plumeria San Jose, CA 95134 (408) 894-7882 garys@altera.com Cypress Semiconductor (Future IBIS development planned) Bruce Wenniger 3901 N. First Street San Jose, CA 95134 (408) 943-2688 bw@cypress.com ICS, Inc. Clock Gen. http://www.icsinc.com/products/pinfo ftp://ftp.aimnet.com/pub/users/icsinc/ibis Craig McKelvey 1271 Parkmoor Avenue San Jose CA 95126 (408) 925-9415 mckelvey@icssj.com IC Works Clock Gen., others under developement Craig Wiley 3725 North First Street San Jose, CA 95134-1700 (408) 922-0202, ext. 1175 cwiley@icworks.com IDT SRAM and other Misc. Models Kelly Maas 2670 Seely Ave. San Jose, CA 95134 maas@idt.com (408) 944-2078 Intel Corporation See Web Site http://www.vhdl.com/pub/ibis/models/intel Arpad Muranyi 1900 Prairie City Road Folsom, CA 95630 (916) 356-2558 arpad_muranyi@ccm.fm.intel.com Intel Corporation See Web Site Stephen Peters 2111 NE 25th Ave Hillsboro, OR 97124 (503) 264-4108 speters@ichips.intel.com ISSI Pipeline Burst SRAM Under development James Wang 680 Almanor Ave Sunnyvale CA 94086 (408) 774-4611 jwang@issiusa.com Micron Technology SRAM, DRAM, others Brian Johnson 8000 South Federal Way P.0. Box 6 Boise, ID 83707-0006 (208) 368-3849 brainjohnson@micron.com Mitsubishi Electronics America, Inc. Models under development Larry Alchesky 1050 East ArquesAve Sunnyvale, CA 94086 (408) 774-3071 lalchesk@msm.mea.com Motorola See Web Site http://www.mot.com.pub/SPS/PowerPC/support/hw_design/IBIS_Models PowerPC Applications Engineering risc_hotline@riscgate.sps.mot.com (512) 891-4488 National Semiconductor See Web Site http://www.vhdl.org/pub/ibis/models/national http://www.national.com Syed Huq 2900 Semiconductor Drive, M/S A-2529 Santa Clara, CA 95052 (408) 721-4874 huq@rockie.nsc.com Texas Instruments ASIC models Paul Grotrian MS-8666 8505 Forest Lane Dallas, TX 75243 (214) 480-4020 grotrian@asic.sc.ti.com Texas Instruments JTAG and Misc. Mode Sri Jandhyala MS-838 6412 Highway 75 South Sherman, TX 75070-0084 srij@ti.com VLSI Technology, Inc. See Web site for list http://www.vhdl.org/pub/ibis/models/vlsi Jerry Rose 8375 S. River Parkway, M/S260 Tempe, AZ 85284 (602) 752-6209 jerry.rose@tempe.vlsi.com ibismodels@tempe.vlsi.com From owner-ibis Fri May 3 21:58:51 1996 Received: from pimaia2y.prodigy.com (pimaia2y.prodigy.com [192.207.105.55]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id VAA07456 for ; Fri, 3 May 1996 21:58:46 -0700 (PDT) Received: from mime3.prodigy.com ([192.168.253.27]) by pimaia2y.prodigy.com (8.6.10/8.6.9) with ESMTP id AAB31418 for ; Sat, 4 May 1996 00:42:31 -0400 Received: (from root@localhost) by mime3.prodigy.com (8.6.10/8.6.9) id AAA02758 for ibis@vhdl.org; Sat, 4 May 1996 00:41:43 -0400 Message-Id: <199605040441.AAA02758@mime3.prodigy.com> X-Mailer: Prodigy Internet GW(v0.9beta) - ae02dm02sc06 From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Sat, 4 May 1996 00:41:42, -0500 To: ibis@vhdl.org Subject: Fwd: Re: Express Information Model -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Will, E-mail address for Alan Williams is alanrw@cs.man.ac.uk. He works under direction of Hilary Kahn at kahn@cs.man.ac.uk. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Friday, 03-May-96 01:02 AM > > From: Will Hobbs \ Internet: > (will_hobbs@ccm.jf.intel.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re: Express Information Model > > Text item: > > Olaf, > > Does it appear fairly complete? Is there any pointer to Alan's e-mail so > we can contact him? > > Will > > Hello all, > > today, I found an information-model of IBIS (2.0) on > 'vhdl.org/pub/die/express'. The author of this document is Alan Williams > of the University of Manchester. > > Maybe, this information is useful for the standardization process of ibis > and we may contact Alan Williams for further assistance? > > Olaf > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > Content-Type: text > X-Mailer: ELM [version 2.4 PL23] > Date: Tue, 23 Apr 1996 15:22:43 +0200 (MET DST) > To: ibis@vhdl.org > Subject: Express Information Model > Message-Id: <9604231322.AA11779@pluto.incases.com> > Received: by pluto.incases.com (4.1) id AA11779; Tue, 23 Apr 96 15:22: 44 > +0200 > Received: from pluto.incases.com by mail.pad.incases.com with smtp > (Smail3.1.28.1 #3) id m0uBi3I-00045PC; Tue, 23 Apr 96 15:22 MET DST > Received: from isdn.pad.incases.com(194.64.13.226) by center.farside.net > via sma p (V1.3) > id sma000592; Tue Apr 23 15:23:00 1996 > Received: (from bin@localhost) by center.farside.net (8.7.5/8.7.2) id > PAA00597 f > or ; Tue, 23 Apr 1996 15:23:10 +0200 (MET DST) > From: olaf@pad.incases.com > Received: from center.farside.net (bin@center.farside.net > [194.163.159.200]) by > vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA01149 for ; > Tue, 23 > Apr 1996 06:32:22 -0700 (PDT) > Received: from vhdl.vhdl.org by hermes.intel.com (8.7.4/10.0i); Tue, 23 > Apr 1996 > 08:10:42 -0700 > Received: from hermes.intel.com by ichips.intel.com (8.7.4/jIII) > id IAA20407; Tue, 23 Apr 1996 08:09:29 -0700 (PDT) > Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by > relay.jf. intel.com (8.7.4/8.7.3) with ESMTP id IAA14979; Tue, 23 Apr 1996 > 08:10:44 -0700 (PDT) > Return-Path: owner-ibis@vhdl.vhdl.org > > > ------- FORWARD, End of original message ------- From owner-ibis Sat May 4 11:47:58 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA18612 for ; Sat, 4 May 1996 11:47:40 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 4 May 96 11:38 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 4 May 96 11:40 PDT Message-Id: Date: Sat, 4 May 96 11:40 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD31.3 - Mated Models To IBIS Members: BIRD31.3 changes BIRD31.2 by making Tedge_rate optional. This is functionally equivalent to using the previously proposed method of reserving "0". Changes in BIRD31.3 are noted by "|*3" comment lines. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 31.3 ISSUE TITLE: Mated Models REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 11/22/95, 3/18/96, 4/29/96, 5/4/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: No guidance is given within IBIS with respect to modeling connectors, cables and sockets used to connect boards to boards and boards to components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: "Mated model" text is blended within the original PACKAGE MODELING section, and the section is renamed as PACKAGE, CONNECTOR, CABLE AND SOCKET MODELS. The whole section is presented with BIRD28.3 extensions and additional changes noted by "|*" lines. (References to the "PACKAGE MODELING" section elsewhere would be changed to the new title. These are not shown.) |============================================================================= | |* PACKAGE, CONNECTOR, CABLE, AND SOCKET MODELING |* |* This section describes the [Define Package Model] syntax and its matrix, |* transmission line, and discrete element extension formats. This section |* also describes [Define Mated Model] as a generic class of I/O terminal |* extensions which can be used to describe the electrical characteristics |* of connectors, sockets, and cables. These can be referred to as "mated |* models" because the are used to provide the interconnection between circuit |* boards through connectors or cables, and also between boards and components |* through sockets. |* |* The electrical format for data is identical. Some operational details |* and syntax are noted. |* | The [Package Model] keyword is optional. If more than the default RLC |* package model is desired, use the [Define Package Model] keyword. There |* is no reference within the [Component] keyword to any connector model. |* The information within the [Define Mated Model] is available to |* simulators to define the interconnections using the simulator-specific |* syntax and interfaces. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... |* [End Package Model] keywords for each package model that is defined. |* However, the mated model keywords can exist only in a separate |* .mmf, and not in a .ibs or .pkg file. It exits |* between the [Define Mated Model] ... [End Mated Model] keywords for each |* connector that is defined. For reference, the keywords are listed |* below. Full descriptions follow. |* Simulators that do not support these keywords will ignore all entries between |* the [Define Package Model] and [End Package Model] keywords or between the |* [Define Mated Model] and [End Connector Model] keywords. |* | |* [Define Package Model] Required if the [Package Model] keyword is used |* [Define Mated Model] (note 3) | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) |** BIRD28.3 ADDITION BELOW |** [Number of Sections] (optional) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) |* [Model Data] (note 4) |* [Resistance Matrix] (note 4, optional) |* [Inductance Matrix] (note 4) |* [Capacitance Matrix] (note 4) |* [Bandwidth] (note 4, required for Banded_matrix matrices only) |* [Row] (note 4) |* [End Model Data] (note 4) |* [End Package Model] (note 2) |* [End Mated Model] (note 3) | |* (note 1) Required when the [Define Package Model] or [Define Mated Model] |* keyword is used |* (note 2) Required for ending a package model definition |* (note 3) Required for beginning and ending a mated model definition |* (note 4) Used only when the [Model Data] ... [End Model Data] is used |* | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | |* USAGE RULES FOR THE .PKG AND .MMF FILES | | Package models are stored in a file whose name looks like: | .pkg. |* |* Mated models are stored in a file whose name looks like: | .mmf. | | The provided must adhere to the General Syntax Rules. Use the |* ".pkg" extension to identify files containing package models. Use the |* ".mmf" extension to identify files containing mated models. The .pkg and |* .mmf files | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment Char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg |* or .mmf files. The .pkg file is for package models only. The .mmf file |* is used for mated models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |*============================================================================= |* Keyword: [Define Mated Model] |* Required: Yes |*2 Sub-params: Tedge_rate, Cpad_1, Cpad_2 |* Description: Marks the beginning of a mated model description. |* Usage Rules: If the .mmf file contains data for more than one mated model, |* each section must begin with a new [Define Mated Model] |* keyword. The length of the mated model name must not |* exceed 40 characters in length. Blank characters are |* allowed. |* |*3 The Tedge_rate is as an optional subparameter defining the |*2 the minimum time edge rate for which the mated model is |*2 considered accurate under test fixture conditions. A more |*2 detailed mated model topology would be preferred if the edge |*2 rate were smaller. The Tedge_rate subparameter may serve |*2 to produce a warning that the simulations are being done |*2 outside of the mated model performance range. |*2 |*2 A numerical value must be defined. It is the input pulse |*2 rise time defined between the 20% and 80% points. |*2 This value will be the minimum value where the signal line |*2 "impedance" is within 10% of the simulated impedance. This |*2 impedance parameter is the dynamic ratio at the mated model |*2 input voltage to input current over time under the condition |*2 that the signal line has a source and load termination of |*2 of 50 ohms and all other lines are grounded. A value of 0 |*3 is permitted, and would serve as an indication that the |*3 model is suitable for all edge rates. |*3 |* The Cpad_1 and Cpad_2 subparameters are optional and define |* default pad capacitances at sides 1 and 2 of the mated model. |* The values default to 0 pF if omitted. However, in all cases |* the simulator may override the default values based on |* actual geometrical pad dimensions. |*2 |*2 Other Notes: The mated model extends to the physical surfaces of the |*2 structure in the mated configuration. For example, the |*2 the printed circuit board fingers of an edge card connector |*2 that extend into the connector are included in the mated |*2 model electrical description. The Cpad_1 and Cpad_2 sub- |*2 parameters are optional default extensions for pads outside |*2 the mated model physical dimensions. |*------------------------------------------------------------------------------ [Define Mated Model] CONN4X40 Tedge_min = 0.1nS | Cpad_1 = .5pF Cpad_2 = 1.0pF |* |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package |* or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs and .pkg files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes |* Description: Declares the manufacturer of the package or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs and .pkg | files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of |* what kind of package the [Package Model] or mated model is |* representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package |* stub' or mated model. | A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |* This keyword also defines the number of sections that make up |* a mated model. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |****************************************************************************** |****************************************************************************** |* BIRD28.3 REPLACEMENT BELOW |****************************************************************************** |****************************************************************************** |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package |* or mated model | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section |* of a pin's die to pin connection or mated model connection. | Sub-Params: Len, L, R, C, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. |* |* For package models, the first column is used for listing each |* pin. For mated models, the first and second columns are used |* to list the side 1 pins and the corresponding side 2 pins. |* Normally the side 2 listing is the same as the side 1 listing. |* However, for cables and connectors that crossover or have |* different pin names or groupings at either end, the two columns |* will have different entries. All Matrix references will be |* based on the first column notation and order. | | Subparameters: | The subparameters specify the length, inductance, capacitance |* and resistance of each section of each stub on a package or mated |* model. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. The subparameters are defined as | follows: |* Len The length of a package or mated model stub section. |* Lengths are given | in terms of arbitrary 'units'. |* L The inductance of a package stub or mated model section, |* in terms of | 'inductance/unit length'. For example, if the total | inductance of a package stub section is 3.0nH and the | length of this section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). |* C The capacitance of a package stub or mated model section, |* in terms of | capacitance per unit length. |* R The DC (ohmic) resistance of a package stub or mated |* model section,in | terms of ohms per unit length. | Matrix Use of this subparameter means that this package stub |* or mated model | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | | Specifying a length or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. | |* Using the Subparameters to Describe Package or Mated Model |* Sections: | Each section description must begin with the Len subparameter and | ends with the slash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. All | package stub descriptions must contain the same number of | sections however, a particular section description can contain | no data (i.e. the description is given as 'Len = 0 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | slash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the slash. |----------------------------------------------------------------------------- [Pin Numbers] A1 Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 / A2 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.1 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01/ A5 Len = 0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | | Note that the actual length for each section is reported, even for | those sections that use the Matrix subparameter. | |* Note that there are two columns of pin numbers if this is for a |* mated model definition. |============================================================================= | Keyword: [Model Data] |* Required: Yes, if any of the sections in a package stub or mated model |* description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |*Description: Indicates the beginning of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub |* or mated model | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub |* or mated model | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 REPLACEMENT OF EXITING VERSION 2.1 TEXT |****************************************************************************** |****************************************************************************** |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The subparameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the subparameters. | After each of these subparameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are |* defined as ENTERING the pins of the package or mated model |* from the board | (General Syntax Rule #11). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | There are two different ways to extract the coefficients that are reported | in the the capacitance and inductance matrices. For the purposes of this | specification, the coefficients reported in the capacitance matrices shall | be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. | The Maxwell capacitance Kij is defined as the charge induced on conductor "j" | when conductor "i" is held at 1 volt and all other conductors are held at | zero volts. Note that Kij ( when i /= j) will be a negative number and | should be entered as such. Likewise, for the inductance matrix the | coefficients for Lij are defined as the voltage induced on conductor "j" | when conductor "i"'s current is changed by 1amp/sec and all other | conductors have no current change. | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | |* For even a modest-sized package or mated model, |* this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N x M, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The Banded_matrix is used to specify the coupling effects up to B pins | on either side. Two variations are supported. One allows for the coupling | to circle back on itself. This is technically a simple form of a bordered | block diagonal matrix. However, its data can be completely specified | in terms of a Banded_matrix for an N x M matrix consisting of N rows | and M = N + B columns. The second variation is just in terms of an N x N | matrix where no circle back coupling needs to be specified. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | For case where coupling can circle back on itself, consider a matrix of | N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | The first row only needs to specify the entries [1,1] through [1,1+B] since | all other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2,2+B], and so on. For row K | the entries [K,K] through [K,K+B] are given when K + B is less than or | equal to the size of the matrix N. When K + B exceeds N, the entries in the | last columns 1 ... B specify the coupling to the first rows. For row K, the | entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = | mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. To avoid | redundant entries, the bandwidth is limited to B <= int((N - 1) / 2). | | For the case where coupling does not circle back on itself, the process is | modified. Only N columns need to be considered. When K + B finally exceeds | the size of the matrix N, the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. This construction | constrains the bandwidth to B < N. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs). | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | With this convention, please note that the N'th row of an | N x N matrix has just a single entry (the diagonal entry). | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |*============================================================================= |* Keyword: [End Mated Model] |* Required: Yes |* Description: Marks the end of a mated model description. |* Usage Rules: This keyword must come at the end of each complete mated |* model description. |* |* Optionally, add a comment after the [End Package Model] keyword |* to clarify which package model has just ended. For example, |* |* [Define Mated Model] My_Model |* | |* | ... content of model ... |* | |* [End Mated Model] | end of My_Model |* |*---------------------------------------------------------------------------- [End Mated Model] |* |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] December 13, 1995 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRD31.1 is a total rewrite of BIRD31 which proposed connector models split and attached directly on [Component] models. It was impractical, limiting, and burdensome to provide split models. "Mated models" is introduced as a general term to describe connectors, cables and socket. Its electrical format is the same as the package model format. The final form will track any further developments in package model syntax. Thus the mated model text was merged with the existing package model text to form a combined section. The interconnection is based on simulator dependent interfaces. The [Component] pins for the connector footprint must contain reference to Model_names or NC, POWER, or GND. The package model elements can be used to approximate the termination effects if the connector is NOT mated. The mated model elements override these package parameters when the interconnection is made. The electrical model of cables contain the effects of the connectors at both ends along with the cable wire descriptions. For [Components] modeled on sockets, the package model of the [Component] model will be used. Here the simulator interface could distinguish between a connection made to another board, and a connection made to just a component. (3) The mated model introduces the [Define Mated Model] and [End Mated Model] keywords because it differs from the package model in the following ways: (a) It adds optional Cpad_1 and Cpad_2 subparameters for pad capacitance. Most connector model do not include these effects. (b) The mated model is NOT referenced by any [Component] directly. The simulator interface determines how a mated model is connected (or not connected as in the case of an empty socket for optional memory. (c) The mated model must exist only in a separate file since it cannot be determined which mated model file to use if it also exists within a .ibs file. (In contrast, the [Package Model] keyword provides the direct reference, and its model is searched first in the .ibs file and then in any .pkg file.) (d) The mated model contains two columns of pins so that the pins on one side can be defined differently than the pins on the other side. Thus cables which have cross-over connections, or which can be split and feed several different connectors can be described. BIRD31.2 contains two addtions to the mated model definition that were requested at the April 19, 1996 meeting and discussed in related e-mail by Hank Herrmann and David Fogel. A definition of the mate model physical boundary is clarified. Also the Tedge_rate parameter is needed because there is no surrounding basis to know whether the mate model is accurate enough for the simulations. With package models, it is presumed that the model is of suitable accuracy to be used with the associated components. Since the Tedge_rate is required, it is necessary to specify how it is determined. Hank Herrmann recommended an impedance profile method to relate physical and simulated model accuracy within 10% as a function of the edge_rate of the input signal. The point at which deviations exceed 10% is where the mated model needs more structural detail. The proposed impedance profile method illustrated below works both for single line models and coupled line models. A properly formed coupled line model will converge to the same impedance profile as a single line model of similar structural detail. So this subparameter is consistent for both cases. mate model or physical connection __ --> i(t), v(t) ______ / o---/\/\/\-------O______O--/\/\/\---o GND V(t) / 50 ohms ^ 50 ohms __/ ^ | | Compare v(t)/i(t) | (other contacts grounded) Tedge_rate is the 20% to 80% duration rise time Note, if faster edge rate models are constructed by cascading IDENTICAL sections, the Tedge_rate subparameter shall be defined using a large or maximal number of cascaded sections to accomodate simulators which will treat each stage using (coupled) transmission line methodology. Thus even if that stage is presented as one section, its Tedge_rate will be based on a distributed model with a large number of identical cascaded sections. Programs which use discrete lumped sections would need to expand a section along into the appropriate number of cascaded identical sections based on the Tedge_rate value. BIRD31.3 makes the subparameter Tedge_rate optional to resolve the objection to using "0" to indicate that no information is available (which was functionally equivalent to making the subparameter optional). ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Mon May 6 06:35:12 1996 Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id GAA21764 for ; Mon, 6 May 1996 06:35:11 -0700 (PDT) From: apanella@usa.molex.com Received: by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA29334 for ; Mon, 6 May 96 09:16:34 -0400 Received: from cc:Mail by uu1372.usa.molex.com id AA831395195 Mon, 06 May 96 08:06:35 Date: Mon, 06 May 96 08:06:35 Message-Id: <9604068313.AA831395195@uu1372.usa.molex.com> To: ibis@vhdl.org Subject: Bird 31.1 and 20/80 Spec. Gentlemen I have two questions: 1. 20% - 80% Rise/Fall time.. I have to admit, my understanding of ECL logic use in the semiconductor industry is somewhat low... but... The trend for our customers is a 10-90 Rise/Fall time specification... There is a different constant to calculate bandwidth using 20-80. The model could use the same structure but reference a different edge rate sdue to the different Rise/Fall measurment. How is a 20-80 Rise/Fall specification more readily extracted in a noisy simulation? Does this allow for extra roll of in the "dog leg" areas of a digital pulse? Are there "convergance" issues when using IBIS solvers? 2. Someday femptoSeconds will be the industry norm.... Is a "all edge rate model" pratical (using LCRZk matrices)? _gus Panella apanella@molex.com From owner-ibis Mon May 6 10:53:00 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA23295 for ; Mon, 6 May 1996 10:52:59 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id KAA14371 for ; Mon, 6 May 1996 10:43:46 -0700 (PDT) Received: from xtg801.intel.com by ichips.intel.com (8.7.4/jIII) id KAA23910; Mon, 6 May 1996 10:40:41 -0700 (PDT) Received: from localhost by xtg801.intel.com (4.1/SW1.11) id AA20212; Mon, 6 May 96 10:43:46 PDT Message-Id: <9605061743.AA20212@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD 31.2 comments Date: Mon, 06 May 1996 10:43:45 -0700 From: Stephen Peters Hello Bob, other: In your changes you state that a Tedge_rate of zero (0) means that the model is good for all edge rates. I propose that a value of zero indicate that the model has been validated at DC only (i.e. Dv/Dt = 0). Also, now that the Tedge_rate parameter is optional, what is it's default (non present) value? I propose assuming a default value of zero (DC). Regards, Stephen From owner-ibis Mon May 6 11:47:06 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA24023 for ; Mon, 6 May 1996 11:47:05 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id LAA22972; Mon, 6 May 1996 11:36:43 -0700 (PDT) Received: from xtg801.intel.com by ichips.intel.com (8.7.4/jIII) id LAA27329; Mon, 6 May 1996 11:33:37 -0700 (PDT) Received: from localhost by xtg801.intel.com (4.1/SW1.11) id AA21639; Mon, 6 May 96 11:36:42 PDT Message-Id: <9605061836.AA21639@xtg801.intel.com> To: bob@icx.com Cc: ibis@vhdl.org Subject: [Pin] Keyword in .pkg and .mmf files Date: Mon, 06 May 1996 11:36:41 -0700 From: Stephen Peters Hello Bob, fellow IBISains: While going thru the details of the .mmf stuff I realized that the way the spec is written the [Pin] keyword is REQUIRED in the stand alone .mmf file (it is also required in the stand alone .pkg file). Is this what you intended? exerpt below: >| ".mmf" extension to identify files containing mated models. The >| .pkg and .mmf files >| must contain all of the required elements of a normal .ibs file, including ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >| [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional >| elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], >| and [Comment Char] keywords. Regards, Stephen From owner-ibis Mon May 6 12:29:39 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA24254 for ; Mon, 6 May 1996 12:29:23 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 May 96 12:18 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 May 96 12:21 PDT Message-Id: Date: Mon, 6 May 96 12:21 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Re: Bird 31.1 and 20/80 Spec. Cc: apanella@use.molex.com, speters@ichips.com Gus, Stephen and IBIS Committee: 1. The 20% to 80% convention was chosen because it is consistent with the existing dV/dt_r and dV/dt_r subparameters. Also, since simulators might need to detect this during simulation, it gives less probability of other noise or reflection artifacts entering into the determination than, say, a 10% to 90% definition. Finally, ECL is a high speed technology often specified with a 50 ohm terminations and using the 20% to 80% definition. The 20% to 80% definition can be transformed to the 10% to 90% definition by the 4/3 factor or to the 0% to 100% definition by the 5/3 factor. So the bandwidth equivalent values could still be used from the 20% to 80% information after it has been converted to 10% to 90% values. This issue here is one of preference. The 10% to 90% definition or any other rise time definition could been used. However, the convention used needs to be stated. 2. The Tedge_rate = 0 convention choices are (1) means no ("practical") limit or (2) DC limit only. The first choice means that the simulator does not need to provide any checking. The second choice means that the model provider must still "invent" a very small value and the simulator may then need to provide some checking algorithm if the model structure is not limited. As Gus points out, the values could become very small in practice when there is a limit. Regarding Stephens suggestion (2), usually DC connections are known and would not be checked anyway, so (2) does not convey useful information to the simulator. Also, if the connection is used at any frequency, then you would generate a warning message automatically without testing. The same information is available by simply omitting the parameter. Anyway, these are some considerations on what Tedge_rate = 0 should be defined to mean. Bob Ross, Interconnectix, Inc. Secondly, > Gentlemen > > I have two questions: > > 1. 20% - 80% Rise/Fall time.. I have to admit, my understanding of > ECL logic use in the semiconductor industry is somewhat low... but... > The trend for our customers is a 10-90 Rise/Fall time specification... > There is a different constant to calculate bandwidth using 20-80. The > model could use the same structure but reference a different edge rate > sdue to the different Rise/Fall measurment. > > How is a 20-80 Rise/Fall specification more readily extracted in a > noisy simulation? Does this allow for extra roll of in the "dog leg" > areas of a digital pulse? Are there "convergance" issues when using IBIS > solvers? > > 2. Someday femptoSeconds will be the industry norm.... Is a "all edge > rate model" pratical (using LCRZk matrices)? > > > > _gus Panella > > apanella@molex.com From owner-ibis Mon May 6 14:39:17 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA25090 for ; Mon, 6 May 1996 14:39:12 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 May 96 14:09 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 May 96 14:12 PDT Message-Id: Date: Mon, 6 May 96 14:12 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: [Pin] Keyword in .pkg and .mmf files Stephen: You are correct. [Pin] is not included in a .mmf file. The list actually refers to the header items and not to other required entries under a [Component] keyword (such as [Package] or [Pin]) or [Model] keyword. Anyway some textual clarification will be put into the next revision of BIRD31.X. Bob Ross, Interconnectix, Inc. > Hello Bob, fellow IBISains: > While going thru the details of the .mmf stuff > I realized that the way the spec is written the > [Pin] keyword is REQUIRED in the stand alone > .mmf file (it is also required in the stand alone > .pkg file). Is this what you intended? > exerpt below: > >| ".mmf" extension to identify files containing mated models. The > >| .pkg and .mmf files > >| must contain all of the required elements of a normal .ibs file, including > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >| [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional > >| elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], > >| and [Comment Char] keywords. > Regards, > Stephen > From owner-ibis Mon May 6 17:23:40 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA26097 for ; Mon, 6 May 1996 17:22:44 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 May 96 17:11 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 May 96 17:14 PDT Message-Id: Date: Mon, 6 May 96 17:14 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: UPDATED IBIS MODEL SOURCES To IBIS Members: Here is an updated list with a few changes, corrections and additions that replaces the earlier list. Note, commerical vendors of IBIS models are not included on this list. Their offerings may be considered as additions or alternatives to those provided by the sources below. Bob Ross Interconnectix, Inc. Altera (Future IBIS development planned) Gary Sugita 3 W. Plumeria San Jose, CA 95134 (408) 894-7882 garys@altera.com AMCC Misc. Models Dick Spehn Bipolar and PECL Tim Thompson BiCMOS 6195 Lusk Boulevard San Diego, CA 92121-2793 (619) 535-6514 dicks@amcc.com timt@amcc.com Cypress Semiconductor (Future IBIS development planned) Bruce Wenniger 3901 N. First Street San Jose, CA 95134 (408) 943-2688 bw@cypress.com ICS, Inc. Clock Gen. http://www.icsinc.com Craig McKelvey 1271 Parkmoor Avenue San Jose CA 95126 (408) 925-9415 mckelvey@icssj.com IC Works Clock Gen., others under developement Craig Wiley 3725 North First Street San Jose, CA 95134-1700 (408) 922-0202, ext. 1175 cwiley@icworks.com IDT SRAM and other Misc. Models Kelly Maas 2670 Seely Ave. San Jose, CA 95134 (408) 944-2078 maas@idt.com Intel Corporation See Web Site http://www.vhdl.com/pub/ibis/models/intel Arpad Muranyi 1900 Prairie City Road Folsom, CA 95630 (916) 356-2558 arpad_muranyi@ccm.fm.intel.com Intel Corporation Stephen Peters 2111 NE 25th Ave Hillsboro, OR 97124 (503) 264-4108 speters@ichips.intel.com ISSI Models under development James Wang 680 Almanor Ave Sunnyvale CA 94086 (408) 774-4611 jwang@issiusa.com Micron Technology SRAM, DRAM, others Brian Johnson 8000 South Federal Way P.0. Box 6 Boise, ID 83707-0006 (208) 368-3849 brainjohnson@micron.com Mitsubishi Electronics America, Inc. Models under development Larry Alchesky 1050 East ArquesAve Sunnyvale, CA 94086 (408) 774-3071 lalchesk@msm.mea.com Motorola See Web Site http://www.mot.com.pub/SPS/PowerPC/support/hw_design/IBIS_Models PowerPC Applications Engineering (512) 891-4488 risc_hotline@riscgate.sps.mot.com National Semiconductor See Web Site http://www.vhdl.org/pub/ibis/models/national http://www.national.com Syed Huq 2900 Semiconductor Drive, M/S A-2529 Santa Clara, CA 95052 (408) 721-4874 huq@rockie.nsc.com Texas Instruments ASIC models Paul Grotrian MS-8666 8505 Forest Lane Dallas, TX 75243 (214) 480-4020 grotrian@asic.sc.ti.com Texas Instruments JTAG and Misc. Models Sri Jandhyala MS-838 6412 Highway 75 South Sherman, TX 75070-0084 (903) 868-5818 srij@ti.com VLSI Technology, Inc. See Web site http://www.vhdl.org/pub/ibis/models/vlsi Jerry Rose 8375 S. River Parkway, M/S260 Tempe, AZ 85284 (602) 752-6209 jerry.rose@tempe.vlsi.com ibismodels@tempe.vlsi.com Xilinx FPGAs Siuki Chan 2100 Logic Drive San Jose, CA 95124 (408) 879-4925 siuki@xilinx.com From owner-ibis Wed May 8 13:22:48 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA28862 for ; Wed, 8 May 1996 13:22:47 -0700 (PDT) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQaovw15136; Wed, 8 May 1996 16:13:34 -0400 (EDT) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Wed, 8 May 1996 16:13:31 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00855; Wed, 8 May 96 13:04:38 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06495; Wed, 8 May 96 13:04:38 PDT Date: Wed, 8 May 96 13:04:38 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9605082004.AA06495@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00733; Wed, 8 May 96 13:04:37 PDT To: ibis@vhdl.org Subject: DAC BOOTH The EIA has taken care of all signage that is required for the booth. There will be NO individual company participation. I am looking into alternatives. I will be making up a all-company flier and new IBIS SPOKEN HERE plaques for member companies. Sorry this didn't work out but the EIA did this without our input or direction. Jon From owner-ibis Fri May 10 10:49:18 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA01825 for ; Fri, 10 May 1996 10:49:17 -0700 (PDT) Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQapcw04859; Fri, 10 May 1996 13:39:58 -0400 (EDT) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 10 May 1996 13:39:59 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00841; Fri, 10 May 96 10:32:22 PDT Received: from a10.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20439; Fri, 10 May 96 10:32:22 PDT Date: Fri, 10 May 96 10:32:22 PDT From: crokusek@qdt.com (Chris Rokusek) Message-Id: <9605101732.AA20439@hal.qdt.com> To: ibis@vhdl.org Subject: home page error? Hi All, Just wondering if anyone else gets some "Network error" when attempting to read http://www.eia.org/eig/ibis/ibis.htm or if its something to do with our site. I'm using an old netscape_1.12. (Only reply if you can confirm) Regards, -Chris From owner-ibis Fri May 10 13:11:06 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA02722 for ; Fri, 10 May 1996 13:11:05 -0700 (PDT) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQapdg12071; Fri, 10 May 1996 16:01:55 -0400 (EDT) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 10 May 1996 16:01:57 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01155; Fri, 10 May 96 13:00:20 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21638; Fri, 10 May 96 13:00:20 PDT Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQapdf09997; Fri, 10 May 1996 15:54:20 -0400 (EDT) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 10 May 1996 15:54:21 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01121; Fri, 10 May 96 12:57:49 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21595; Fri, 10 May 96 12:57:49 PDT Date: Fri, 10 May 96 12:57:49 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9605101957.AA21595@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA06460; Fri, 10 May 96 12:57:48 PDT To: uunet!uunet!qdt.com!crokusek@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: <9605101732.AA20439@hal.qdt.com> (uunet!qdt.com!crokusek) Subject: Re: home page error? I think they have changed the structure. Go to www.eia.org and follow the links from there. (works for me) jon From owner-ibis Fri May 10 14:19:43 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA03213 for ; Fri, 10 May 1996 14:19:31 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 10 May 96 14:10 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 10 May 96 14:13 PDT Message-Id: Date: Fri, 10 May 96 14:13 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Agenda 5/17/96 IBIS Open Forum Meeting Agenda for 5/17/96 Bridge Number Reservation # Passcode (916) 356-9200 2-66106 5576848 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. (Note, Due to Daylight Savings Time, the meeting now starts at 15:00 GMT) 8:00 Check-In, Intros, Announcements Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Ross - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates All - New Models Available, Library Update All - Opens for New Issues All 8:15 EIA/IBIS Activities - DAC EDA Standards Booth Powell - Standards Meeting at DAC Hobbs 8:25 Administrative and Project Discussions DAC Meeting Agenda and Details Hobbs DAC Roadmap Meeting Hobbs Golden Parser 2.1 Status Roksuek/Ross S2IBIS 2.1 Status & Bug List Ross Express Information Model Actions Ross New Administrative Issues All 8:50 IBIS Comments on EDIF 3 9 9 Dodd/Wiens 9:00 Technical Discussion EGG10 - PARSER TESTS 1-5 Rokusek/Peters BIRD31.3 - Mated Models Ross Physical Package Committee Report Peters, etc. (BIRD33, SULTAN, EDIF, BIRD32, New proposal, etc.) BIRD34.1 - Stored Charge Proposal Progress Ross New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From owner-ibis Fri May 10 15:27:16 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA03594 for ; Fri, 10 May 1996 15:27:16 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.4/10.0i); Fri, 10 May 1996 22:15:58 GMT Received: from ccm.fm.intel.com by fmmail.fm.intel.com (Smail3.1.28.1 #2) id m0uHzXH-000rIpC; Fri, 10 May 96 14:15 PDT Received: by ccm.fm.intel.com (ccmgate 3.0) Fri, 10 May 96 14:15:39 PST Date: Fri, 10 May 96 14:15:39 PST From: Arpad Muranyi Message-ID: <960510141539_2@ccm.fm.intel.com> To: ibis@vhdl.org Subject: Re: home page error? Text item: I tried the adress you show, and it worked for me. http://www.eia.org/eig/ibis/ibis.htm Arpad ============================================================================= Hi All, Just wondering if anyone else gets some "Network error" when attempting to read http://www.eia.org/eig/ibis/ibis.htm or if its something to do with our site. I'm using an old netscape_1.12. (Only reply if you can confirm) Regards, -Chris 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: home page error? To: ibis@vhdl.org Message-Id: <9605101732.AA20439@hal.qdt.com> From: crokusek@qdt.com (Chris Rokusek) Date: Fri, 10 May 96 10:32:22 PDT Received: from a10.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20439; Fri, 10 May 96 10:32:22 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00841; Fri, 10 May 96 10:32:22 PDT Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 10 May 1996 13:39:59 -0400 Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQapcw04859; Fri, 10 May 1996 13:39:58 -0400 (EDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8. 7.3/8.7.3) with ESMTP id KAA01825 for ; Fri, 10 May 1996 10:49:17 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.7.4/8.7.3) with ESMTP id KAA12649; Fri, 10 May 1996 10:48:25 -0700 (PDT) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.192.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id KAA03899; Fri, 10 May 1996 10: 49:17 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Mon May 13 09:46:15 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA08241 for ; Mon, 13 May 1996 09:45:59 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 13 May 96 09:36 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 13 May 96 09:39 PDT Message-Id: Date: Mon, 13 May 96 09:39 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD35 - Multi-stagged Outputs To IBIS Committee: The multi-stagged switching functionality has been on the priority list for Version 3.0 addtions. Below is a proposal to start the discussion. The key elements of this proposal are: 1. The [Model] keyword and subparameters and all keywords under [Model] keep their same definitions. The existing [Pulldown], [Pullup] and [Ramp] keywords are still required for downward compatiblility. 2. Up to 10 new internal building blocks consisting of local [Pullup(n)], [Pulldown(n)], [Rising Waveform(n)] and [Falling Waveform(n)] keywords are permitted. 3. There are some syntactical ordering restrictions that preserve readability and permit one-pass parsing. 4. Only one of [Pulldown(n)] or [Pullup(n)] keywords is required to support Open_source (Open_sink) and Open_drain configurations. Both the [Rising Waveform(n)] and [Falling Waveform(n)] keywords are required for each stage. 5. The [Gnd Clamp] and [Power Clamp] keywords are not split into sections. Unlike exiting IBIS keywords, the new tables cannot be measured directly or even be produced easily by direct decomposition and simulation of Spice elements because of too much internal interaction. The actual construction would be by trial and validation and based on the known architectural intent. I have not explored all possibilities and implications of this proposal. However, I believe it is even possible to model bus hold effects using a final delayed correction stage. The example is fabricated to be a 100 ohm pullup/pulldown stage and a 100 ohm pulldown stage that is switched later and at a slower rate. This will provide both waveform shaping and impedance changes during transition. Bob Ross Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 35 ISSUE TITLE: Multi-stagged Outputs REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 5/13/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Modeling output transitions of buffers consisting of several sequentially switched internal devices has been a long standing request. The addition of the [Rising Waveform] and [Falling Waveform] keywords partially addresses the issue by waveform shaping control. However, these keywords do not model the dynamic impedance changes during transitions. The more direct solution is to add IBIS keywords which allow modeling the internal architecture more closely. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: An extension of the existing [Pullup], [Pulldown], [Rising Waveform] and [Falling Waveform] syntax is proposed. Up to ten sets (n=0,...,9) of keyword groupings for [Pulldown(n)], [Pullup(n)], [Rising Waveform(n)], and [Falling Waveform(n)] to describe modeling individually controlled switching. The summation of the new keywords override the existing [Pullup], [Pulldown], [Rising Waveform] and [Falling Waveform] descriptions of the low to high and high to low driver switching. All other parameters and requirements for the [Model] keyword do not change. Add the following keywords as a group afer the [Falling Waveform] keyword example: |============================================================================== | Keywords: [Pulldown(n)], [Pullup(n)], n=0,...,9 | Required: No | Description: Defines a partitioning of an output buffer into groupings | of [Pulldown(n)], [Pullup(n)], [Rising Waveform(n)], and | [Falling Waveform(n)] descriptions to be summed to form | the complete output response. | | Usage Rules: The [Pulldown(n)], [Pullup(n)] tables follow the same rules | as the [Pulldown], [Pullup], but override them. Either the | [Pulldown(n)] or the [Pullup(n)] or both may be given for (n). | Both the corresponding [Rising Waveform(n)] and [Falling | Waveform(n)] descriptions are required. These waveforms are | used to describe the switching on and off behavior. The | outputs of all stages are connected to produce the total | response. | | The usage of [Voltage Range] and [Pullup Reference] and | [Pulldown Reference] apply to all of the [Pulldown(n)] and | [Pullup(n)] tables | | Other Notes: If an output stage is described by only a [Pullup(n)] or | [Pulldown(n)] chararacterization, the unused table may be | omitted or may be entered using all zero entries for current. |============================================================================== |============================================================================== | Keywords: [Rising Waveform(n)], [Falling Waveform(n)], n=0...9 | Required: Yes, for [Pulldown(n)] and [Pullup(n)] specified | Description: Describes the shape of the rising and falling edge | waveforms of a driver component (n) to describe sequential | turn-on and turn-off of portions of a driver. | | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | | Usage Rules: The [Rising Waveform(n)] and [Falling Waveform(n)] keywords | follow the same rules as [Rising Waveform] and [Falling | Waveform] keywords. However, these timing descriptions | are used only with the corresponding [Pulldown(n)] and | [Pullup(n)] tables. | | The DC starting and ending values of each Waveform table | must be at the initial and final states of the transition. | These individual switches may be full transitions | from low-high or high-low or pulse transitions of low- | high-low and high-low-high. These transitions all must | be with respect to a common time reference so that delays | in transitions relative to one another can be used to | simulate squential turn-on and turn-off characteristics. | | Several waveform descriptions are permitted for each (n). | The model components 0...n must grouped in sequential order | and must start with (0). I.e., all table(0) keywords must | be placed before any table(1) keyword, and so forth. Up to | ten such keyword groupings are permitted. The sequential | ordering may differ from the switching sequence. E.g., | table(1) may switch before table(0). | | Other Notes: While the R_dut, L_dut, and C_dut subparameters are | allowed, they would normally not be used. | |------------------------------------------------------------------------------ | | Pulldown and Pullup Switch (0) | [Pulldown(0)] | | Voltage I(typ) I(min) I(max) -5.0V -50.0m NA NA 0.0V 0.0m NA NA 5.0V 50.0m NA NA 10.0V 100.0m NA NA | [Pullup(0)] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) -5.0V 50.0m NA NA 0.0V 0.0m NA NA 5.0V -50.0m NA NA 10.0V -100.0m NA NA | [Rising Waveform(0)] R_fixture = 100 V_fixture = 0 | |Time V(typ) V(min) V(max) 0.0ns 0.0 NA NA 0.5ns 2.5 NA NA 1.0ns 2.5 NA NA 5.0ns 2.5 NA NA | [Falling Waveform(0)] R_fixture = 100 V_fixture = 5 | |Time V(typ) V(min) V(max) 0.0ns 5.0 NA NA 0.5ns 2.5 NA NA 1.0ns 2.5 NA NA 5.0ns 2.5 NA NA | | Pulldown Switch (1) | [Pulldown(1)] | | Voltage I(typ) I(min) I(max) -5.0V -50.0m NA NA 0.0V 0.0m NA NA 5.0V 50.0m NA NA 10.0V 100.0m NA NA | [Rising Waveform(1)] R_fixture = 100 V_fixture = 5 | |Time V(typ) V(min) V(max) 0.0ns 2.5 NA NA 0.5ns 2.5 NA NA 1.5ns 5.0 NA NA 5.0ns 5.0 NA NA | [Falling Waveform(1)] R_fixture = 100 V_fixture = 5 | |Time V(typ) V(min) V(max) 0.0ns 5.0 NA NA 0.5ns 5.0 NA NA 1.5ns 2.5 NA NA 5.0ns 2.5 NA NA | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The proposal is designed to add to the existing IBIS structures and retain as much existing meaning as possible. The new "stage" tables follow all of the conventions of the existing non-stagged tables. For that reason, even the subparameters R_dut, L_dut, and C_dut are permitted, although they are not relevant nor are expected to be used. The overall structure is to connect independently controlled stages to a common output node. The relative relationhips between waveform controls are used to produce phased turn-on and turn-off models. The structure can be also be used to model other internal artifacts. These may include providing an extra boost pulse or providing bus hold modeling. A general objection to these structures is that they do not relate to any externally obtained extraction. The intent of these structures is to give a format for modeling a known architecture with behavioral blocks and to also add some detail to existing models. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Wed May 15 15:46:23 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA15066 for ; Wed, 15 May 1996 15:46:22 -0700 (PDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id PAA13301 for ; Wed, 15 May 1996 15:37:08 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id PAA13312 for ibis@vhdl.org; Wed, 15 May 1996 15:37:08 -0700 (PDT) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Wed, 15 May 96 15:37:08 PDT Date: Wed, 15 May 96 15:35:00 PDT From: Will Hobbs Message-ID: To: ibis@vhdl.org Subject: IBIS Face-to-face meeting at DAC, Friday, 6/8 IBIS-Folks, Here is some information so you can properly plan your DAC visit. Patti Rusher of EIA has made the arrangements for our face-to-face IBIS meeting in Las Vegas at the end of the DAC convention. We will have time for both technical discussions and essential administrative stuff, including election of new officers. The details: Date: Friday, June 8, 1996 Time: 9 AM to 1 PM local time Place: Las Vegas Hilton, the "Headquarters Hotel" adjacent to the Las Vegas Convention Center Patti has arranged for continental breakfast, and an overhead projector will be available. We can discuss remaining logistics at our Friday, 5/17 teleconference. Regards, Will Hobbs Chair, EIA IBIS Committee Intel Corp. From owner-ibis Thu May 16 07:43:41 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id HAA28237 for ; Thu, 16 May 1996 07:43:40 -0700 (PDT) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQapyo06531; Thu, 16 May 1996 10:31:55 -0400 (EDT) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Thu, 16 May 1996 10:31:57 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00707; Thu, 16 May 96 07:08:14 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA15334; Thu, 16 May 96 07:08:14 PDT Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQapym27963; Thu, 16 May 1996 10:01:40 -0400 (EDT) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 16 May 1996 10:01:42 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00663; Thu, 16 May 96 06:35:17 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA14868; Thu, 16 May 96 06:35:17 PDT Date: Thu, 16 May 96 06:35:17 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9605161335.AA14868@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00445; Thu, 16 May 96 06:35:14 PDT To: uunet!uunet!ccm.jf.intel.com!Will_Hobbs@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: (uunet!ccm.jf.intel.com!Will_Hobbs) Subject: Re: IBIS Face-to-face meeting at DAC, Friday, 6/8 >>>>> "Will" == Will Hobbs writes: Will> IBIS-Folks, Here is some information so you can properly Will> plan your DAC visit. Patti Rusher of EIA has made the Will> arrangements for our face-to-face IBIS meeting in Las Vegas Will> at the end of the DAC convention. We will have time for both Will> technical discussions and essential administrative stuff, Will> including election of new officers. Will> The details: Will> Date: Friday, June 8, 1996 Time: 9 AM to 1 PM local time Will> Place: Las Vegas Hilton, the "Headquarters Hotel" adjacent Will> to the Las Vegas Convention Center Will> Patti has arranged for continental breakfast, and an Will> overhead projector will be available. We can discuss Will> remaining logistics at our Friday, 5/17 teleconference. Will> Regards, Will> Will Hobbs Chair, EIA IBIS Committee Intel Corp. Friday is June 7. From owner-ibis Thu May 16 12:34:23 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA00941 for ; Thu, 16 May 1996 12:34:22 -0700 (PDT) Received: from ormail.intel.com by relay5.UU.NET with ESMTP (peer crosschecked as: ormail.intel.com [134.134.192.3]) id QQapzh05223; Thu, 16 May 1996 15:25:08 -0400 (EDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id MAA04749; Thu, 16 May 1996 12:25:06 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id MAA15918; Thu, 16 May 1996 12:25:05 -0700 (PDT) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Thu, 16 May 96 12:25:05 PDT Date: Thu, 16 May 96 12:23:00 PDT From: Will Hobbs Message-ID: To: uunet!qdt.com!jonp@uunet.uu.net, uunet!uunet!ccm.jf.intel.com!Will_Hobbs@uunet.uu.net cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re[2]: IBIS Face-to-face meeting at DAC, Friday, 6/8 Text item: Jon> Friday is June 7. Picky, picky. Friday, June 7 is our meeting. Thanks, Jon. Will Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: IBIS Face-to-face meeting at DAC, Friday, 6/8 In-Reply-To: (uunet!ccm.jf.inte l.com!Will_Hobbs) Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net To: uunet!uunet!ccm.jf.intel.com!Will_Hobbs@uunet.uu.net Received: by f14.qdt.com (4.1/SMI-4.1) id AA00445; Thu, 16 May 96 06:35:14 PDT Message-Id: <9605161335.AA14868@hal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Thu, 16 May 96 06:35:17 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA14868; Thu, 16 May 96 06:35:17 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00663; Thu, 16 May 96 06:35:17 PDT Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 16 May 1996 10:01:42 -0400 Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQapym27963; Thu, 16 May 1996 10:01:40 -0400 (EDT) Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA15334; Thu, 16 May 96 07:08:14 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00707; Thu, 16 May 96 07:08:14 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Thu, 16 May 1996 10:31:57 -0400 Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQapyo06531; Thu, 16 May 1996 10:31:55 -0400 (EDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id HAA20506 for ; Thu, 16 May 1996 07:34:26 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id HAA27830 for ; Thu, 16 May 1996 07:34:27 -0700 (PDT) Return-Path: uunet!qdt.com!jonp@uunet.uu.net From owner-ibis Fri May 17 10:35:46 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA19514 for ; Fri, 17 May 1996 10:34:28 -0700 (PDT) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 17 May 96 10:24 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 17 May 96 10:27 PDT Message-Id: Date: Fri, 17 May 96 10:27 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Forwarded: vhdl.org will be down this weekend To All: This means that vhdl.org, which is physically located at Synopsys, will not have IBIS or other Web Links, E-mail and FTP access this weekend. So do whatever communication and access before 6 PM PDT (1:00 GMT) or wait until Monday to avoid bounced messages and failed access. Bob Ross, Interconnectix, Inc. Date: Fri, 17 May 96 09:49:11 PDT From: wyle@Synopsys.COM (Mitch Wyle) To: all-accounts@vhdl.org, support@vhdl.org Subject: vhdl.org will be down this weekend NO COMPUTING SERVICES AVAILABLE FROM 6 P.M. MAY 17 TO 8 A.M. MAY 20 IN MOUNTAIN VIEW It's time for the regularly scheduled NCS quarterly downtime for preventive maintenance. NCS will take the campus computing resources down for necessary reconfiguration, testing, expansion, and general catching-up-on work that can't be done with the machines running. This downtime will mean that no campus computing resources will be available from 6 p.m. Friday, May 17, until 8 a.m. Monday, May 20. (All times are PDT.) For future reference, the following are our Preventive Maintenance scheduled activity dates: May 18-19, 1996 <------ NEXT Aug 24-25, 1996 Nov 16-17, 1996 --Bryan Stansell Computing Systems Network & Computing Services -------- End of Forwarded Message From owner-ibis Sat May 18 12:04:55 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA06941 for ; Sat, 18 May 1996 12:04:55 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA16947 for ; Sat, 18 May 1996 11:58:24 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma016939; Sat May 18 11:58:05 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA16455 for ibis@vhdl.org; Sat, 18 May 96 11:55:12 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA15864; Sat, 18 May 96 11:58:06 PDT Date: Sat, 18 May 96 11:58:06 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9605181858.AA15864@rockie.nsc.com> To: ibis@vhdl.org Subject: National releases RTC IBIS model Cc: huq@rockie.nsc.com IBIS fans, National Semiconductor has released the following RTC(Real Time Clock) IBIS model today. This is available from our web site at: http://www.national.com dp8573an.ibs Real Time Clock National Semiconductor provides IBISv1.1 and IBISv2.1 models from selected product lines. Refer to www.national.com for the lastest available models. National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. Regards, Syed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Syed B. Huq huq@rockie.nsc.com ~ ~ National Semiconductor Corp. ~ ~ Tel:(408)721-4874; Fax:(408)721-4785 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ibis Tue May 21 14:40:47 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA25361 for ; Tue, 21 May 1996 14:40:38 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 21 May 96 14:31 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 21 May 96 14:31 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 21 May 96 14:33 PDT Message-Id: Date: Tue, 21 May 96 14:33 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Minutes 5/17/96 DATE: May 21, 1996 SUBJECT: 5/17/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann*, Tim Minnick* Cadence Design C. Kumar* Contec CAE, Ltd. Dileep Divekar*, Norio Matsui Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli* INCASES Olaf Rethmeier Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, Donald Telian, Jim Kruchowski Interconnectix, Inc. Bob Ross* Meta-Software (Les Spruiell) Mitsubushi Tam Cao Motorola Ahmed Omer* National Semiconductor Syed Huq*, Donald Snyder, Chune-Sin Yeh NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell*, Chris Rokusek* Quantic Labs (Mike Ventham) Tanner Research, Inc. (Scott Wedge) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu* EIA Patti Rusher IC Works Eric Chen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo* Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison Veribest/Integraph Ian Dodd, David Wiens Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 6/7/96 (916) 356-9200 1-77607 8892397 Las Vegas, NV., 9:00 A.M. to 1:00 P.M. All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Tim Minnick is working with Hank Herrmann at AMP on producing IBIS Connector Models. Mike Magdaluyo of Philips Semiconductor's Logic Products Group has been involved with Philips Spice Models and is researching IBIS models with the expectation of producing them in the future. EIA MEMBERSHIP AND TREASURER'S REPORT Bob Ross reported no treasury change. Bob is still researching with Patti Rusher membership payments. The account is $9,988.59 minus some DAC expenses for the meeting and awards. Jeff Chu needs to follow up with EIA concerning Digital Equipment membership payment. Bob will contact Jon Powell concerning who are official members for a possible IBIS member company poster update. A polling of companies indicated that NCR, Intel, and Contec have paid their membership even though the EIA records may not indicate payment. AR - Bob Ross continue working with Patti Rusher regarding membership payment issues. MINUTES REPORT, MISC. No Corrections. Bob Ross review all ARs. Except for publishing the EDIF letter ballot comment, all ARs have been completed or handled by alternative action. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Sigrity reports support of IBIS models on page 120 in the April 29, 1996 issue of Electronic Engineering Times. NEW MODELS The Intel Web site http://www.intel.com has additional IBIS models available from the Chandler, Arizona division. They can be accessed with SEARCH (small letters at the top of the home page) on IBIS. They consist of some flash memory and i960 components. OPENS FOR NEW ISSUES Will Hobbs for Ramp discussion (not discussed) Bob Ross for BIRD35 (not discussed) DAC STANDARDS BOOTH Jon Powell reported that Patti Rusher is handling the IBIS visuals for the EIA booth at DAC. Bob Ross has supplied the IBIS bullet items to be used with the display. Jon Powell will generate additional IBIS Spoken Here signs and will distribute them at DAC on the floor. See Jon at the Quad Design booth if you need signs. They will have stands (as opposed to Velcro backing). Jon Powell also generated 50 "I Like IBIS" buttons and sent one to Bob Ross and Will Hobbs. They will also be available at DAC. DAC (DESIGN AUTOMATION CONFERENCE) MEETING ARRANGEMENTS AND AGENDA The Standards Roadmap Birds of the Feather Meeting by Ron Werner of Motorola on Thursday, June 6, 1996 between 6 PM and 8 PM may provide an opportunity to comment on the Roadmap. We decided not to do our own BOF session because IBIS is now quite well-known. EIA/IBIS MEETING Will Hobbs indicated that the EIA/IBIS Face to Face meeting will be at the Las Vegas Hilton Hotel between 9 AM and 1 PM. Arrive early for refreshments. Election of new officers (nominations on the floor), awards, and other administrative issues will be handled. Unlike other DAC meetings, some technical issues will also be discussed. Several people wanted unity and closure of the package/mated-model issue as the primary technical issue. AR - Stephen Peters on behalf of the Package Committee prepare a presentation and provide a recommended format. To ensure that representatives who have major interests in this issue can participate, even though they may not be able to attend DAC, a phone bridge will be established. AR - Bob Ross get phone bridge number to publish in Agenda, and contact Patti Rusher to get a speaker phone in the meeting room Bob Ross polled and estimate that about 10 people who were at this meeting will be at DAC. AR - Anyone, contact Will Hobbs if you are attending the EIA/IBIS Summit. GOLDEN PARSER UPDATE Thanks to Chris Rokusek for providing the parser executables. Bob Ross checked out the fixes, and the executables are now on vhdl.org under /pub/ibis/ibischk2. Kellee Crisafulli stated that winibis will be upgraded with the new parser. He also reported that the parser issues an ERROR if there are too many pins, as in the Motorola Power PC 620. Bob Ross will investigate. (After the meeting, Bob checked this and found that a the error occurs when a Version 1.1 IBIS file is tested. This error does not occur for Version 2.1 IBIS files. So this is a limitation in the original ibis_chk program which is embedded within ibischk2. One solution is to change the [IBIS Ver] to 2.1, even for 1.1 files. This will also give addtional tests.) SPICE TO IBIS VERSION 2.1 Bob Ross reported that Alan Glaser is spending several weeks a s2ibis2.1 upgrade. Bob reported another crash with respect to table generation for ECL devices based on wrong ranges, and then a segment fault when these Spice outputs are used to generate the IBIS file due to memory overrun errors. (Based on a discussion after the meeting, Alan is still working on problems and interface upgrades. He may take several more weeks. He requests input from anyone on problems and improvements.) AR - Bob Ross continue to work with Alan Glaser concerning the s2ibis2.1 upgrade. EXPRESS INFORMATION MODEL ACTIONS Since last meeting, Olaf Rethmeier reported on an existing Express Model for IBIS 2.0 done in June 1994. Since IBIS has had minimal technical changes from that point to ANSI/EIA-656 (IBIS Version 2.1), this format is still very close to the current version. Bob Ross has discovered only a few minor errors such as specifying integers for revision numbers. Bob has committed to providing a technical review and upgrade resulting in a good starting point for an Express representation for IBIS Version 2.1. Kellee Crisafulli raised some questions on whether there was a reader or way of testing the Express representation. We did not know the answer. IBIS COMMENTS ON EDIF 3 9 9 The AR for David Wiens to provide formal comment on behalf of the IBIS Committee on EDIF 3 9 9 and publish them on the IBIS reflector still needs to be done. AR - Stephen Peters work with David Wiens on the comment and publish it on the IBIS reflector as soon a possible. The primary issues are to add within EDIF a reference to IBIS components and to be able to store and retrieve passive (R, L, C) component electrical values. Bob Ross will also provide an Interconnectix comment for these concerns. Bob will work with Kellee Crisafulli to get a better understanding of this issue before formulating a response. EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING Chris Rokusek covered the contents of EGG10 proposed a while ago. A set of ibischk2 tests are proposed to check the validity of model data and to issue warning messages for questionable contents. (1) Polarity test. Bob Ross indicated that ibischk2 already has a good polarity test, so this may already be covered. (2) Checking Waveform table endpoints. This looks like a good test. Bob indicated that the test should included the contributions of the clamp tables since it is possible that there may be internal "pullup resistors" or "pulldown resistors". Warnings should not be issued for correct IBIS data. (3) Warning for large diode currents. Excessively large currents around 1 V to 1.5 V in the order of amps are too large and may indicate a units problem. Chris will examine all of the IBIS files to see if there is a reasonable large test current at, say, 1 V or 1.5 V in the order of 1 A 100 A which could be used to trigger a warning message. (4) Abrupt slopes. The intent is to trap discontinuities and also to issue warnings if there are abrupt changes such as with a 3-point diode model. The test would be based on a second derivative limit. Kellee Crisafulli. indicated that this would not be a problem for some simulators. Also, some noisy models obtained from measurement may have noise. So there are still open issues on this test. (5) Stephen Peters added a component value reality test for C, L, and R components and also for the dV/dt values. Arpad Muranyi suggested that identical dt's would indicate that the incorrect "reduced" ramp rate ratio was used. Bob Ross wanted the test to be based on actual values, and not on just the units since ibischk2 already does polarity testing based on actual values. Some possible upper limits might be C = 1 uF L = 1 mH, and R, no limit. However, testing for an R value greater than 1 M may reveal a units problem when milliohms was intended. Stephen expected that the terminator keyword R/C components would not be tested. Bob added that this set of tests might be part of the model validation process that we have been discussing. BIRD31.3 - MATED MODELS Bob Ross discussed only the latest change making the Tedge_rate parameter optional based on the fact that the Tedge_rate = 0 discussion was functionally the same thing. Stephen Peters proposed using "0" to indicate DC usage guarantee only, rather than very small rise time. Hank Herrmann would still like to make this parameter a required parameter. The discussion then was about whether one section was to be assumed a discrete L/C section or could be a transmission line segment. Stephen Peters said that BIRD28.3 presumes that if Len = 0, it is for a discrete section, and a non-zero length creates a distributed element. C. Kumar and others representation simulator companies preferred the distributed representation basis since those simulators which use discrete elements can estimate the number of sections based on actual edge_rate requirement. One suggestion was to use Z0 and delay for clarity for distributed sections. This discussion was tabled to move on to the related package discussion. PACKAGE COMMITTEE DISCUSSION Stephen Peters reported that the package committee had three fundamental approaches to electrical representation: a segment approach from Jon Powell, a Spice like nodal approach from C. Kumar, and a BIRD28.3 extension from Stephen Peters. The committee decided not to deal with the submatrix issue because it opened up some issues regarding reference planes and format preferences that needed more time to resolve. The main focus from Steven will be to examine extensions for nodes, forks, etc., and to possibly to come up with a format that includes mated models. As already indicated, Stephen plans to have a proposal for discussion at the DAC meeting. BIRD34.1 - HANDLING STORED CHARGE Not discussed. NEW ITEMS Not discussed. NEXT MEETING: The next meeting is at DAC, Friday, June 7, 1996 9:00 A.M. to 1:00 P.M., at the Las Vegas Hilton adjacent to the Las Vegas Convention Center. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Server Chipset System Validation Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Thu May 23 09:43:54 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA26511 for ; Thu, 23 May 1996 09:43:53 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id JAA23778; Thu, 23 May 1996 09:33:35 -0700 (PDT) Received: from xtg801.intel.com by ichips.intel.com (8.7.4/jIII) id JAA04978; Thu, 23 May 1996 09:32:37 -0700 (PDT) Received: from localhost by xtg801.intel.com (4.1/SW1.11) id AA22989; Thu, 23 May 96 09:33:33 PDT Message-Id: <9605231633.AA22989@xtg801.intel.com> To: dawiens@ingr.com Cc: ibis@vhdl.org Subject: RE: IBIS comments to the EDIF committee Date: Thu, 23 May 1996 09:33:32 -0700 From: Stephen Peters Hello David: Regarding your questions below I'm going to give you my interpretation, but I think the simulator vendor folks need to give you the final word. 1. Yes, an IBIS file should be associated with a 'part' rather than each component instance. 2. The RLC values we are talking about refer to descrete components. A board my have descrete resistor, capacitor and inductor components connected as part of a net. The simulator vendors must have a way to clearly and uniquely extract from the EDIF description the values of these components (i.e. 50 ohms, 20pF). Stephen > On Thu, 23 May 1996 11:06:10 David Wiens wrote: Stephen, In working up the EDIF proposal, I came up with a few things I want run past you... 1. In EDIF, a 'component' is an instance of a 'part'. Given the choice, I'm assuming we want to attach IBIS models to parts, not components. 2. Regarding the issue of one location for RLC values... - There aren't ANY places I can find within EDIF that define RLC, so the only way to add them would be using the 'property' name/value type. Unfortunately, this can be done under about any element type. - The real point I'm missing is why we care about RLCs within EDIF if we can properly point at IBIS and get them there for package and die pins. David Wiens From owner-ibis Thu May 23 09:56:16 1996 Received: from alcatel.fr (gatekeeper.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA26593 for ; Thu, 23 May 1996 09:56:14 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id RAA03375 for ; Thu, 23 May 1996 17:48:35 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id SAA28341 for ; Thu, 23 May 1996 18:46:55 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA18981; Thu, 23 May 96 18:46:59 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01001; Thu, 23 May 96 18:46:56 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <31A4967F.62319AC4@ln.cit.alcatel.fr> Date: Thu, 23 May 1996 18:46:55 +0200 From: FITZPATRICK John Organization: Alcatel CIT, 22304 Lannion, France X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Egg : Absolute Maximum Ratings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS mailing list: Below is a proposal to include absolute maximum rating in an IBIS model. The key elements are: i) A new keyword [Maximum Voltage] is added ii) A table is given of the maximum voltage as a function of time Two examples are given to explain why this information might be useful to a board designer. Unfortunately, I'm not an expert on what the physical reasons for the maximum applied voltage are, so I would be very grateful for any comments from component designers on the following statements: a) Most often suppliers say the limit is latchup, requiring current limitation. Does anyone have typical latch-up current vs. time curves? b) I was once told that the limit was the amount of reverse current in the power rings, and that the max current depended on the no. or power pins and no. of buffers in question! c) I also understand that the the finer the technology, the less its tolerance to higher voltages. So, for example, even without clamping diodes to Vcc, it may not be possible to make a 2.5V buffer which is 5V-TTL compatible. I look forward to your comments, Regards, John -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 To IBIS mailing list: *********************************************************************** BIRD ID#: NA ISSUE TITLE: Absolute Maximum Voltage REQUESTER: John Fitzpatrick, Alcatel DATE SUBMITTED: May 20, 1996 DATE ACCEPTED BY IBIS OPEN FORUM: NA *********************************************************************** STATEMENT OF THE ISSUE: IBIS can be extended to allow a component supplier specify the absolute maximum voltages and currents that can be applied to an I/O buffer. These limits should be expressible as a function of time to give maximum flexibility to board designers. Note: Because IBIS simulation data is provided from -Vcc to 2Vcc, a non-specialist might wrongly believe that there are no absolute maximum limits. *********************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Add the following keyword after the [Model] keyword: |===================================================================== | Keywords: [Maximum Voltage] | Required: Yes, unless the component works for all simulation points | Description: Defines the extreme positive and negative voltages | that can safely be applied to an I/O buffer. | Sub-params: POWER_Clamp_Reference, Pullup_Reference | Usage Rules: This keyword defines a table of voltage versus time points. | There are four voltages: positive (above POWER) and negative | (below GND) voltages for 3-state and active(low impedance) | state. | Entries for active state are included only if the limits | are different than in 3-state. | Negative voltage are referenced to GND. | Positive voltages are given in the form: | V = Vapplied - Vcc if POWER_Clamp_Reference=yes | or | V = Vapplied if POWER_Clamp_Reference=no | The last entries in the table are the static absolute maximum | voltages. When a waveform exceeds a static voltage, the | simulator will set time=0, then check that the rest of the | waveform is within the dynamic limits given in the table. | | Other Notes: The I/V curves [Pullup], [POWER Clamp], [Pulldown] and | [GND Clamp] are used to calculate the input impedance, | and hence the absolute maximum currents. | If the component supplier wishes to specify the absolute maximum | current, he must calculate the corresponding maximum voltage. | | When specifying limits, the component supplier might take | into account the following situations where the static | maximum ratings will be exceeded: | | 1) Reflections: | - An over- or undershoot can last for up to 20ns (?) | - If there are no clamping diodes, the buffer should | tolerate applied voltages from -Vcc to 2Vcc (CMOS buffer) | - If there are clamping diodes, the buffer should tolerate | applied currents from -Vcc/Z to 2Vcc/Z (CMOS buffer), | where Z is the track impedance. Usually Z > 40 ohms. | | 2) Power supply failure | - In a multi-supply design (e.g. mixed 5V/3V bus), a | buffer should tolerate excess applied voltages(dV) | and currents(I) from the time its power supply fails until | all connected outputs are disabled (time Tfail later). | Tfail < 50us (Latchup is faster?) | I < 250mA (?) | dV < 3.3V (?) (e.g. 5V buffer on mixed 5V/3V bus) | | Note: The simulator will assume that the section of the | [POWER clamp] table above Vcc can be used (shifted?) for all | values of supply voltage from 0 to Vcc. | | The example below could represent a CMOS output, with a | permanent clamping diode to GND, and a clamping diode to | Vcc in active state only: | [Maximum Voltage] | Pullup_reference=yes POWER_clamp_reference=no | | Time Vpos(3-state) Vneg(3-state) Vpos(active) Vneg(active) 0 7 -2 2 -2 20ns 7 -2 2 -2 30ns 5.5 -1.5 1.5 -1.5 50us NA -1 1 -1 100us 5.5 -0.5 0.5 -0.5 | *********************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The manner in which absolute maximum ratings are given in paper databooks is extremely conservative. Typically, the board designer is expected to guarantee that the voltage V applied to a buffer be in the range -0.5V < V < Vcc+0.5V. (*) Most board designers know that these limits are often exceeded in their designs due to reflections, without any harm being done to the component. They would however like to have real risks flagged by a simulator. In multiple power supply designs (e.g. mixed 3.3V/5V), it is possible to have "5V tolerant" 3.3V buffers. But what happens if one of the power supply fails? The designer would like to know if it is sufficient to disable all output buffers, and if so, within what time-frame. Some suppliers specify the absolute max voltage as a function of Vcc, others tolerate any voltage up to a limit (usually 7V), even if Vcc is set to 0V. The sub-parameter POWER_Clamp_Reference allows this distinction to be taken into account. Some 3.3V CMOS components (e.g. 74LVCxxx, 74LCXxxx) have output clamping diodes in the active state only. Optional columns are included to allow this fact be taken into account. This proposal is simply an extension of the existing absolute maximum ratings, with the additional parameter: time. Any supplier who wishes to be "customer-unfriendly" by continuing to specify (*) can write: [Maximum Voltage] | POWER_clamp_reference=yes | | Time Vpos(3-state) Vneg(3-state) 0 0.5 -0.5 Remarks: 1) Should there be an optional keyword [Maximum Current] which could replace [Maximum Voltage] if the component supplier prefers to specify maximum current rather than maximum voltage. This would shift the burden of applying Ohms' Law to the simulator. 2) Many of the figures above are rough estimations or educated guesses. Feedback from component designers is needed. *********************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD has been inspired by the PCI bus specification. The relevant references are (Rev 2.0): 4.2.1.3 Maximum AC ratings and Device Protection (5V) 4.2.2.3 Maximum AC ratings and Device Protection (3.3V) 4.3.2 Reset *********************************************************************** From owner-ibis Thu May 23 10:09:20 1996 Received: from ingr.ingr.com (ingr.ingr.com [129.135.211.100]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA26713 for ; Thu, 23 May 1996 10:09:09 -0700 (PDT) Received: from hq15.pcmail.ingr.com by ingr.ingr.com (5.65c/1.920611) id AA18989; Thu, 23 May 1996 11:59:04 -0500 Received: by hq15.pcmail.ingr.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB489F.48FAB350@hq15.pcmail.ingr.com>; Thu, 23 May 1996 11:59:24 -0500 Message-Id: From: "Wiens, David" To: Stephen Peters Cc: "ibis@vhdl.org" Subject: RE: IBIS comments to the EDIF committee Date: Thu, 23 May 1996 11:58:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 71 TEXT Stephen, You're correct about RLCs for discretes...I had active parts on the brain for some reason. I will propose a location for storage of these values, since there isn't one now. Is there anything else other than the following that would possibly need to be described for a 'physical' netlist : - active model (IBIS link) - passive model (RLC values in EDIF) - physical topology (layers, traces/vias, part geometries, etc. in EDIF) Note that we don't have to be all-inclusive here...but if we don't get something into the spec now we will end up adding generic name/value properties that we can't require anyone to recognize. David Wiens >---------- >From: Stephen Peters[SMTP:speters@ichips.intel.com] >Sent: Thursday, May 23, 1996 10:33 AM >To: Wiens, David >Cc: ibis@vhdl.org >Subject: RE: IBIS comments to the EDIF committee > >Hello David: > > Regarding your questions below I'm going to give you >my interpretation, but I think the simulator vendor folks >need to give you the final word. > > 1. Yes, an IBIS file should be associated with a 'part' rather >than each component instance. > > 2. The RLC values we are talking about refer to descrete components. >A board my have descrete resistor, capacitor and inductor components >connected as part of a net. The simulator vendors must have a way to >clearly and uniquely extract from the EDIF description the values of >these components (i.e. 50 ohms, 20pF). > > Stephen > > > >> On Thu, 23 May 1996 11:06:10 David Wiens wrote: > >Stephen, > >In working up the EDIF proposal, I came up with a few things I want run >past you... > >1. In EDIF, a 'component' is an instance of a 'part'. Given the choice, >I'm assuming we want to attach IBIS models to parts, not components. > >2. Regarding the issue of one location for RLC values... > - There aren't ANY places I can find within EDIF that define RLC, >so > the only way to add them would be using the 'property' name/value >type. > Unfortunately, this can > be done under about any element type. > - The real point I'm missing is why we care about RLCs within EDIF > if we can properly point at IBIS and get them there for package >and die > pins. > >David Wiens > From owner-ibis Thu May 23 10:27:28 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA26823 for ; Thu, 23 May 1996 10:27:27 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id KAA07787; Thu, 23 May 1996 10:16:50 -0700 (PDT) Received: from xtg801.intel.com by ichips.intel.com (8.7.4/jIII) id KAA09558; Thu, 23 May 1996 10:15:40 -0700 (PDT) Received: from localhost by xtg801.intel.com (4.1/SW1.11) id AA24143; Thu, 23 May 96 10:16:37 PDT Message-Id: <9605231716.AA24143@xtg801.intel.com> To: dawiens@ingr.com Cc: ibis@vhdl.org Subject: RE: IBIS comments to the EDIF committee Date: Thu, 23 May 1996 10:16:36 -0700 From: Stephen Peters Hello David: Yes, that looks like the major points. Thanks again for your effort in getting comments back to the EDIF committee. Regards, Stephen Stephen, You're correct about RLCs for discretes...I had active parts on the brain for some reason. I will propose a location for storage of these values, since there isn't one now. Is there anything else other than the following that would possibly need to be described for a 'physical' netlist : - active model (IBIS link) - passive model (RLC values in EDIF) - physical topology (layers, traces/vias, part geometries, etc. in EDIF) Note that we don't have to be all-inclusive here...but if we don't get something into the spec now we will end up adding generic name/value properties that we can't require anyone to recognize. David Wiens >---------- >From: Stephen Peters[SMTP:speters@ichips.intel.com] >Sent: Thursday, May 23, 1996 10:33 AM >To: Wiens, David >Cc: ibis@vhdl.org >Subject: RE: IBIS comments to the EDIF committee > >Hello David: > > Regarding your questions below I'm going to give you >my interpretation, but I think the simulator vendor folks >need to give you the final word. > > 1. Yes, an IBIS file should be associated with a 'part' rather >than each component instance. > > 2. The RLC values we are talking about refer to descrete components. >A board my have descrete resistor, capacitor and inductor components >connected as part of a net. The simulator vendors must have a way to >clearly and uniquely extract from the EDIF description the values of >these components (i.e. 50 ohms, 20pF). > > Stephen > > > >> On Thu, 23 May 1996 11:06:10 David Wiens wrote: > >Stephen, > >In working up the EDIF proposal, I came up with a few things I want run >past you... > >1. In EDIF, a 'component' is an instance of a 'part'. Given the choice, >I'm assuming we want to attach IBIS models to parts, not components. > >2. Regarding the issue of one location for RLC values... > - There aren't ANY places I can find within EDIF that define RLC, >so > the only way to add them would be using the 'property' name/value >type. > Unfortunately, this can > be done under about any element type. > - The real point I'm missing is why we care about RLCs within EDIF > if we can properly point at IBIS and get them there for package >and die > pins. > >David Wiens > From owner-ibis Thu May 23 13:17:46 1996 Received: from ingr.ingr.com (ingr.ingr.com [129.135.211.100]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA28138 for ; Thu, 23 May 1996 13:16:37 -0700 (PDT) Received: from hq15.pcmail.ingr.com by ingr.ingr.com (5.65c/1.920611) id AA06758; Thu, 23 May 1996 15:06:33 -0500 Received: by hq15.pcmail.ingr.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB48B9.78208F50@hq15.pcmail.ingr.com>; Thu, 23 May 1996 15:06:50 -0500 Message-Id: From: "Wiens, David" To: "edif-support@edif.org" Cc: "prusher@eia.org" , "ibis@vhdl.org" Subject: Response to EDIF 3 9 9 proposal from the IBIS Open Forum Date: Thu, 23 May 1996 15:07:30 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 47 TEXT To the EDIF Technical Experts Group : The IBIS Open Forum has reviewed the EDIF 3 9 9 proposed standard for use in data transfer between CAD layout and signal integrity simulation tools. We need to be able to transfer the following data : 1. Physical topology 2. Active part data 3. Passive part data We have concluded that the current EDIF proposal more than adequately supports our needs for physical topology definition. However, the following issues were raised by the group : 1. To support active parts, we need a link to an IBIS model description. We request consideration of IBIS model files as External Libraries, with the pointer to them residing in the EDIF 'Part' type. IBIS models are referenced by component name, and more than one model can reside in one IBIS file, but multiple files may also be used. We are not requesting that the IBIS format be considered as a subset of EDIF. 2. To support passive parts, we need values for resistance, capacitance, and inductance in the EDIF 'Part' type. All or none of these values may exist for a part. While we understand that these issues can probably be solved using name/value 'Properties' types, we request that they be added to the specification to avoid misinterpretations during translation. Thank you for your consideration of these issues. This request will also be submitted to the EIA on paper per EIA procedures. For further information, please contact : - Stephen Peters (speters@ichips.intel.com) - David Wiens (dawiens@veribest.com) From owner-ibis Thu May 30 14:35:32 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA20837 for ; Thu, 30 May 1996 14:35:30 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 30 May 96 14:26 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 30 May 96 14:26 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 30 May 96 14:28 PDT Message-Id: Date: Thu, 30 May 96 14:28 PDT From: bob@icx.com ( Bob Ross) To: alanrw@cs.man.ac.uk, hkahn@cs.man.ac.uk Subject: REVIEW - INFORMATION MODEL OF IBIS Cc: ibis@vhdl.org Alan Williams and Hilary Kahn Department of Computer Science University of Manchester Subject: Comments on Version 0.1 Information Model of I/O Buffer Specification (IBIS) Version 2.0 Alan and Hilary: Attached are my review comments of the above document. In general, you have provided an excellent document which can be used for an ANSI/EIA-656 (IBIS Version 2.1) information model. Several comments relate to the Version 2.1 additions. Feel free to contact me. We may need to clarify some other points which I may have missed. Bob Ross Interconnectix, Inc. (Secretary, EIA/IBIS Subcommittee) Title Page: Change Version 2.0 to 2.1 and make reference to ANSI/EIA-656. Page 5: Change Version 2.0 to 2.1. 1.0 Introduction: Rewrite sentence to read: "This document contains an information model of the I/O Buffer Specification (IBIS) Version 2.1, also known as ANSI/EIA-656." Page 6: 2.0 Component UoF What does "UoF" mean? I am not familiar with the Information model conventions and I did not see it defined. Page 9, Lines 195-206: Line 198: revision : STRING (This should follow Line 195 since it is the first required keyword in an IBIS file. While 1.0, 1.1, 2.0, 2.1 are current legal arguments, the argument may be a string such as 2.1.1 or 2.1a.) Line 199: date : OPTIONAL STRING (40) Add: After Line 203: copyright : STRING Note, source, notes, disclaimer, and copyright can be multi-lined strings. All strings must not exceed either the stated maximum length or must not extend beyond the 80th character for each line. Delete lines 204-206: revision is a STRING Line 197: status is also a STRING. While an enumeration is recommended, the actual argment syntax is arbitrary and for information only. Page 10, Lines 228-238: After line 227, the [Model Data] and [End Model Data] Syntax is not included. I presume that because this is used for syntactical bracketing, it is not needed for the information model. Question: Do all keywords and subparameters within the IBIS Specification have to have some informational representation? Line 230: The resistance_matrix is optional. Lines 237-238: Perhaps matrix_size should be max_matrix_size since several formats allow storing the data in more concise forms. Page12, Line 310: What does not_yet_defined refer to? Page 14, Lines 485 and 486 should be OPTIONAL After Line 486 Add for Vref: reference_voltage: OPTIONAL voltage_value Page 17, Line 563: capacitance_value should be REAL. Its value within a Capacitance matrix on Page 10, Lines 232, and 257 can be mostly negative. Line 599: inductance_value should be REAL for a similar reason. Page 19, Line 715-716: Non-monotonic tables are permitted. A parser warning will be given. I do not know what not_yet_defined means. Page 20, Add after Line 763 (A Version 2.1 addition): fixture_voltage_min : voltage_value fixture_voltage_max : voltage_value Page 21, Glossary 8.0: Change Version 2.0 to Version 2.1 8.1: Change sub-parameter to subparameter throughout since this was changed in the Version 2.1 specification. 8.2: Regarding the question concerning sub-typing the "bus" entity, the bus implies that all voltage sources on the same bus are physically CONNECTED and all other models that have models ASSOCIATED with that bus use that particular connected voltage source. I do not know whether this implies a sub-type relationship, but I think it should. 8.5: Capatilize c in [Component] 8.6: The current_range does not always require numerical values in the typical column. The typical table itself must contain a minimal amount of numerical data, whereas the min and max columns may contain no numerical data. So the nomenclature might be changed to table_current_range. Page 25, 8.33: The pin_differential ASSOCIATES two pins and adds differential voltage and relative time delay specifications. Should this also be a sub-type relationship? 8.37-8.39 pin_to_pin_capacitance and pin_to_pin_inductance can also include capacitance to global ground and self inductance. The definition may need to be expanded. 8.39: pin_to_pin resistance is the resistance associated with each pin of a circuit with two package_pins. Page 28, 8.60 A waveform consists of "table_voltage_ranges" because the typical value is not always required. However, similar to 8.6, the typical column must contain a minimal amount of numerical data, whereas the min and max columns may contain no numerical data. This is similar to 8.6. Pages 31-42 Attribute Summary As a general comment, this table is technically correct because attributes may be associated with names even if they provide no functionality. For example, the ac_terminator_pin_model and all input models will disregard the pullup, pulldown, falling_waveforms, rising_waveforms, and has_ramp attributes and several others. From owner-ibis Fri May 31 09:57:47 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA06039 for ; Fri, 31 May 1996 09:57:42 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 31 May 96 09:48 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 31 May 96 09:48 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 31 May 96 09:50 PDT Message-Id: Date: Fri, 31 May 96 09:50 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: AGENDA - 6/7/96 SUMMIT MEETING IBIS Open Forum Meeting Agenda for 6/7/96 Bridge Number Reservation # Passcode (916) 356-9200 1-77607 8892397 Las Vegas, NV., 9:00 A.M. to 1:00 P.M. This meeting is 9:00 AM to 1: 00 PM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:30 Refeshments All 9:00 Check-In, Intros, Announcements (Phone-In) Hobbs - Intros of IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Ross/Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates All - New Models Available, Library Update All - Opens for New Issues All 9:15 EIA Awards Rusher 9:30 Election of EIA/IBIS Officers 1996-1997 Hobbs Chair Vice-Chair Secretary Librarian 10:00 Technical Discussions PACKAGE/CONNECTOR/PCB-MODULE EXTENSIONS DISCUSSION: (CONSOLIDATION/AGREEMENT/CLOSURE) Peters/All BIRD36 - (Pending Package Committee Proposal) BIRD31.3 - Mated Models BIRD32 - Additional Enhancement to the Package Model BIRD33 - Physical Package Description (resolved - EDIF) 11:00 Break 11:15 Technical Discussions Continued PACKAGE/CONNECTOR/PCB-MODULE (Continued) 12:00 Other Technical Issues (Time Permitting) BIRD35 - Multi-Stagged Outputs Ross BIRD34.1 - Stored Charge Proposal Progress Ross EGG10 - PARSER TESTS 1-5 Rokusek/Peters New Technical Issues All 12:55 Wrap Up and Next Meetings Plans Hobbs 1:00: Sign Off and Goodbye