From katz@blazng.enet.dec.com Mon May 2 05:32:28 1994 Return-Path: Received: from inet-gw-2.pa.dec.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00124; Mon, 2 May 94 05:32:28 PDT Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA11350; Mon, 2 May 94 05:24:19 -0700 Received: from blazng.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA18560; Mon, 2 May 94 08:24:32 -0400 Message-Id: <9405021224.AA18560@us1rmc.bb.dec.com> Received: from blazng.enet; by us1rmc.enet; Mon, 2 May 94 08:24:35 EDT Date: Mon, 2 May 94 08:24:35 EDT From: Barry Katz To: ibis@vhdl.org Cc: katz@decsim.enet.dec.com Apparently-To: ibis@vhdl.org, katz@decsim.enet.dec.com Subject: Re: BIRD 12.1 Steve, Great work! My only comment is on the figure. I believe the R_fixture and L_fixture should be in series as is shown below. Comments? Barry- *** Proposed Change **** | | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | \/ | | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | *** What you have **** | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | | \/ | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | From katz@blazng.enet.dec.com Mon May 2 06:14:47 1994 Return-Path: Received: from inet-gw-2.pa.dec.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00379; Mon, 2 May 94 06:14:47 PDT Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA13287; Mon, 2 May 94 06:01:02 -0700 Received: from blazng.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA19657; Mon, 2 May 94 08:59:32 -0400 Message-Id: <9405021259.AA19657@us1rmc.bb.dec.com> Received: from blazng.enet; by us1rmc.enet; Mon, 2 May 94 08:59:40 EDT Date: Mon, 2 May 94 08:59:40 EDT From: Barry Katz To: ibis@vhdl.org Apparently-To: ibis@vhdl.org Subject: Re: BIRD 12.1 Steve, Great work! My only comment is on the figure. I believe the R_fixture and L_fixture should be in series as is shown below. Comments? Barry- *** Proposed Change **** | | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | \/ | | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | *** What you have **** | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | | \/ | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | From speters@ichips.intel.com Mon May 2 08:43:32 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01577; Mon, 2 May 94 08:43:32 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 2 May 94 08:40:37 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 2 May 94 08:40:16 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 2 May 94 08:40:31 PDT Message-Id: <9405021540.AA07044@xtg801.intel.com> To: katz@blazng.enet.dec.com Cc: ibis@vhdl.org Subject: Re[1]: BIRD 12.1 Date: Mon, 02 May 1994 08:40:29 -0700 From: Stephen Peters Hello Barry -- Thanks for your comment. The reason the C_fixture is between the R and L is so that one could duplicate the standard 500 ohm, 50pf data book test load. Regards, Stephen Peters Steve, Great work! My only comment is on the figure. I believe the R_fixture and L_fixture should be in series as is shown below. Comments? Barry- *** Proposed Change **** | | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | \/ | | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | *** What you have **** | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | | \/ | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | From intgrty!phil@kksys.com Mon May 2 13:11:55 1994 Return-Path: Received: from kksys.skypoint.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03872; Mon, 2 May 94 13:11:55 PDT Received: by kksys.skypoint.net (Smail3.1.28.1 #15) id m0py49m-0006ZAC; Mon, 2 May 94 14:59 CDT Received: by intgrty.intgrty.mn.org (4.1/SMI-4.1) id AA13127; Mon, 2 May 94 09:33:38 CDT Date: Mon, 2 May 94 09:33:38 CDT Message-Id: <9405021433.AA13127@intgrty.intgrty.mn.org> From: Greg Doyle To: ibis@vhdl.org Subject: Comments on Bird to add a new section for [Model] sub-parameters To: IBIS group I want to express my support for the BIRD submitted by John Keifer which is designed to add specified load parameters to the [Model] section. I think it is good to include anything which is considered to be "data book" information into the model description. I would actually like to see these parameters become required, but we'll take what we can get for now. I would like to see us also add two extra parameters (Vref & Rref). These extra two parameters would allow this keyword to be extended to support open collector/drain devices as well as ECL devices. With these parameters added, we would probably be able to have 95+% coverage of all devices. Thus, I propose the specified load schematic look as follows: |\ | \ | \________________________ | / | | | / __|__ | |/ _____ Cref \ | / Rref | \ GND / | | Vref Greg Doyle Integrity Engineering From Derrick_Duehren@ccm2.jf.intel.com Mon May 2 21:54:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07381; Mon, 2 May 94 21:54:08 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0pyCRC-000MNNC; Mon, 2 May 94 21:50 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 2 May 94 21:50:30 PST Date: Mon, 2 May 94 21:50:30 PST From: Derrick Duehren Message-Id: <940502215030_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: May 20 Editing Committee Meeting Text item: Text_1 For those planning to participate in the May 20 editing committee meeting: Please RSVP to Derrick_Duehren@ccm.jf.intel.com before or at the May 13 IBIS meeting so I can make appropriate arrangements. If you received a Fax from me with a map, you're already on my list. IBIS Editing Committee Meeting May 20, 1994 9:00 am - 5:00 pm (lunch courtesy Intel) Intel Jones Farm Building 2111 N.E. 25th Ave. Hillsboro, OR 97124 (Park near the flag poles) Hillsboro is about 40 minutes West of the Portland airport. Some hotel options in increasing quality levels: Best Western Hallmark Inn $65.00 3500 N.E. Cornell Rd. Hillsboro, OR (~2 miles from Jones Farm) (800) 528-1234 Greenwood Inn $74.00/$82.00 10700 S.W. Allen Blvd. Beaverton, OR (~12 miles from Jones farm) (800) 289-1300 Executive Inn at the Lakes $75 18200 N.W. Cornell Rd. Beaverton, OR (~8 miles from Jones Farm) (800) 235-3932 Embassy Suites $109.00 9000 S.W. Washington Square Rd. Tigard, OR (~14 miles from Jones Farm) (800) 772-3897 From Derrick_Duehren@ccm2.jf.intel.com Mon May 2 22:33:37 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07619; Mon, 2 May 94 22:33:37 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0pyD3T-000MNdC; Mon, 2 May 94 22:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 2 May 94 22:30:03 PST Date: Mon, 2 May 94 22:30:03 PST From: Derrick Duehren Message-Id: <940502223003_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: Legal Advice Needed Text item: Text_1 Hello, We need someone's company attorney to volunteer some legal advice to the IBIS effort. I'm trying to get Intel's legal team to recommend a course of action for getting us some legal standing, such as a Special Interest Group, so we can get a corporate Tax ID number, etc. I have not been very successful. Can any of you loyal IBISians help here? - Derrick Duehren Intel Corp. (503) 696-4299 From jonp@qdt.com Tue May 3 20:50:36 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20376; Tue, 3 May 94 20:50:36 PDT Received: from uucp3.uu.net by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwojn25963; Tue, 3 May 94 23:48:05 -0400 Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Tue, 3 May 1994 23:48:06 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01004; Tue, 3 May 94 15:32:52 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA00128; Tue, 3 May 94 15:32:42 PDT Date: Tue, 3 May 94 15:32:42 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9405032232.AA00128@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA04355; Tue, 3 May 94 15:32:42 PDT To: ibis@vhdl.org Subject: AC waveform Synchronization Here is a cut at that measurement waveform sync method I had spoken of. jonp #--------cut below this line and send to post script printer ----- %!PS-Adobe-3.0 %%BoundingBox: (atend) %%Pages: (atend) %%PageOrder: (atend) %%DocumentFonts: (atend) %%Creator: Frame 4.0 %%DocumentData: Clean7Bit %%EndComments %%BeginProlog % % Frame ps_prolog 4.0, for use with Frame 4.0 products % This ps_prolog file is Copyright (c) 1986-1993 Frame Technology % Corporation. All rights reserved. This ps_prolog file may be % freely copied and distributed in conjunction with documents created % using FrameMaker, FrameBuilder and FrameViewer as long as this % copyright notice is preserved. % % Frame products normally print colors as their true color on a color printer % or as shades of gray, based on luminance, on a black-and white printer. The % following flag, if set to True, forces all non-white colors to print as pure % black. This has no effect on bitmap images. /FMPrintAllColorsAsBlack false def % % Frame products can either set their own line screens or use a printer's % default settings. Three flags below control this separately for no % separations, spot separations and process separations. If a flag % is true, then the default printer settings will not be changed. If it is % false, Frame products will use their own settings from a table based on % the printer's resolution. /FMUseDefaultNoSeparationScreen true def /FMUseDefaultSpotSeparationScreen true def /FMUseDefaultProcessSeparationScreen false def % % For any given PostScript printer resolution, Frame products have two sets of % screen angles and frequencies for printing process separations, which are % recomended by Adobe. The following variable chooses the higher frequencies % when set to true or the lower frequencies when set to false. This is only % effective if the appropriate FMUseDefault...SeparationScreen flag is false. /FMUseHighFrequencyScreens true def % % PostScript Level 2 printers contain an "Accurate Screens" feature which can % improve process separation rendering at the expense of compute time. This % flag is ignored by PostScript Level 1 printers. /FMUseAcccurateScreens true def % % The following PostScript procedure defines the spot function that Frame % products will use for process separations. You may un-comment-out one of % the alternative functions below, or use your own. % % Dot function /FMSpotFunction {abs exch abs 2 copy add 1 gt {1 sub dup mul exch 1 sub dup mul add 1 sub } {dup mul exch dup mul add 1 exch sub }ifelse } def % % Line function % /FMSpotFunction { pop } def % % Elipse function % /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add % sqrt 1 exch sub } def % % /FMversion (4.0) def /FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def /FMPColor FMLevel1 { false /colorimage where {pop pop true} if } { true } ifelse def /FrameDict 400 dict def systemdict /errordict known not {/errordict 10 dict def errordict /rangecheck {stop} put} if % The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk FrameDict /tmprangecheck errordict /rangecheck get put errordict /rangecheck {FrameDict /bug true put} put FrameDict /bug false put mark % Some PS machines read past the CR, so keep the following 3 lines together! currentfile 5 string readline 00 0000000000 cleartomark errordict /rangecheck FrameDict /tmprangecheck get put FrameDict /bug get { /readline { /gstring exch def /gfile exch def /gindex 0 def { gfile read pop dup 10 eq {exit} if dup 13 eq {exit} if gstring exch gindex exch put /gindex gindex 1 add def } loop pop gstring 0 gindex getinterval true } bind def } if /FMshowpage /showpage load def /FMquit /quit load def /FMFAILURE { dup = flush FMshowpage /Helvetica findfont 12 scalefont setfont 72 200 moveto show FMshowpage FMquit } def /FMVERSION { FMversion ne { (Frame product version does not match ps_prolog!) FMFAILURE } if } def /FMBADEPSF { (PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X ) dup dup (X) search pop exch pop exch pop length 4 -1 roll putinterval FMFAILURE } def /FMLOCAL { FrameDict begin 0 def end } def /concatprocs { /proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx }def FrameDict begin /FMnone 0 def /FMcyan 1 def /FMmagenta 2 def /FMyellow 3 def /FMblack 4 def /FMcustom 5 def /FrameNegative false def /FrameSepIs FMnone def /FrameSepBlack 0 def /FrameSepYellow 0 def /FrameSepMagenta 0 def /FrameSepCyan 0 def /FrameSepRed 1 def /FrameSepGreen 1 def /FrameSepBlue 1 def /FrameCurGray 1 def /FrameCurPat null def /FrameCurColors [ 0 0 0 1 0 0 0 ] def /FrameColorEpsilon .001 def /eqepsilon { sub dup 0 lt {neg} if FrameColorEpsilon le } bind def /FrameCmpColorsCMYK { 2 copy 0 get exch 0 get eqepsilon { 2 copy 1 get exch 1 get eqepsilon { 2 copy 2 get exch 2 get eqepsilon { 3 get exch 3 get eqepsilon } {pop pop false} ifelse }{pop pop false} ifelse } {pop pop false} ifelse } bind def /FrameCmpColorsRGB { 2 copy 4 get exch 0 get eqepsilon { 2 copy 5 get exch 1 get eqepsilon { 6 get exch 2 get eqepsilon }{pop pop false} ifelse } {pop pop false} ifelse } bind def /RGBtoCMYK { 1 exch sub 3 1 roll 1 exch sub 3 1 roll 1 exch sub 3 1 roll 3 copy 2 copy le { pop } { exch pop } ifelse 2 copy le { pop } { exch pop } ifelse dup dup dup 6 1 roll 4 1 roll 7 1 roll sub 6 1 roll sub 5 1 roll sub 4 1 roll } bind def /CMYKtoRGB { dup dup 4 -1 roll add 5 1 roll 3 -1 roll add 4 1 roll add 1 exch sub dup 0 lt {pop 0} if 3 1 roll 1 exch sub dup 0 lt {pop 0} if exch 1 exch sub dup 0 lt {pop 0} if exch } bind def /FrameSepInit { 1.0 RealSetgray } bind def /FrameSetSepColor { /FrameSepBlue exch def /FrameSepGreen exch def /FrameSepRed exch def /FrameSepBlack exch def /FrameSepYellow exch def /FrameSepMagenta exch def /FrameSepCyan exch def /FrameSepIs FMcustom def setCurrentScreen } bind def /FrameSetCyan { /FrameSepBlue 1.0 def /FrameSepGreen 1.0 def /FrameSepRed 0.0 def /FrameSepBlack 0.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 1.0 def /FrameSepIs FMcyan def setCurrentScreen } bind def /FrameSetMagenta { /FrameSepBlue 1.0 def /FrameSepGreen 0.0 def /FrameSepRed 1.0 def /FrameSepBlack 0.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 1.0 def /FrameSepCyan 0.0 def /FrameSepIs FMmagenta def setCurrentScreen } bind def /FrameSetYellow { /FrameSepBlue 0.0 def /FrameSepGreen 1.0 def /FrameSepRed 1.0 def /FrameSepBlack 0.0 def /FrameSepYellow 1.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 0.0 def /FrameSepIs FMyellow def setCurrentScreen } bind def /FrameSetBlack { /FrameSepBlue 0.0 def /FrameSepGreen 0.0 def /FrameSepRed 0.0 def /FrameSepBlack 1.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 0.0 def /FrameSepIs FMblack def setCurrentScreen } bind def /FrameNoSep { /FrameSepIs FMnone def setCurrentScreen } bind def /FrameSetSepColors { FrameDict begin [ exch 1 add 1 roll ] /FrameSepColors exch def end } bind def /FrameColorInSepListCMYK { FrameSepColors { exch dup 3 -1 roll FrameCmpColorsCMYK { pop true exit } if } forall dup true ne {pop false} if } bind def /FrameColorInSepListRGB { FrameSepColors { exch dup 3 -1 roll FrameCmpColorsRGB { pop true exit } if } forall dup true ne {pop false} if } bind def /RealSetgray /setgray load def /RealSetrgbcolor /setrgbcolor load def /RealSethsbcolor /sethsbcolor load def end /setgray { FrameDict begin FrameSepIs FMnone eq { RealSetgray } { FrameSepIs FMblack eq { RealSetgray } { FrameSepIs FMcustom eq FrameSepRed 0 eq and FrameSepGreen 0 eq and FrameSepBlue 0 eq and { RealSetgray } { 1 RealSetgray pop } ifelse } ifelse } ifelse end } bind def /setrgbcolor { FrameDict begin FrameSepIs FMnone eq { RealSetrgbcolor } { 3 copy [ 4 1 roll ] FrameColorInSepListRGB { FrameSepBlue eq exch FrameSepGreen eq and exch FrameSepRed eq and { 0 } { 1 } ifelse } { FMPColor { RealSetrgbcolor currentcmykcolor } { RGBtoCMYK } ifelse FrameSepIs FMblack eq {1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse RealSetgray } ifelse end } bind def /sethsbcolor { FrameDict begin FrameSepIs FMnone eq { RealSethsbcolor } { RealSethsbcolor currentrgbcolor setrgbcolor } ifelse end } bind def FrameDict begin /setcmykcolor where { pop /RealSetcmykcolor /setcmykcolor load def } { /RealSetcmykcolor { 4 1 roll 3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat setrgbcolor pop } bind def } ifelse userdict /setcmykcolor { FrameDict begin FrameSepIs FMnone eq { RealSetcmykcolor } { 4 copy [ 5 1 roll ] FrameColorInSepListCMYK { FrameSepBlack eq exch FrameSepYellow eq and exch FrameSepMagenta eq and exch FrameSepCyan eq and { 0 } { 1 } ifelse } { FrameSepIs FMblack eq {1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse RealSetgray } ifelse end } bind put FMLevel1 not { /patProcDict 5 dict dup begin <0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 4 -4 moveto 12 4 lineto stroke -4 4 moveto 4 12 lineto stroke} bind def <0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke -4 4 moveto 4 -4 lineto stroke 4 12 moveto 12 4 lineto stroke} bind def <8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke -1 -1 moveto 9 9 lineto stroke } bind def <03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 4 -4 moveto 12 4 lineto stroke -4 4 moveto 4 12 lineto stroke} bind def <8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke -4 4 moveto 4 -4 lineto stroke 4 12 moveto 12 4 lineto stroke} bind def end def /patDict 15 dict dup begin /PatternType 1 def /PaintType 2 def /TilingType 3 def /BBox [ 0 0 8 8 ] def /XStep 8 def /YStep 8 def /PaintProc { begin patProcDict bstring known { patProcDict bstring get exec } { 8 8 true [1 0 0 -1 0 8] bstring imagemask } ifelse end } bind def end def } if /combineColor { FrameSepIs FMnone eq { graymode FMLevel1 or not { [/Pattern [/DeviceCMYK]] setcolorspace FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor } { FrameCurColors 3 get 1.0 ge { FrameCurGray RealSetgray } { FMPColor graymode and { 0 1 3 { FrameCurColors exch get 1 FrameCurGray sub mul } for RealSetcmykcolor } { 4 1 6 { FrameCurColors exch get graymode { 1 exch sub 1 FrameCurGray sub mul 1 exch sub } { 1.0 lt {FrameCurGray} {1} ifelse } ifelse } for RealSetrgbcolor } ifelse } ifelse } ifelse } { FrameCurColors 0 4 getinterval aload FrameColorInSepListCMYK { FrameSepBlack eq exch FrameSepYellow eq and exch FrameSepMagenta eq and exch FrameSepCyan eq and FrameSepIs FMcustom eq and { FrameCurGray } { 1 } ifelse } { FrameSepIs FMblack eq {FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse graymode FMLevel1 or not { [/Pattern [/DeviceGray]] setcolorspace FrameCurPat setcolor } { graymode not FMLevel1 and { dup 1 lt {pop FrameCurGray} if } if RealSetgray } ifelse } ifelse } bind def /savematrix { orgmatrix currentmatrix pop } bind def /restorematrix { orgmatrix setmatrix } bind def /dmatrix matrix def /dpi 72 0 dmatrix defaultmatrix dtransform dup mul exch dup mul add sqrt def /freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def /sangle 1 0 dmatrix defaultmatrix dtransform exch atan def /dpiranges [ 2540 2400 1693 1270 1200 635 600 0 ] def /CMLowFreqs [ 100.402 94.8683 89.2289 100.402 94.8683 66.9349 63.2456 47.4342 ] def /YLowFreqs [ 95.25 90.0 84.65 95.25 90.0 70.5556 66.6667 50.0 ] def /KLowFreqs [ 89.8026 84.8528 79.8088 89.8026 84.8528 74.8355 70.7107 53.033 ] def /CLowAngles [ 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 ] def /MLowAngles [ 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 ] def /YLowTDot [ true true false true true false false false ] def /CMHighFreqs [ 133.87 126.491 133.843 108.503 102.523 100.402 94.8683 63.2456 ] def /YHighFreqs [ 127.0 120.0 126.975 115.455 109.091 95.25 90.0 60.0 ] def /KHighFreqs [ 119.737 113.137 119.713 128.289 121.218 89.8026 84.8528 63.6395 ] def /CHighAngles [ 71.5651 71.5651 71.5651 70.0169 70.0169 71.5651 71.5651 71.5651 ] def /MHighAngles [ 18.4349 18.4349 18.4349 19.9831 19.9831 18.4349 18.4349 18.4349 ] def /YHighTDot [ false false true false false true true false ] def /PatFreq [ 10.5833 10.0 9.4055 10.5833 10.0 10.5833 10.0 9.375 ] def /screenIndex { 0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for } bind def /getCyanScreen { FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load } bind def /getMagentaScreen { FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load } bind def /getYellowScreen { FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse screenIndex dup 3 1 roll get 3 1 roll get { 3 div {2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat FMSpotFunction } } {/FMSpotFunction load } ifelse 0.0 exch } bind def /getBlackScreen { FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse screenIndex get 45.0 /FMSpotFunction load } bind def /getSpotScreen { getBlackScreen } bind def /getCompositeScreen { getBlackScreen } bind def /FMSetScreen FMLevel1 { /setscreen load }{ { 8 dict begin /HalftoneType 1 def /SpotFunction exch def /Angle exch def /Frequency exch def /AccurateScreens FMUseAcccurateScreens def currentdict end sethalftone } bind } ifelse def /setDefaultScreen { FMPColor { orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer } { orgxfer cvx settransfer } ifelse orgfreq organgle orgproc cvx setscreen } bind def /setCurrentScreen { FrameSepIs FMnone eq { FMUseDefaultNoSeparationScreen { setDefaultScreen } { getCompositeScreen FMSetScreen } ifelse } { FrameSepIs FMcustom eq { FMUseDefaultSpotSeparationScreen { setDefaultScreen } { getSpotScreen FMSetScreen } ifelse } { FMUseDefaultProcessSeparationScreen { setDefaultScreen } { FrameSepIs FMcyan eq { getCyanScreen FMSetScreen } { FrameSepIs FMmagenta eq { getMagentaScreen FMSetScreen } { FrameSepIs FMyellow eq { getYellowScreen FMSetScreen } { getBlackScreen FMSetScreen } ifelse } ifelse } ifelse } ifelse } ifelse } ifelse } bind def end /gstring FMLOCAL /gfile FMLOCAL /gindex FMLOCAL /orgrxfer FMLOCAL /orggxfer FMLOCAL /orgbxfer FMLOCAL /orgxfer FMLOCAL /orgproc FMLOCAL /orgrproc FMLOCAL /orggproc FMLOCAL /orgbproc FMLOCAL /organgle FMLOCAL /orgrangle FMLOCAL /orggangle FMLOCAL /orgbangle FMLOCAL /orgfreq FMLOCAL /orgrfreq FMLOCAL /orggfreq FMLOCAL /orgbfreq FMLOCAL /yscale FMLOCAL /xscale FMLOCAL /edown FMLOCAL /manualfeed FMLOCAL /paperheight FMLOCAL /paperwidth FMLOCAL /FMDOCUMENT { array /FMfonts exch def /#copies exch def FrameDict begin 0 ne /manualfeed exch def /paperheight exch def /paperwidth exch def 0 ne /FrameNegative exch def 0 ne /edown exch def /yscale exch def /xscale exch def FMLevel1 { manualfeed {setmanualfeed} if /FMdicttop countdictstack 1 add def /FMoptop count def setpapername manualfeed {true} {papersize} ifelse {manualpapersize} {false} ifelse {desperatepapersize} {false} ifelse { (Can't select requested paper size for Frame print job!) FMFAILURE } if count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for } {{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped { (Can't select requested paper size for Frame print job!) FMFAILURE } if {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop } ifelse FMPColor { currentcolorscreen cvlit /orgproc exch def /organgle exch def /orgfreq exch def cvlit /orgbproc exch def /orgbangle exch def /orgbfreq exch def cvlit /orggproc exch def /orggangle exch def /orggfreq exch def cvlit /orgrproc exch def /orgrangle exch def /orgrfreq exch def currentcolortransfer FrameNegative { 1 1 4 { pop { 1 exch sub } concatprocs 4 1 roll } for 4 copy setcolortransfer } if cvlit /orgxfer exch def cvlit /orgbxfer exch def cvlit /orggxfer exch def cvlit /orgrxfer exch def } { currentscreen cvlit /orgproc exch def /organgle exch def /orgfreq exch def currenttransfer FrameNegative { { 1 exch sub } concatprocs dup settransfer } if cvlit /orgxfer exch def } ifelse end } def /pagesave FMLOCAL /orgmatrix FMLOCAL /landscape FMLOCAL /pwid FMLOCAL /FMBEGINPAGE { FrameDict begin /pagesave save def 3.86 setmiterlimit /landscape exch 0 ne def landscape { 90 rotate 0 exch dup /pwid exch def neg translate pop }{ pop /pwid exch def } ifelse edown { [-1 0 0 1 pwid 0] concat } if 0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 0 paperheight lineto 0 0 lineto 1 setgray fill xscale yscale scale /orgmatrix matrix def gsave } def /FMENDPAGE { grestore pagesave restore end showpage } def /FMFONTDEFINE { FrameDict begin findfont ReEncode 1 index exch definefont FMfonts 3 1 roll put end } def /FMFILLS { FrameDict begin dup array /fillvals exch def dict /patCache exch def end } def /FMFILL { FrameDict begin fillvals 3 1 roll put end } def /FMNORMALIZEGRAPHICS { newpath 0.0 0.0 moveto 1 setlinewidth 0 setlinecap 0 0 0 sethsbcolor 0 setgray } bind def /fx FMLOCAL /fy FMLOCAL /fh FMLOCAL /fw FMLOCAL /llx FMLOCAL /lly FMLOCAL /urx FMLOCAL /ury FMLOCAL /FMBEGINEPSF { end /FMEPSF save def /showpage {} def % See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714. % "...the following operators MUST NOT be used in an EPS file:" (emphasis ours) /banddevice {(banddevice) FMBADEPSF} def /clear {(clear) FMBADEPSF} def /cleardictstack {(cleardictstack) FMBADEPSF} def /copypage {(copypage) FMBADEPSF} def /erasepage {(erasepage) FMBADEPSF} def /exitserver {(exitserver) FMBADEPSF} def /framedevice {(framedevice) FMBADEPSF} def /grestoreall {(grestoreall) FMBADEPSF} def /initclip {(initclip) FMBADEPSF} def /initgraphics {(initgraphics) FMBADEPSF} def /initmatrix {(initmatrix) FMBADEPSF} def /quit {(quit) FMBADEPSF} def /renderbands {(renderbands) FMBADEPSF} def /setglobal {(setglobal) FMBADEPSF} def /setpagedevice {(setpagedevice) FMBADEPSF} def /setshared {(setshared) FMBADEPSF} def /startjob {(startjob) FMBADEPSF} def /lettertray {(lettertray) FMBADEPSF} def /letter {(letter) FMBADEPSF} def /lettersmall {(lettersmall) FMBADEPSF} def /11x17tray {(11x17tray) FMBADEPSF} def /11x17 {(11x17) FMBADEPSF} def /ledgertray {(ledgertray) FMBADEPSF} def /ledger {(ledger) FMBADEPSF} def /legaltray {(legaltray) FMBADEPSF} def /legal {(legal) FMBADEPSF} def /statementtray {(statementtray) FMBADEPSF} def /statement {(statement) FMBADEPSF} def /executivetray {(executivetray) FMBADEPSF} def /executive {(executive) FMBADEPSF} def /a3tray {(a3tray) FMBADEPSF} def /a3 {(a3) FMBADEPSF} def /a4tray {(a4tray) FMBADEPSF} def /a4 {(a4) FMBADEPSF} def /a4small {(a4small) FMBADEPSF} def /b4tray {(b4tray) FMBADEPSF} def /b4 {(b4) FMBADEPSF} def /b5tray {(b5tray) FMBADEPSF} def /b5 {(b5) FMBADEPSF} def FMNORMALIZEGRAPHICS [/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall fx fw 2 div add fy fh 2 div add translate rotate fw 2 div neg fh 2 div neg translate fw urx llx sub div fh ury lly sub div scale llx neg lly neg translate /FMdicttop countdictstack 1 add def /FMoptop count def } bind def /FMENDEPSF { count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for FMEPSF restore FrameDict begin } bind def FrameDict begin /setmanualfeed { %%BeginFeature *ManualFeed True statusdict /manualfeed true put %%EndFeature } bind def /max {2 copy lt {exch} if pop} bind def /min {2 copy gt {exch} if pop} bind def /inch {72 mul} def /pagedimen { paperheight sub abs 16 lt exch paperwidth sub abs 16 lt and {/papername exch def} {pop} ifelse } bind def /papersizedict FMLOCAL /setpapername { /papersizedict 14 dict def papersizedict begin /papername /unknown def /Letter 8.5 inch 11.0 inch pagedimen /LetterSmall 7.68 inch 10.16 inch pagedimen /Tabloid 11.0 inch 17.0 inch pagedimen /Ledger 17.0 inch 11.0 inch pagedimen /Legal 8.5 inch 14.0 inch pagedimen /Statement 5.5 inch 8.5 inch pagedimen /Executive 7.5 inch 10.0 inch pagedimen /A3 11.69 inch 16.5 inch pagedimen /A4 8.26 inch 11.69 inch pagedimen /A4Small 7.47 inch 10.85 inch pagedimen /B4 10.125 inch 14.33 inch pagedimen /B5 7.16 inch 10.125 inch pagedimen end } bind def /papersize { papersizedict begin /Letter {lettertray letter} def /LetterSmall {lettertray lettersmall} def /Tabloid {11x17tray 11x17} def /Ledger {ledgertray ledger} def /Legal {legaltray legal} def /Statement {statementtray statement} def /Executive {executivetray executive} def /A3 {a3tray a3} def /A4 {a4tray a4} def /A4Small {a4tray a4small} def /B4 {b4tray b4} def /B5 {b5tray b5} def /unknown {unknown} def papersizedict dup papername known {papername} {/unknown} ifelse get end statusdict begin stopped end } bind def /manualpapersize { papersizedict begin /Letter {letter} def /LetterSmall {lettersmall} def /Tabloid {11x17} def /Ledger {ledger} def /Legal {legal} def /Statement {statement} def /Executive {executive} def /A3 {a3} def /A4 {a4} def /A4Small {a4small} def /B4 {b4} def /B5 {b5} def /unknown {unknown} def papersizedict dup papername known {papername} {/unknown} ifelse get end stopped } bind def /desperatepapersize { statusdict /setpageparams known { paperwidth paperheight 0 1 statusdict begin {setpageparams} stopped end } {true} ifelse } bind def /DiacriticEncoding [ /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash /zero /one /two /three /four /five /six /seven /eight /nine /colon /semicolon /less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar /braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute /Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis /atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis /iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve /ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex /udieresis /dagger /.notdef /cent /sterling /section /bullet /paragraph /germandbls /registered /copyright /trademark /acute /dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef /yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown /exclamdown /logicalnot /.notdef /florin /.notdef /.notdef /guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde /Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright /quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis /fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl /periodcentered /quotesinglbase /quotedblbase /perthousand /Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute /Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve /Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron /breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron ] def /ReEncode { dup length dict begin { 1 index /FID ne {def} {pop pop} ifelse } forall 0 eq {/Encoding DiacriticEncoding def} if currentdict end } bind def FMPColor { /BEGINBITMAPCOLOR { BITMAPCOLOR} def /BEGINBITMAPCOLORc { BITMAPCOLORc} def /BEGINBITMAPTRUECOLOR { BITMAPTRUECOLOR } def /BEGINBITMAPTRUECOLORc { BITMAPTRUECOLORc } def } { /BEGINBITMAPCOLOR { BITMAPGRAY} def /BEGINBITMAPCOLORc { BITMAPGRAYc} def /BEGINBITMAPTRUECOLOR { BITMAPTRUEGRAY } def /BEGINBITMAPTRUECOLORc { BITMAPTRUEGRAYc } def } ifelse /K { FMPrintAllColorsAsBlack { dup 1 eq 2 index 1 eq and 3 index 1 eq and not {7 {pop} repeat 0 0 0 1 0 0 0} if } if FrameCurColors astore pop combineColor } bind def /graymode true def /bwidth FMLOCAL /bpside FMLOCAL /bstring FMLOCAL /onbits FMLOCAL /offbits FMLOCAL /xindex FMLOCAL /yindex FMLOCAL /x FMLOCAL /y FMLOCAL /setPatternMode { FMLevel1 { /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def freq sangle landscape {90 add} if {/y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def bstring yindex bwidth mul xindex 8 idiv add get 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if {/onbits onbits 1 add def 1} {/offbits offbits 1 add def 0} ifelse } setscreen offbits offbits onbits add div FrameNegative {1.0 exch sub} if /FrameCurGray exch def } { pop pop dup patCache exch known { patCache exch get } { dup patDict /bstring 3 -1 roll put patDict 9 PatFreq screenIndex get div dup matrix scale makepattern dup patCache 4 -1 roll 3 -1 roll put } ifelse /FrameCurGray 0 def /FrameCurPat exch def } ifelse /graymode false def combineColor } bind def /setGrayScaleMode { graymode not { /graymode true def FMLevel1 { setCurrentScreen } if } if /FrameCurGray exch def combineColor } bind def /normalize { transform round exch round exch itransform } bind def /dnormalize { dtransform round exch round exch idtransform } bind def /lnormalize { 0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop } bind def /H { lnormalize setlinewidth } bind def /Z { setlinecap } bind def /PFill { graymode FMLevel1 or not { gsave 1 setgray eofill grestore } if } bind def /PStroke { graymode FMLevel1 or not { gsave 1 setgray stroke grestore } if stroke } bind def /fillvals FMLOCAL /X { fillvals exch get dup type /stringtype eq {8 1 setPatternMode} {setGrayScaleMode} ifelse } bind def /V { PFill gsave eofill grestore } bind def /Vclip { clip } bind def /Vstrk { currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /N { PStroke } bind def /Nclip { strokepath clip newpath } bind def /Nstrk { currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /M {newpath moveto} bind def /E {lineto} bind def /D {curveto} bind def /O {closepath} bind def /n FMLOCAL /L { /n exch def newpath normalize moveto 2 1 n {pop normalize lineto} for } bind def /Y { L closepath } bind def /x1 FMLOCAL /x2 FMLOCAL /y1 FMLOCAL /y2 FMLOCAL /R { /y2 exch def /x2 exch def /y1 exch def /x1 exch def x1 y1 x2 y1 x2 y2 x1 y2 4 Y } bind def /rad FMLOCAL /rarc {rad arcto } bind def /RR { /rad exch def normalize /y2 exch def /x2 exch def normalize /y1 exch def /x1 exch def mark newpath { x1 y1 rad add moveto x1 y2 x2 y2 rarc x2 y2 x2 y1 rarc x2 y1 x1 y1 rarc x1 y1 x1 y2 rarc closepath } stopped {x1 y1 x2 y2 R} if cleartomark } bind def /RRR { /rad exch def normalize /y4 exch def /x4 exch def normalize /y3 exch def /x3 exch def normalize /y2 exch def /x2 exch def normalize /y1 exch def /x1 exch def newpath normalize moveto mark { x2 y2 x3 y3 rarc x3 y3 x4 y4 rarc x4 y4 x1 y1 rarc x1 y1 x2 y2 rarc closepath } stopped {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if cleartomark } bind def /C { grestore gsave R clip setCurrentScreen } bind def /CP { grestore gsave Y clip setCurrentScreen } bind def /FMpointsize FMLOCAL /F { FMfonts exch get FMpointsize scalefont setfont } bind def /Q { /FMpointsize exch def F } bind def /T { moveto show } bind def /RF { rotate 0 ne {-1 1 scale} if } bind def /TF { gsave moveto RF show grestore } bind def /P { moveto 0 32 3 2 roll widthshow } bind def /PF { gsave moveto RF 0 32 3 2 roll widthshow grestore } bind def /S { moveto 0 exch ashow } bind def /SF { gsave moveto RF 0 exch ashow grestore } bind def /B { moveto 0 32 4 2 roll 0 exch awidthshow } bind def /BF { gsave moveto RF 0 32 4 2 roll 0 exch awidthshow grestore } bind def /G { gsave newpath normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath PFill fill grestore } bind def /Gstrk { savematrix newpath 2 index 2 div add exch 3 index 2 div sub exch normalize 2 index 2 div sub exch 3 index 2 div add exch translate scale 0.0 0.0 1.0 5 3 roll arc restorematrix currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /Gclip { newpath savematrix normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath clip newpath restorematrix } bind def /GG { gsave newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath PFill fill grestore } bind def /GGclip { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath clip newpath restorematrix } bind def /GGstrk { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath restorematrix currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /A { gsave savematrix newpath 2 index 2 div add exch 3 index 2 div sub exch normalize 2 index 2 div sub exch 3 index 2 div add exch translate scale 0.0 0.0 1.0 5 3 roll arc restorematrix PStroke grestore } bind def /Aclip { newpath savematrix normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath strokepath clip newpath restorematrix } bind def /Astrk { Gstrk } bind def /AA { gsave savematrix newpath 3 index 2 div add exch 4 index 2 div sub exch normalize 3 index 2 div sub exch 4 index 2 div add exch translate rotate scale 0.0 0.0 1.0 5 3 roll arc restorematrix PStroke grestore } bind def /AAclip { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath strokepath clip newpath restorematrix } bind def /AAstrk { GGstrk } bind def /x FMLOCAL /y FMLOCAL /w FMLOCAL /h FMLOCAL /xx FMLOCAL /yy FMLOCAL /ww FMLOCAL /hh FMLOCAL /FMsaveobject FMLOCAL /FMoptop FMLOCAL /FMdicttop FMLOCAL /BEGINPRINTCODE { /FMdicttop countdictstack 1 add def /FMoptop count 7 sub def /FMsaveobject save def userdict begin /showpage {} def FMNORMALIZEGRAPHICS 3 index neg 3 index neg translate } bind def /ENDPRINTCODE { count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for FMsaveobject restore } bind def /gn { 0 { 46 mul cf read pop 32 sub dup 46 lt {exit} if 46 sub add } loop add } bind def /str FMLOCAL /cfs { /str sl string def 0 1 sl 1 sub {str exch val put} for str def } bind def /ic [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223 0 {0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx} {10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx} {19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12} {13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh} {4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh} {13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl} {7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl} {0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl} {10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl} ] def /sl FMLOCAL /val FMLOCAL /ws FMLOCAL /im FMLOCAL /bs FMLOCAL /cs FMLOCAL /len FMLOCAL /pos FMLOCAL /ms { /sl exch def /val 255 def /ws cfs /im cfs /val 0 def /bs cfs /cs cfs } bind def 400 ms /ip { is 0 cf cs readline pop { ic exch get exec add } forall pop } bind def /rip { bis ris copy pop is 0 cf cs readline pop { ic exch get exec add } forall pop pop ris gis copy pop dup is exch cf cs readline pop { ic exch get exec add } forall pop pop gis bis copy pop dup add is exch cf cs readline pop { ic exch get exec add } forall pop } bind def /wh { /len exch def /pos exch def ws 0 len getinterval im pos len getinterval copy pop pos len } bind def /bl { /len exch def /pos exch def bs 0 len getinterval im pos len getinterval copy pop pos len } bind def /s1 1 string def /fl { /len exch def /pos exch def /val cf s1 readhexstring pop 0 get def pos 1 pos len add 1 sub {im exch val put} for pos len } bind def /hx { 3 copy getinterval cf exch readhexstring pop pop } bind def /h FMLOCAL /w FMLOCAL /d FMLOCAL /lb FMLOCAL /bitmapsave FMLOCAL /is FMLOCAL /cf FMLOCAL /wbytes { dup dup 24 eq { pop pop 3 mul } { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse } bind def /BEGINBITMAPBWc { 1 {} COMMONBITMAPc } bind def /BEGINBITMAPGRAYc { 8 {} COMMONBITMAPc } bind def /BEGINBITMAP2BITc { 2 {} COMMONBITMAPc } bind def /COMMONBITMAPc { /r exch def /d exch def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def r /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h d [w 0 0 h neg 0 h] {ip} image bitmapsave restore grestore } bind def /BEGINBITMAPBW { 1 {} COMMONBITMAP } bind def /BEGINBITMAPGRAY { 8 {} COMMONBITMAP } bind def /BEGINBITMAP2BIT { 2 {} COMMONBITMAP } bind def /COMMONBITMAP { /r exch def /d exch def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def r /is w d wbytes string def /cf currentfile def w h d [w 0 0 h neg 0 h] {cf is readhexstring pop} image bitmapsave restore grestore } bind def /ngrayt 256 array def /nredt 256 array def /nbluet 256 array def /ngreent 256 array def /gryt FMLOCAL /blut FMLOCAL /grnt FMLOCAL /redt FMLOCAL /indx FMLOCAL /cynu FMLOCAL /magu FMLOCAL /yelu FMLOCAL /k FMLOCAL /u FMLOCAL FMLevel1 { /colorsetup { currentcolortransfer /gryt exch def /blut exch def /grnt exch def /redt exch def 0 1 255 { /indx exch def /cynu 1 red indx get 255 div sub def /magu 1 green indx get 255 div sub def /yelu 1 blue indx get 255 div sub def /k cynu magu min yelu min def /u k currentundercolorremoval exec def % /u 0 def nredt indx 1 0 cynu u sub max sub redt exec put ngreent indx 1 0 magu u sub max sub grnt exec put nbluet indx 1 0 yelu u sub max sub blut exec put ngrayt indx 1 k currentblackgeneration exec sub gryt exec put } for {255 mul cvi nredt exch get} {255 mul cvi ngreent exch get} {255 mul cvi nbluet exch get} {255 mul cvi ngrayt exch get} setcolortransfer {pop 0} setundercolorremoval {} setblackgeneration } bind def } { /colorSetup2 { [ /Indexed /DeviceRGB 255 {dup red exch get 255 div exch dup green exch get 255 div exch blue exch get 255 div} ] setcolorspace } bind def } ifelse /tran FMLOCAL /fakecolorsetup { /tran 256 string def 0 1 255 {/indx exch def tran indx red indx get 77 mul green indx get 151 mul blue indx get 28 mul add add 256 idiv put} for currenttransfer {255 mul cvi tran exch get 255.0 div} exch concatprocs settransfer } bind def /BITMAPCOLOR { /d 8 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def FMLevel1 { colorsetup /is w d wbytes string def /cf currentfile def w h d [w 0 0 h neg 0 h] {cf is readhexstring pop} {is} {is} true 3 colorimage } { colorSetup2 /is w d wbytes string def /cf currentfile def 7 dict dup begin /ImageType 1 def /Width w def /Height h def /ImageMatrix [w 0 0 h neg 0 h] def /DataSource {cf is readhexstring pop} bind def /BitsPerComponent d def /Decode [0 255] def end image } ifelse bitmapsave restore grestore } bind def /BITMAPCOLORc { /d 8 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def FMLevel1 { colorsetup /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h d [w 0 0 h neg 0 h] {ip} {is} {is} true 3 colorimage } { colorSetup2 /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def 7 dict dup begin /ImageType 1 def /Width w def /Height h def /ImageMatrix [w 0 0 h neg 0 h] def /DataSource {ip} bind def /BitsPerComponent d def /Decode [0 255] def end image } ifelse bitmapsave restore grestore } bind def /BITMAPTRUECOLORc { /d 24 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def /is im 0 lb getinterval def /ris im 0 w getinterval def /gis im w w getinterval def /bis im w 2 mul w getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h 8 [w 0 0 h neg 0 h] {w rip pop ris} {gis} {bis} true 3 colorimage bitmapsave restore grestore } bind def /BITMAPTRUECOLOR { gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def /is w string def /gis w string def /bis w string def /cf currentfile def w h 8 [w 0 0 h neg 0 h] { cf is readhexstring pop } { cf gis readhexstring pop } { cf bis readhexstring pop } true 3 colorimage bitmapsave restore grestore } bind def /BITMAPTRUEGRAYc { /d 24 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def /is im 0 lb getinterval def /ris im 0 w getinterval def /gis im w w getinterval def /bis im w 2 mul w getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h 8 [w 0 0 h neg 0 h] {w rip pop ris gis bis w gray} image bitmapsave restore grestore } bind def /ww FMLOCAL /r FMLOCAL /g FMLOCAL /b FMLOCAL /i FMLOCAL /gray { /ww exch def /b exch def /g exch def /r exch def 0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul b i get .114 mul add add r i 3 -1 roll floor cvi put } for r } bind def /BITMAPTRUEGRAY { gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def /is w string def /gis w string def /bis w string def /cf currentfile def w h 8 [w 0 0 h neg 0 h] { cf is readhexstring pop cf gis readhexstring pop cf bis readhexstring pop w gray} image bitmapsave restore grestore } bind def /BITMAPGRAY { 8 {fakecolorsetup} COMMONBITMAP } bind def /BITMAPGRAYc { 8 {fakecolorsetup} COMMONBITMAPc } bind def /ENDBITMAP { } bind def end /ALDsave FMLOCAL /ALDmatrix matrix def ALDmatrix currentmatrix pop /StartALD { /ALDsave save def savematrix ALDmatrix setmatrix } bind def /InALD { restorematrix } bind def /DoneALD { ALDsave restore } bind def /I { setdash } bind def /J { [] 0 setdash } bind def %%EndProlog %%BeginSetup (4.0) FMVERSION 1 1 0 0 612 792 0 1 5 FMDOCUMENT 0 0 /Helvetica FMFONTDEFINE 1 0 /Helvetica-Bold FMFONTDEFINE 2 0 /Times-Roman FMFONTDEFINE 32 FMFILLS 0 0 FMFILL 1 0.1 FMFILL 2 0.3 FMFILL 3 0.5 FMFILL 4 0.7 FMFILL 5 0.9 FMFILL 6 0.97 FMFILL 7 1 FMFILL 8 <0f1e3c78f0e1c387> FMFILL 9 <0f87c3e1f0783c1e> FMFILL 10 FMFILL 11 FMFILL 12 <8142241818244281> FMFILL 13 <03060c183060c081> FMFILL 14 <8040201008040201> FMFILL 16 1 FMFILL 17 0.9 FMFILL 18 0.7 FMFILL 19 0.5 FMFILL 20 0.3 FMFILL 21 0.1 FMFILL 22 0.03 FMFILL 23 0 FMFILL 24 FMFILL 25 FMFILL 26 <3333333333333333> FMFILL 27 <0000ffff0000ffff> FMFILL 28 <7ebddbe7e7dbbd7e> FMFILL 29 FMFILL 30 <7fbfdfeff7fbfdfe> FMFILL %%EndSetup %%Page: "1" 1 %%BeginPaperSize: Letter %%EndPaperSize 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0 0 0 0 1 1 1] [ 0 0 0 1 0 0 0] 9 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K J 0 0 0 1 0 0 0 K 72 18 540 54 R 7 X 0 0 0 1 0 0 0 K V 0 10 Q 0 X (Synchronizing AC waveforms) 72 35.33 T (May 3, 1994 3:26 pm) 72 23.33 T 1 12 Q (1) 533.33 23.33 T %%BeginBinary: 5007 976 348 175.68 62.64 0 69.92 688.72 BEGINBITMAPBWc 9"j"J#B"e" E0A1FO%8007F83FJ"aA#@$B#J" LC0FC00FE007F0003701J#<"J$J# KF00000DFE00017003FJ#>"J" JFE0007O00FJ"?#J$J" JE0007FBFC0000803J"@"J"8"J" J800FBF87F701J#@"J"J# IFE0003E3F7007F:"Z:"A"J"J" 07@F800BF0;3FJ"B"J"8"J" IF07FAE01F81FJ"B"J"CS"8" IE03FD0FF80FJ"B"J"J% IC01FAC08FFC00007J"B"J"J" I800FD076F8J"SJ%J$ K03D800380036FE0003J$>$J$J" I00003FF00007A0007C07FFJ">"J"J# KFFFCF0178001J$?$J&J" HFE0003FF0003@FE000FE0007C0J"@"J#J# J0780C1FF08E000J"@"J":" J0FC0AFC7FJ$A"J%J" HFC001F01@F8003FF88F0J"J"J" O'E0F3F87FJ"J%J" J3FLF0007FFC8F8J"J"8" O(00BFF1FJ$@"J"8$ HF8007FF0AE0FE000FJ%J$ OIC001FFFF8FC003FJ" P 07J#8# OI80038003J$ O'F8007FJ#8#J" OI0007C0016FE<"j>"J"8" FE;FFM0FE0J"J";" HF0MFE00J"8$ OJ1FF0007FJ":" OHFCF8J$:" OHF8003F3FJ" OMFCJ$:" OHF0007F1F>"Z"J$8$ 7F8F8O&E000FFFE000F J#9$ OHC001FF0007J" P 80J#;" OH800303J# P C001J# OH0007J":# OI0FE000J"<" OGFEF0J$<" OGFC001F7FJ" P F8J$<" OGF8003F3FJ$ P FC001FJ$ OGF0007FJ"J":$ O#8FEFFFE000FJ"J"<" O#03CE0FFJ#J"=" O"FE00D0107J$J"=# O"FC007FBC08003J$J# O"F8001FB8003J$J# O"FC000FJC001@"j"G$J#<" E030FFE0003B0007E0J$J"=" O"FF0001C0F00J$J">" O#C0007F@FEF0J$J$>" O#E0003F@FC001F7FJ$J$ O#F8000FIF8003FJ$J$ O#FC0007@F8003FJ$J$ O#FF0001IFC001FA"Z"I#J$>" 0728F8000@F0007F0FJ$J"d O$E0003F?E0J$J" O$F0000FJ07J$J" O$FC0007?C0J$J" O$FF0001J03J$>$J"@" HF8007F800078>8001J$J" O%E00038O/FCJ$J"@" O%F00008>0000J$@" O%FC00007FJ"J">"B"H$ O%FE6FCFE7FF8007FJ#J"B" O%FF80>FC3FJ"?"J"S"J" J3FC0@1FF84F0J"A"A"H$>$J" HFCF03FF8003FFC001F4FFJ"J"J" O&F85F8HE0J"?"J$>$H" J1FFE>F0007FFE000FC0J#>$J"J# O&FF80FE001F4FF=8001J$@$H$<"@$H" HFE000FC0003FF000FFE0FF000700J"@$>"?">#@#G$ J0780001F0FE0C0018003FC0003J"@$<$?"?"J" J0300000FFF0007C003=F0J$?"8">"?">"A#G$ HFF0001FE03018080C001000007J#>"8">#=$>"J"8" J007FF801007FFE000107"8"=$="?"A#>d8" FC7F80000FC000800007F000E0001FJ"=#9">#;%>"@$H" K00E0007F003FFE0000030FF0007F3FJ"8c:"<"8b?$J" IC0FFC0FE001F?7FJ"B#="A"<"B$H" IE00801E007FCF8003FFFJ"B#="A">"J" IF01E03F00F3F>03J"B#="A"<"B$G" IF87F87F81FF8FC001F0FJ"B#="A">"@"I" IFCFFCFFE7F7FFE3FEV"D"A$=#?#<$B"F# FCFE03FFFFFF8001FFF000FF0F03FFJ#@"@"?"="B"H" IFF800FE007E0FF7FJ"@"@"?">"C";W JE03FFC3F0107J"?#@#=#=#B# JFC01FFFFE007FFFFFFFFFFJ#>"B#;# JFFE03FFFC003FFJ#<#CR KFFE01FFFJS L Jb;$@# OMC0001F800FJ"a":#:"="<" O:E007800F00030FJ#<#>">#;" O9FC00003FF0003F07J"e":"e"9">">"?";" HFE07F801E007800703J#H">"=#?";" O%007F0000FE000101J"G"@"<"@#:" O&0FFC7FF8007F00J"G"@"<"A";" O&03F81FE03F7FJ"G"@"<"A";" O&00E00FC01F3FJ"F"@"<"A";" O'3FC007800F1FJ#J"F"@"<"A";" :FFFF91F800300070FJ"J"8"R$;" O'0FAFE0180000307J"F$Q$>"=$9$ O'07000003C000017FFC0001040003J"R"8":U:"<$;%=#:$ J3FFE033FFC0000FC0003FFFF80060001J#G%<#>"?#9$ O$FFF0FE0001FFFF800FE000070000J$G">$:$?";$ O%FE000107E0007FF8001FF080007FJ$E$>">"?$9$ O%FF8000FC000FF03FF8007FC0003FJ"H">"J$ O&C01FF88E0001FJ$F"@":$?";$ O&E0007F3F3FF0007FFCF0000FJ"F$>"J"9$ O&F0F8007FFC43FFC0007J"J"?";$ O(3FBFFFEFE0003J"H"E"G$ O&F8FFE0FF0001J"J# OBFE98000J$J"@"<$ O&FC001FA01FFC0003FJ$ P.E0001FJ"J"H$ O&FEBC0F0000FJ"J$ O(0FO%F80007J"G$ OJ03FC0003J"J$J$ O&FF;FFFFFF7FE0001J#:$ P(FFFFFF0000J"J$ O(07O&80007FJ$ P/C0003FJ"J$ O'80O'E0001FJ$ P/F0000FJ"J$ O97FCF80007J$ P/FC0003J$J$ O7FC003FCFE0001J"J$ O91FCFF0000J"J$ O90FD80007FJ$J$ O7FE0003DC0003FJ"J#J$ >FFH007FCE0001FJ"8"J$ O7FF03CF0000FEe"J$J$ 0FO 000001AF80007J"Jd"8"9`"J$ 907@1F803F#J$ 903LC0007F;FF0001J"J"?"J# 901LE003<8000J"J"?#J$ 900LF0007F;C0007FJ"J"@"J$ :7FKF81F;E0003FJ"J"@"J$ :3FKFE07;F0001FJ"J#?"J$ :1FKFFC003;F8000FJ"J"?"B"a"=$ :0FLFC01801FFC0003J"J#>"J$ :07LFFE000;FE0001J"J#>"J$ :03MFFFE7F:FF0000J"JU;P"J$ :01?F8?80007FJ"J#8"J$ :00O%FFF83F;C0003FJ"J#J$ ;7FO%FFC0=E0001FCZJ$J$ /O&F8001F;F0000FJ"J$ OBFC=F80007J"CQ@$ OBFEFC0003J"J$ OD0F;FE0001J"J$ OBFF=FF0000J$ P380007FJ"J$ OC80=C0003FJ$ P3E0001FJ$ P3F0000FJ$ P3F80007J"J#J$ AFFCF001HFC0003J$ P3FE0001J"J$ OJ016FF0000J$ P4C0007FAjJ"J$ 2800O,E0003FJ"J"J"B$ =7F80FLFEF0001FJ"J#J$ =3FO+E0007F8000FJ"J"J$ =1FH00IFC0007J"J"J"B$ =0F6FEO FCFE0003J"J"J"A"@$ =0781FB7F3FFF0000J"J$?";"A"C$ =03GF8007F00F0F880007FJ"J"J"J$ =016FCD3F7C0003FJ"J"F">$:$?$A$ =0083F3FFE001FF8001FF0007FE0001FJ"J"F$>">"?"C$ >7F5F8FC001FFC0FE0F0000FJ"J"H">"<$?"C$ >3F5F00FF8FC0007C0F80007J"J$F">$<"?$A$ >1F5E0007F07F0003F010000FFFC0003J"J"F$>"<%="D$ >0F5C0FE0001C0FE00007FF8FE0001J"J$F#<%="=$B$ >0750000FF000FFC00007F07000001FF0000@ZJ"G"8#;"="8#;"F$ 54F8FF003F00FF001FC0800000J$F"8a9";"8b8"C" O%80000180FF8003C0J%F"@"<"A"C" O$E0000003C001C007F0Jd8":e8"@"<"A"C" J07E003E00FF8J"F"@"<"A"C" O'0FF007F03FFCJ"F"@"<"A"C" O'1FFC0FF87FFEJ"F"@"<"@#C" O'3FFE3FFE01FFFFJ"F#?"<#?"E" O'FFFFC0FFFF800780J"H">">"?"E" O&03F803F03FC0J"H#=">">#E" O&0FFF803FFF07FFE0J"D"I"<#?"<#F$ EFFFFFC07FFFC01FFFFFFFFJ"J#;"@S;# O%1F4FFF0FFFFFFJW:W;Q;# HFFFF>j" 81FJ" @0FJ" @07J" @03J" @01J" @00J" A7FJ" A3FJ" A1FJ" A0FJ" A07J" A03J" A01J" A00#9"J&;$:";&<$>" 05FFF1FBBF87FFF3FBFFFE1F3FBB873F87FC7FFB6C5FFF5FF8FE0FF07E3F5FFDFFFE7E0FF7703&8"8"8$8#8":"9$8"9":#J&;$:";(:#8#;" 02FFEEFFBDF5F7DBFEFBFF6EBFBFBBBFF7BBFDFBBF:C0FFEEFF77C07FF7E9EEFFAFFFF7FFFDC07FF7BF43"9"8"<":"="H"J&;$:";$9":&<" 05FDEEFF6FFFFF:C5FFDF7F7F803FEFE3DF7F77FF803F27FFFF03"8$8$8%8&9#9#9(8'J08";)9(:" 02BB387F871A61DAECFBC36CF187BC6E3C6EBC611A71971871A71FF1965C69C31F5C0FFBFBF7DD4E38D3FFF001FEE38CBE9BFBF7538F77639E3001F5634E70E3443"9#8$8%8&8$8$8)8'J08";)8*9" 05BDFFBAE9B7C6EEFBBB6EEEBBBFAED7BBAE87BBB787E9BEAAEDEE9AEFEEAAAFA6BAEF5C5FF7F8F7DD35D74DFFE005FDDD755E37F8F74DF7775DDDDFE005F55D377BDD37F03"<%8"<%9#8":):%J.:";)8&8#9" 02E0BAEBF7DAF3BBBC2EB82ABFBF0BF0AA0DE0BF3FAC2EBB3F5C0FF1F1F7DD7E775FFFFA0BFBDE91F1F05D877767DE7FFA0BF75D7D7FF43"<"B%9#=):%J%8"9#;";)9#?" 05EEFDBBBBACBBEABEEBEEAAFDEFBFDFABAEBBDF5C5FF8E3FFBD17FE38E3F75D77767BDFBD17F03':"9";%8$:"<%8"9#J(9$:";#9$9#9";" 02FFEAB3BDBFF6CEEE87BBB2EFBBAAB6EDAEBEEFAEBAEF5C0FFC47F7597DDEAFF7DE9C47F95DDDDEAFFB543'8$8,9#9#81J)8&8";)9(:" 05FFF1CB1E7F871BF9872C71C3FFFE1C71BF1C3E1C751C79BF0BF0BB1E71BF1FFFFC71BAEC2EC31F5C5FFE0FF8E57E38DF5FF0638DDE3E0FF75D863F638E3F5FF763763CE3703$S8S$8$8$8ZJ$P8&8";)9"Q:" 02FFFEBFFFEEFFFFFFFFFFFF05C0FFF1FBFFFFFFFFE9F1FFFFFFFF77FFFFFB43$J"J$="<";":";"@" 05FFFF4F1O#C5FFFBFFE3FB8FFF03"G'8":":#=#J$D";":"F" 02FE03FFFFFFFF8080FE03F80F:C0FFFFE9FFFF43"G#<":":#=#J"F"J" 05FFFFFFFFFFFFFFFF:C5E3;03"J"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"j"F"J" 05O:05E3;03"J"F"J" 02O:00E9;43"J"j"j# 00O:04002:0103"z"z# 0AOKAAA8:AAA843j"j# OL0A:0503"z"z# 05OK5540:AAA043"Z#Z# 03OKEA1F9F503"J#J# 07OKE0BF9F043"J#J# 03OKEA1F9F503"J#J# 07OKE0BF9F043"J#<-=# 03OKEA1FFC38E30DFDDD043FDD8C3063F503"J#<-=# 07OKE0BFFEDDDD75FADD7EDFCD76D7DDF043"J#>%;"=# 03OKEA1FDF75F76BDFF503"J#D"@# 07OKE0BFD5F043"J#>&9#=# 03OKEA1FE30DF7770ED0E3F503"J#>+=# 07OKE0BFFD7DF0777EDFD976D7FDF043"J#@"D# 03OKEA1FF7F503"J#>";"8"=# 07OKE0BFDDDDDDF043"J#<-=# 03OKEA1FFC38E37C1777043FDD8C3063F503"J#EA085FEBE0BE28503"J#J#J' 07O+F8FF>E0A05FF5E05C15043"J"J#J' 03O+E7?EA085FEBE03C28503"J"J#J' 07O+9F?E0A05FF5E01815043"J#J#J' 03O*FE7F?EA085FEBE02828503"E$J#J#J' 07FC0007FFDFF?E0A05FF5E01015043"E$J"J#J' 03FFFBFFFF3@EA085FEBE00028503"J"J#J' 07O*CF@E0A05FF5E00015043"J"J$z& 03O*3F@EA082A5AABE0AAA8503"J#J#z& 07O)FCFF@E0A06555E15555043"J"J#z& 03O)F3AEA086AABE2AAA8503"J"J#z& 07O)CFAE0A16555E55555043"J"J#Z# 03O)3FAEA0F9C503"J#J#J# 07O(FEFFAE0A79D043"J"J#J# 03O(F9BEA0F9C503"J"J#J# 07O(F7BE0A79D043"J"J#j"8# 03O(CFBEA0861FC503"J"J#J"8# 07O(3FBE0A063FD043"J#J#J"8# 03O'FCFFBEA0865FC503"J"J#J"8# 07O'F3CE0A06BFD043"J"J%z$8# 03O'EFCEA08001525544015FC503"J"J%z$8# 07O'9FCE0A000A22AA8A00BFD043"J"J%z$8# 03O'7FCEA08014525505415FC503"J#J%z$8# 07O&FCFFCE0A00AC22AA0BA0BFD043"J"J&Z%8# 03O&FBDEA0817C57F0FE07D55FC503"J"J&G$8# 07O&E7DE0A02FC2FF0BF0BFD043"J"J&G$8# 03O&DFDEA0803C57F07C15FC503"J"J&j$8# 07O&3FDE0A000C28010B00BFD043"J#J&G$8# 03O%FEFFDEA0800050004015FC503"J"J%H$8# 07O%F9EE0A000020800BFD043"J"J%H$8# 03O%F7EEA08000400015FC503"J"J$z"8# 07O%EFEE0A02A5AABFD043"J"J#z"8# 03O%DFEEA086555FC503"J"J#z"8# 07O%BFEE0A06AABFD043"J#J#z"8# 03O$FE7FEEA096555FC503"J#J#j# 07O$FDFFEE0A091043"J"J#z# 03O$F3FEA0A9AAA503"J"J#j" 07O$EFFE080:43"J"J"z" 03O$DFFEA;5503"J"J#j# 07O$BFFE08090443"J#J#z# 03O#FE7FFEA2A9AAA103"J#J#Z# 07O#F9FFFE09F9F443"J"J#J# 03O#E7GEA3F9F103"J"J#J# 07O#DFGE09F9F443"J"J#J# 03O#3FGEA3F9F103"J#J#9#9"8"8(:# 07O"FEFFGE09F8FF9C3E7FDFDDFFDFFF07FF443"J"J#9*9"9#:# 03O"F9HEA3F77FDFFFEFFEDDFFFF7FCFDFFF103"J"J#9";"A"9# 07O"F7HE09F7FFFDFF443"J"J#949# 03O"CFHEA3F7E3DE38C3FED9E30F78DD8E1FD58E18FFDE38FF103"J"J#949# 07O"BFHE09F8DDDDD76FFEDDDD777F5D75DFD575D77FDDDDFF443"J#J#9%8&8$8"9# 03O!FE7FHEA3FF41DC17EDE777785D0975D07FFF103"J#J#9$9'9"<# 07O!FDFFHE09FF5FDDFDFB7777597DD7FF443"J"J#918"9# 03O!F3IEA3F75DDDD76DFEDDDD0F776575DFDD75D77DFF103"J"J#949# 07O!EFIE09F8E38E38F3FC38E37E387D8E1FDD8E18FFDE38FF443"J"J#9R%R"9# 03O!9FIEA3FF7FFFDDFDFF103"J"J#B#="9# 07O!7FIE09FFE3FFFF443"A$J#J#@%A# 03C7FEFB@FCFFIEA3FFFFFFFFFF103"A$J"J#J# 07BBFD75@F3JE09F9F443"B#J"J#J# 03FBAE@CFJEA3F9F103"A"8"J"J#J# 07FBBB?3FJE09F9F443"A"J#J#J# 03F7AFEFFJEA3F9F103"A"J"J#J# 07EFAF9KE09F9F443"A"8"J"J#J# 03DFD7>E7KEA3F9F103"A$J"J#J# 07BFBD75?9FKE09F9F443"A(z":#J# 03831EFBEFF00000O4787FEA3F9F103"A'Z"Z:#J# 07FFBFFFFFFFFB;F9HE09F9F443"B"J"J#J# 03FF?C7LEA3F9F103"J"J#J# 07L3FLE09F9F443"J#J%J# 03KFCFFLEA3FFF7F7F103"J"J+G# 07KF3ME09FFEBFEEFFFBF3FFFBF443"J"J,F# 03K8FMEA3FFDDFEEEFFBFBEFFBF7F103"J#J'8"H# 07JFC7FME09FFBEFEEFFFFF443"J#J,F# 03JE3FFMEA3FF7F7EECF1A7BCF1A61F103"J"J,F# 07J1FO E09FEFF1E0EEE9BBEEE9B7F443"J#J(8"G# 03IF8FFO EA3FE3E3EEEEEBEBF103"J"J%J# 07IC7O!E09FF1C77F443"J#J,F# 03HFE3FO!EA3FF88FEEEF0BBBEF0BB6F103"J#J,F# 07HF1FFO!E09FFC1FEEC7EBB1C7EBB9F443"J"J,F# 03H8FO"EA3FFE3FFFFEEFFFFEEFFFF103"J#J+G# 07GE07FO"E09FFF7FFFFF1FFFFF1FF443"J#J%8"8"G# 03G1FFFO"EA3FFFFFFFFFF103"J#J#J# 07FF8FFO#E09F9F443"J#J#J# 03EFE07O$EA3F9F103"J#J#J# 07EF1FFO$E09F9F443"J#J#J# 03DFC0FO%EA3F9F103"J#J#J# 07DE3FFO%E09F9F443"J#J#J# 03CF81FO&EA3F9F103"J$J#J# 07BF007FFO&E09F9F443"J$J#J# 03A000FFFO'EA3F9F103"J%J#J# 07?F000FFFFO(E09F9F443"F"i#J#J# 03F80FFFO*EA3F9F103"F"ZJ#J# 07FB/O+E09F9F443"J#J# 03OKEA3F9F103"J#J# 07OKE09F9F443"J#J# 03OKEA3F9F103"J%J# 07OKE09FFF7F7F443"J%J# 03OKEA3FFE3F7F103"J(8"G# 07OKE09FFC1FEEFFEF3FF443"J%8"8"G# 03OKEA3FF80FEEBFF103"J%8"J# 07OKE09FF007EF4F443"J,F# 03OKEA3FE003EEA70CF187BC6EF103"J,F# 07OKE09FC00BEE9AEEEEBBBFAEF443"J,F# 03OKEA3FF417EEBAEEF3BBBC2EF103"J%9%F# 07OKE09FFA2FFDBBBBACF443"J%9%F# 03OKEA3FFD5FEE87BBB2F103"J,F# 07OKE09FFEBFF1BB0C71BF1C3EF443"J,F# 03OKEA3FFF7FFFFFFFFFBFFFEEF103"J%<"F# 07OKE09FFFFFF1F443"J#<$F# 03OKEA3FFFFFFFF103"J#J# 07OKE09F9F443"J#J# 03OKEA3F9F103"J#J# 07OKE09F9F443"J#J# 03OKEA3F9F103"J#J# 07OKE09F9F443"J"j":#J# 03O5FC03FEA3F9F103"J#Z:#J# 07O4C0031E09F9F443"J$J#J# 03O3F03FFF5EA3F9F103"J$J#j# 07O2E00FFF6E08090443"J$J#z# 03O1F81FFF7EA2A9AAA903"J#J#j# 07O1C7FF8E08090443"J#J#z# 03O0F03F9EA2A9AAA103"J#J#Z# 07O08FFF9E09F9F443"J#J#J# 03O/FC7F:EA3F9F103"E$J#J#J# 07FC0007KE3FF:E09F9F443"E$J"J#J# 03FFFBFFK1F;EA3F9F103"J#J#9#8"8"8"8$<# 07O.F8FF;E09FFDDF3FF0F9F77FF7F443"J"J#<#8%;";# 03O.C7E09FFDD8778EF8DF77F0E38DF8E1F7F8DF861CE3F443"J"J#9T*:# 03O,3F>EA3FFDFFFF77FFDFFFFFFFF103"F"z":#E"?# 07F8O5787FE09F8FF443"F"Z"Z:#B"8$=# 03FBHF3;EA3FFFFFFFFFF103"J"J#J# 07O+EF?E09F9F443"J"J#J# 03O+9F?EA3F9F103"J"J#J# 07O+7F?E09F9F443"J#J#J# 03O*FEFF?EA3F9F103"J"J#J# 07O*F9@E09F9F443"J"J#J# 03O*E7@EA3F9F103"J"J#J# 07O*9F@E09F9F443"J"J#J# 03O*7F@EA3F9F103"J#J#J# 07O)FCFF@E09F9F443"J"J#J# 03O)FBAEA3F9F103"J"J#:"J# 07O)E7AE09FFE4F443"J"J#:#="A# 03O)DFAEA3FFC7FFBF103"J"J#:&:'<# 07O)3FAE09FF83FFFDE79F5FF8FF7FF7FF443"J#J#:&:(;# 03O(FEFFAEA3FF01FFFAF7DEEFFDFF7F77F7BF103"J"J#:%;#8$;# 07O(F9BE09FE00FFF77DF7FFF7FFBF443"J"J#:#9#8(;# 03O(F7BEA3FC007E377BFBFDD34E70E70F103"J"J#:#9"9(;# 07O(CFBE09F8017DD7F8FDCD377777BF443"J"J#:%8"8%># 03O(BFBEA3FE82FFF07571F1FDDD7F103"J#J#:%;#@# 07O'FE7FBE09FF45FFF778E3FF443"J#J#:#=#;":# 03O'FDFFBEA3FFABFC47F7FF103"J"J#:(8):# 07O'F3CE09FFD7FFF7638E3AFE0FF8DD7630E3CFFF443"J"J#:"Q8"Q;# 03O'EFCEA3FFEF1F103"J"J#:">"A# 07O'9FCE09FFFFBF443"J"J#C"A# 03O'7FCEA3FFFF103"J#J#J# 07O&FCFFCE09F9F443"J"J#J# 03O&F3DEA3F9F103"J"J#J# 07O&CFDE09F9F443"J"J#J# 03O&3FDEA3F9F103"J#J#J# 07O%FEFFDE09F9F443"J"J#J# 03O%F9EEA3F9F103"J"J#J# 07O%F7EE09F9F443"J"J#J# 03O%CFEEA3F9F103"J"J#j# 07O%3FEE08090443"J#J#z# 03O$FCFFEEA2A9AAA903"J"J#j# 07O$F3FE08090443"J"J#z# 03O$CFFEA2A9AAA103"J#J#Z# 07O#FE3FFE09F9F443"A$J#J#J# 03EFFEFBCF1FFFEA3F9F103"A$J"C":"G"F#J# 07D7FD755EF8FBFFDE09F9F443"A$J#J#J# 03BBFBAEBFC7FGEA3F9F103"D"J#J#<.<# 07BBAE3FFGE09F75D0E38C37F77410FF7630C18FF443"J"G"8#D"H"<#<.<# 03:7FFDF81FEFBFEA3F74DB7775D7EB75FB7F35DB5F77F103"J#J#?%;"<# 07O!C7FFHE09F7DD7DDAD7FF443"D"J#J#<#="?# 03D7?FE3FIEA3F755B55F103"A$J$J#?&9#<# 07D7BD75?FC01FFIE09F8C37DDDC3B438FF443"A&j":#=-<# 03EF1EFBEFF0O61FEA3F9B77F5F7C1DDFB7F65DB5FF7F103"A'T"S"S"T"S"S"T$:#A"C# 07FFBFFFFFFFFB7FEFFDBFEFFDBFFFFFE09FDDF443"B"J#=$;"8"<# 03FFO>EA3FDB77757577F103"J#<.<# 07OKE09F8DD0E38DF05DDC10FF7630C18FF443"J"G"H"H"<#$J#J' 07IFEFBBAFFFBFBFF7F@E0885FEBE0BC28443"J"B"J#J' 03K92BF@EA205FF5E15C15103"J/J#J' 07KAAFFF7A71A71C71C71A70C7DFFDF@E0885FEBE0BC28443"J.J#J' 03L1FF79BE9AEBAEBAE9AEBBD83EF@EA205FF5E15C15103"J/J#J' 07KBAFFF7BB0BAECE0BEEBAECFDFFDF@E0885FEBE0BC28443"J'8%J#J' 03MFBBAEBAEF6FBEF7BFFBF@EA205FF5E15C15103"J)J#J' 07O#BAEBAEBAEBBBFF7F@E0885FEBE0BC28443"J0J#J' 03JF1BA0FFDBB0BB1C71C71BB0C77FEFF@EA205FF5E15C15103"JZJ#J' 07I/AE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103j"J' OM885FEBE0BC28443"z"J' 0AOLAA205FF5E15C15103j#J' OL08885FEBE0BC28443"z#J' 05OK5542205FF5E15C15103"Z#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0A028443"J#J' 07OKE2205FF5E14015103"J#J' 03OKE8885FEBE08028443"J#J' 07OKE2205FF5E10015103"J#J' 03OKE8885FEBE00028443"J#J' 07OKE2205FF5E15555103"J#J' 03OKE8885FEBE0AA28443"J#J' 07OKE2205FF5E07E15103"J#J' 03OKE8885FEBE0BE28443"J#J' 07OKE2205FF5E05C15103"J#J' 03OKE8885FEBE03C28443"J#J' 07OKE2205FF5E01815103"J#J' 03OKE8885FEBE02828443"J#J' 07OKE2205FF5E01015103"J#J' 03OKE8885FEBE00028443"J#J' 07OKE2205FF5E00015103"J$z& 03OKE8882A5AABE0AAA8443"J#z& 07OKE2206555E15555103"J#z& 03OKE8886AABE2AAA8443"J#z& 07OKE2216555E55555103"J#Z# 03OKE88F9C443"J#J# 07OKE2279D103"J#J# 03OKE88F9C443"J#J# 07OKE2279D103"J#j"8# 03OKE88861FC443"J#J"8# 07OKE22063FD103"J#J"8# 03OKE88865FC443"J#J"8# 07OKE2206BFD103"J%z$8# 03OKE888001525544015FC443"J%z$8# 07OKE22000A22AA8A00BFD103"J%z$8# 03OKE888014525505415FC443"J%z$8# 07OKE2200AC22AA0BA0BFD103"J&Z%8# 03OKE88817C57F0FE07D55FC443"J&G$8# 07OKE2202FC2FF0BF0BFD103"J&G$8# 03OKE88803C57F07C15FC443"J&j$8# 07OKE22000C28010B00BFD103"J&G$8# 03OKE88800050004015FC443"J%H$8# 07OKE22000020800BFD103"J%H$8# 03OKE888000400015FC443"J$z"8# 07OKE2202A5AABFD103"J#z"8# 03OKE8886555FC443"J#z"8# 07OKE2206AABFD103"J#z"8# 03OKE8896555FC443"J#j# 07OKE22091103"J#z# 03OKE88A9AAA443"J"j# 07OKE2:0103"J#z# 03OKE8D59555443j"j# OL02:0503"z"z# 0AOKAAA8:AAA043j#Z# OL0A1F9F503"z#J# 05OK5540BF9F043j"j#J# I80O"0A1F9F503"z#z#J# 05G55542AO"AAA0BF9F043"Z#Z#J# 00GFE9FO"8A1F9F503"J"J#v#u% 05H3FO"A0BFAABFD5555FFFF043"J"J#v"v% 00H9FO"8A1F553FAA9FFFF503"J"J#v#u% 05H3FO"A0BFAA3FD5551FFFF043"J"J#u#v8# 00H9FO"8A1F55543FAAF503"J"J$T$T"8# 05H3FO"A0BFAFFC3FD7FEF043"J"J$A"B# 00H9FO"8A1F5FAFF503"J"J$A"B# 05H3FO"A0BFAFD7F043"J"J$A"B# 00H9FO"8A1F5FAFF503"J"J&8"8*8$9# 05H3FO"A0BFADDFFDE7F79E7C3FD7F87FFFFCFEF3CFF043"J"J$8$8#8&8$9# 00H9FO"8A1F5DDFFFF7EBDFAFFDBBFFFEFD7BEFF503"J"J$8":"9$:#:# 05H3FO"A0BFADFFDDD7FDBFFBBBF043"J"J+:(<# 00H9FO"8A1F5DD4E19E30F78DDFAFFDB3C61EF1BBF503"J"J*;'=# 05H3FO"A0BFADD35DDDD777F5D7FDBBBAEEFEF043%8%J"J,9"8':# 00FFFE0FFC7FFFFC?9FO"8A1F5DD75DDE777785DFC1AFCEEEF0BBF83BF503%8'J"J$8'9"8':# 05FFFFEFFBBFFFFEFFDF=3FO"A0BFADDFB777759FDDD7F6EEEEB3FBBBF043"8"9"J"J$8&:"8%<# 00DFFFA9FO"8A1F5DDDD0F7765FAFBA1EEECBF503"8+J"J59# 05DC7197FBF1961EF1871F<3FO"8A0BFAE37618E37E387DFDD8E3C3FD7F871C6FC70FBFBB1C7F043"8+J%J59# 00BBAEABFBEEAAEEEEDEEF<9FFFFC1FM88A1F5FFFFFFFF7FFFDDFFFFFFC3FAFFFFFFEFFFFBBFFFFFFF503"8"<$J%J$;#:";"<# 057BE0DE0F<3FFFFFFFMA0BFAFFE3FD7C7F043"?$J"J$9%:"8"8"<# 00EFDEFF<9FO"8A1F5FFFFFFFFFAFFFFFF503%9'J"J$A"B# 05FFFEFBAEAA1EEEDAEF<3FO"A0BFAFD7F043"8+J"J$e#e8# 000C71BBFC71BAFC71E71F<9FO"8A1F503FA8F503"R&J"J$A"B# 05FEFFFFFFFF<3FO"A0BFA0D0F043"J"J$A"B# 00H9FO"8A1F40A0F503"="J"J$A"B# 05FF@3FO"A0BF80C0F043"J"J#Z# 00H9FO"8A1F9F503"J"J#J# 05H3FO"A0BF9F043"J"J#J# 00H9FO"8A1F9F503"J"J#J# 05H3FO"A0BF9F043"J"J#J# 00H9FO"8A1F9F503"J"J#j" 05H3FO"A080:43"J"J"z" 00H9FO"8A;5503"j"j" 04OK20;43"z"z"z" 02HAAD5O"554B;5503j" P:43"z" 0AP9AA83j" P:03 ENDBITMAP %%EndBinary 265.38 195.38 265.38 429.38 2 L 1 H 2 Z N 352.62 195.62 352.62 429.62 2 L N 213.12 198.25 213.12 432.25 2 L N 2 10 Q (A) 210.63 188.87 T (B) 264.38 190.12 T (C) 350.63 188.25 T 72 146 540 470 C 0 0 612 792 C 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "1" 1 %%Page: "2" 2 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0 0 0 0 1 1 1] [ 0 0 0 1 0 0 0] 9 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 72 748.8 540 768.6 R 7 X 0 0 0 1 0 0 0 K V 72 18 540 54 R V 0 10 Q 0 X (Synchronizing AC waveforms) 409.41 35.33 T 1 12 Q (2) 72 23.33 T 0 10 Q (May 3, 1994 3:26 pm) 446.06 23.33 T 72 765.96 539.67 765.96 2 L 1 H 2 Z N 72 751.89 540 751.89 2 L N 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72.33 46 540 46 2 L N 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 72 540 720 R 7 X V 2 12 Q 0 X -0.68 (the middle curve turn on \050time C\051. The top curve is the 50ohm to 5 volt. The start of the turn) 108 712 P -0.56 (on of this curve indicates the start of the turn-off of the pulldown \050time A\051, which is in sync) 108 698 P -0.58 (with the start of the middle curve turn on. So, the start of the middle curve syncs the 50ohm) 108 684 P (to 5 volt and the finish of the middle curve syncs the 50ohm to 0 volt.) 108 670 T 1 F (3. Falling Waveforms.) 72 632 T 2 F (A similar sequence can be seen on the falling waveforms.) 108 606 T 1 F (4. Conclusion) 72 204 T 2 F (All in all it is better to know the synchronization point \050as you can if you are doing) 108 178 T (simulation\051 but baring that you can use this sort of method for synchronizing complete) 108 164 T (separate measurements from the same driver.) 108 150 T (Jon Powell, Quad Design jonp@qdt.com) 108 124 T 0 F (Figure 2:) 175.94 242 T (Falling waveforms into 0V 2.5V and 5V) 229.3 242 T 72 258 540 582 C 72 258 540 582 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 X 0 0 0 1 0 0 0 K %%BeginBinary: 22761 950 650 456 312 0 78 264 BEGINBITMAPBWc j" P:03 J"J" OL08;43"z"z" 05OK5542;AA03"z"Z"Z" 02O:AAA00E9;43"z"F"J" 05O:5545E3;03"Z"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"J"?"<"F"@" 05O:C5FBE3FB03"J$="<";"@"@" 02O:C0FFFBF1E9FBF143$:#:(8"9":#9">#9"J&;$:";&<$>" 05FFF1FBBF87FFF3FBFFFE1F3FBB873F87FC7FFB6C5FFF5FF8FE0FF07E3F5FFDFFFE7E0FF7703&8"8"8$8#8":"9$8"9":#J&;$:";(:#8#;" 02FFEEFFBDF5F7DBFEFBFF6EBFBFBBBFF7BBFDFBBF:C0FFEEFF77C07FF7E9EEFFAFFFF7FFFDC07FF7BF43"9"8"<":"="H"J&;$:";$9":&<" 05FDEEFF6FFFFF:C5FFDF7F7F803FEFE3DF7F77FF803F27FFFF03"8$8$8%8&9#9#9(8'J08";)9(:" 02BB387F871A61DAECFBC36CF187BC6E3C6EBC611A71971871A71FF1965C69C31F5C0FFBFBF7DD4E38D3FFF001FEE38CBE9BFBF7538F77639E3001F5634E70E3443"9#8$8%8&8$8$8)8'J08";)8*9" 05BDFFBAE9B7C6EEFBBB6EEEBBBFAED7BBAE87BBB787E9BEAAEDEE9AEFEEAAAFA6BAEF5C5FF7F8F7DD35D74DFFE005FDDD755E37F8F74DF7775DDDDFE005F55D377BDD37F03"<%8"<%9#8":):%J.:";)8&8#9" 02E0BAEBF7DAF3BBBC2EB82ABFBF0BF0AA0DE0BF3FAC2EBB3F5C0FF1F1F7DD7E775FFFFA0BFBDE91F1F05D877767DE7FFA0BF75D7D7FF43"<"B%9#=):%J%8"9#;";)9#?" 05EEFDBBBBACBBEABEEBEEAAFDEFBFDFABAEBBDF5C5FF8E3FFBD17FE38E3F75D77767BDFBD17F03':"9";%8$:"<%8"9#J(9$:";#9$9#9";" 02FFEAB3BDBFF6CEEE87BBB2EFBBAAB6EDAEBEEFAEBAEF5C0FFC47F7597DDEAFF7DE9C47F95DDDDEAFFB543'8$8,9#9#81J)8&8";)9(:" 05FFF1CB1E7F871BF9872C71C3FFFE1C71BF1C3E1C751C79BF0BF0BB1E71BF1FFFFC71BAEC2EC31F5C5FFE0FF8E57E38DF5FF0638DDE3E0FF75D863F638E3F5FF763763CE3703$S8S$8$8$8ZJ$P8&8";)9"Q:" 02FFFEBFFFEEFFFFFFFFFFFF05C0FFF1FBFFFFFFFFE9F1FFFFFFFF77FFFFFB43$J"J$="<";":";"@" 05FFFF4F1O#C5FFFBFFE3FB8FFF03"G'8":":#=#J$D";":"F" 02FE03FFFFFFFF8080FE03F80F:C0FFFFE9FFFF43"G#<":":#=#J"F"J" 05FFFFFFFFFFFFFFFF:C5E3;03"J"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"J"F"J" 05O:C5E3;03"J"F"J" 02O:C0E9;43"j"F"J" 05O:05E3;03"J"F"J" 02O:00E9;43"J"j"j# 00O:04002:0103"z"z# 0AOKAAA8:AAA843j"j# OL0A:0503"z"z# 05OK5540:AAA043"Z#Z# 03OKEA1F9F503"J#J# 07OKE0BF9F043"J#J# 03OKEA1F9F503"J#J# 07OKE0BF9F043"J#<-=# 03OKEA1FFC38E30DFDDD043FDD8C3063F503"J#<-=# 07OKE0BFFEDDDD75FADD7EDFCD76D7DDF043"J#>%;"=# 03OKEA1FDF75F76BDFF503"J#D"@# 07OKE0BFD5F043"J#>&9#=# 03OKEA1FE30DF7770ED0E3F503"J#>+=# 07OKE0BFFD7DF0777EDFD976D7FDF043"J#@"D# 03OKEA1FF7F503"J#>";"8"=# 07OKE0BFDDDDDDF043"J#<-=# 03OKEA1FFC38E37C1777043FDD8C3063F503"J#E0A05FF5E15C15043"J"J#J' 03O,CF>EA085FEBE0BC28503"J"J#J' 07O,F7>E0A05FF5E15C15043"J"J#J' 03O,F9>EA085FEBE0BC28503"J#J#J' 07O,FE7F=E0A05FF5E15C15043"J#J#J' 03O,FFBF=EA085FEBE0BC28503"J"J#J' 07O-DF=E0A05FF5E15C15043"J"J#J' 03O-E7=EA085FEBE0BC28503"J"J#J' 07O-F9=E0A05FF5E15C15043"J"J#J' 03O-FE=EA085FEBE0BC28503"J#J#J' 07O-FF7F#J' 07O=FFFFE000000FE0A05FF5E15C15043"J):#J' 03O?FFFFFFF00000003FEA085FEBE0BC28503"JP:#J' 07OBE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"J#J' 07OKE0A05FF5E15C15043"J#J' 03OKEA085FEBE0BC28503"F"j"J#J' 07F853FO$E0A05FF5E15C15043"F"Z$J#J' 03FB5C00003O"EA085FEBE0BC28503"J%J#J' 07FFFFFFC00O!E0A05FF5E15C15043"J%J#J' 03HFFFF003FMEA085FEBE0A028503"J$J#J' 07JFFC03FLE0A05FF5E14015043"J$J#J' 03KFFC00FKEA085FEBE08028503"J$J#J' 07LFFF07FJE0A05FF5E10015043"J#J#J' 03MFF9FJEA085FEBE00028503"J"J#J' 07O E0JE0A05FF5E15555043"J#J#J' 03O FF1FIEA085FEBE0AA28503"J"J#J' 07O!E0IE0A05FF5E07E15043"J#J#J' 03O!FF3FHEA085FEBE0BE28503"J"J#J' 07O"C7HE0A05FF5E05C15043"J#J#J' 03O"F83FGEA085FEBE03C28503"J#J#J' 07O"FFCFGE0A05FF5E01815043"J"J#J' 03O#F1GEA085FEBE02828503"J#J#J' 07O#FE7FFE0A05FF5E01015043"J#J#J' 03O#FF83FEA085FEBE00028503"J#J#J' 07O$FC7FEE0A05FF5E00015043"E$J#J$z& 03FC0007@FF9FEEA082A5AABE0AAA8503"E$J"J#z& 07FFFBFFAE7EE0A06555E15555043"J"J#z& 03O%F9EEA086AABE2AAA8503"J"J#z& 07O%FEEE0A16555E55555043"J#J#Z# 03O%FF3FDEA0F9C503"J"J#J# 07O&CFDE0A79D043"J"J#J# 03O&F7DEA0F9C503"J"J#J# 07O&F9DE0A79D043"J#J#j"8# 03O&FE7FCEA0861FC503"J#J#J"8# 07O&FFBFCE0A063FD043"J"J#J"8# 03O'DFCEA0865FC503"J"J#J"8# 07O'EFCE0A06BFD043"J"J%z$8# 03O'F3CEA08001525544015FC503"J"J%z$8# 07O'FDCE0A000A22AA8A00BFD043"J"J%z$8# 03O'FECEA08014525505415FC503"J#J%z$8# 07O'FF7FBE0A00AC22AA0BA0BFD043"J"J&Z%8# 03O(9FBEA0817C57F0FE07D55FC503"J"J&G$8# 07O(EFBE0A02FC2FF0BF0BFD043"J"J&G$8# 03O(F3BEA0803C57F07C15FC503"J"J&j$8# 07O(FCBE0A000C28010B00BFD043"J#J&G$8# 03O(FF7FAEA0800050004015FC503"J"J%H$8# 07O)BFAE0A000020800BFD043"J%H$8# 03OKEA08000400015FC503"J"J$z"8# 07O)DFAE0A02A5AABFD043"J"J#z"8# 03O)E7AEA086555FC503"J"J#z"8# 07O)FBAE0A06AABFD043"J"J#z"8# 03O)FDAEA096555FC503"J"J#j# 07O)FEAE0A091043"J#J#z# 03O)FF3F@EA0A9AAA503"J"J#j" 07O*DF@E080:43"J"J"z" 03O*EF@EA;5503"J"J#j# 07O*F7@E08090443"J"J#z# 03O*F9@EA2A9AAA103"J"J#Z# 07O*FE@E09F9F443"J#J#J# 03O*FF3F?EA3F9F103"J"J#J# 07O+DF?E09F9F443"J"J#J# 03O+EF?EA3F9F103"J#9#9"8"8(:# 07OKE09F8FF9C3E7FDFDDFFDFFF07FF443"J"J#9*9"9#:# 03O+F7?EA3F77FDFFFEFFEDDFFFF7FCFDFFF103"J"J#9";"A"9# 07O+F9?E09F7FFFDFF443"J"J#949# 03O+FE?EA3F7E3DE38C3FED9E30F78DD8E1FD58E18FFDE38FF103"J#J#949# 07O+FF7F>E09F8DDDDD76FFEDDDD777F5D75DFD575D77FDDDDFF443"J"J#9%8&8$8"9# 03O,BF>EA3FF41DC17EDE777785D0975D07FFF103"J"J#9$9'9"<# 07O,CF>E09FF5FDDFDFB7777597DD7FF443"J"J#918"9# 03O,F7>EA3F75DDDD76DFEDDDD0F776575DFDD75D77DFF103"J"J#949# 07O,FB>E09F8E38E38F3FC38E37E387D8E1FDD8E18FFDE38FF443"J"J#9R%R"9# 03O,FD>EA3FF7FFFDDFDFF103"J#J#B#="9# 07O,FE7F=E09FFE3FFFF443"J#J#@%A# 03O,FFBF=EA3FFFFFFFFFF103"J"J#J# 07O-DF=E09F9F443"J"J#J# 03O-EF=EA3F9F103"J"J#J# 07O-F3=E09F9F443"J"J#J# 03O-FD=EA3F9F103"J"J#J# 07O-FE=E09F9F443"A$J#J#J# 03C7FEFBMFF7F# 03O%EFEEA3FE82FFF07571F1FDDD7F103"J"J#:%;#@# 07O%F3EE09FF45FFF778E3FF443"J"J#:#=#;":# 03O%FCEEA3FFABFC47F7FF103"J#J#:(8):# 07O%FF7FDE09FFD7FFF7638E3AFE0FF8DD7630E3CFFF443"J"J#:"Q8"Q;# 03O&BFDEA3FFEF1F103"J"J#:">"A# 07O&CFDE09FFFFBF443"J"J#C"A# 03O&F7DEA3FFFF103"J"J#J# 07O&F9DE09F9F443"J#J#J# 03O&FE7FCEA3F9F103"J#J#J# 07O&FFBFCE09F9F443"J"J#J# 03O'DFCEA3F9F103"J"J#J# 07O'EFCE09F9F443"J"J#J# 03O'F3CEA3F9F103"J"J#J# 07O'FDCE09F9F443"J#J#J# 03O'FE7FBEA3F9F103"J#J#j# 07O'FF9FBE08090443"J"J#z# 03O(EFBEA2A9AAA903"J"J#j# 07O(F7BE08090443"J"J#z# 03O(FBBEA2A9AAA103"J"J#Z# 07O(FCBE09F9F443"J#J#J# 03O(FF7FAEA3F9F103"J"J#J# 07O)9FAE09F9F443"J"J#J# 03O)E7AEA3F9F103"J"J#<.<# 07O)FBAE09F75D0E38C37F77410FF7630C18FF443"J"J#<.<# 03O)FCAEA3F74DB7775D7EB75FB7F35DB5F77F103"J#J#?%;"<# 07O)FF3F@E09F7DD7DDAD7FF443"J"J#<#="?# 03O*DF@EA3F755B55F103"J"J#?&9#<# 07O*E3@E09F8C37DDDC3B438FF443"J#J#=-<# 03O*FC7F?EA3F9B77F5F7C1DDFB7F65DB5FF7F103"J#J#A"C# 07O*FF9F?E09FDDF443"J"J#=$;"8"<# 03O+EF?EA3FDB77757577F103"A$J"J#<.<# 07EFFEFBKF0?E09F8DD0E38DF05DDC10FF7630C18FF443"A$H"D"?#:"E"?#E09F9F443"D"J#J#J# 03BBKF83F=EA3F9F103"J#J#J# 07O,FFC1=E09F9F443"J"E"D"9#@"G#j# 038EF7FFDFE01EFEA2091103"D"J%J#z# 07D7LFFFE007F:E08A9AA8443"A$J(J#j& 03D7BD75O FFFF800000000F6EA2061E00001103"A&j9j":#J"8# 07EF1EFBEFF0O!21FE08863E0443"A'R"R"R"Q"R"R"R"R"P:#J"8# 03FFBFFFFFFFFBEFDF7FFEFDF7EFBFEA2065E5103"B"J#J"8# 07FFO>E0886BE8443"J$Z& 03OKEA207F55E00015103"J#J' 07OKE0885FEBE00828443"J"E"D"E"G#J' 038FFFFFFFFEA205FF5E01015103"J#J' 07OKE0885FEBE02828443"J#J' 03OKEA205FF5E01815103"F"E"D"E"E"?(8%@' 07FFFFFFFFFFE08870410DDFE3DD04107FFEBE03C28443"J(8$A' 03OKEA207DDF75DFDDCD7F7FFF5E05C15103"J#8#;#@' 07OKE088749F7EFFFEBE0BE28443"J#8$8$A' 03OKEA20755FFDD57F7DFF5E07E15103"J-A' 07OKE0887DC30D5FFBFC1FD50F78FEBE08028443"J.@' 03OKEA207DDF5DDFF7FFFFD97F7F7FFF5E10015103"J#8$F' 07OKE0886DDFEFFEBE00028443"J#8$8$A' 03OKEA2075DFDFDD7F77FF5E15555103"J%8"9$@' 07OKE0887DC1C10778FFFEBE0AAA8443"J(8$A' 03OKEA207FFFFFFFFFFFFFFFFF5E15515103"J#J' 07OKE0885FEBE0AA28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J(8$A' 07OKE08870410DDFE3DD0418FEBE0BC28443"J(8%@' 03OKEA207DDF75DFDDCD7F777FFF5E15C15103"J#8#G' 07OKE088749FFEBE0BC28443"D&A%A&A%B%>#8$8$A' 03FEE3FC107F83BFF183FC1DFF041FE0EFFC60077FC107EA20755FFDD57F7FFF5E15C15103"E%A%A&A%B%>.@' 07DDFFD7FFBF5FEEBFFDFAFFF5FFEFCFFBAF7E7FFD7FE0887DC30D5FFBFC1FD50F7EFFFEBE0BC28443"D"8"B#D$C"D$?-A' 03FCB7BEEFF77FEDAF7D7FFBEA207DDF5DDFF7FFFFD97F7DFF5E15C15103"D"8"B%B"8"A%B"8">#8$:"A' 07FAB4A6EFFEA7373FE9EFFFA94F4FE0886DDFEF7BFEBE0BC28443"E%A%A&A"8"B%>#8$8$A' 03E1FF737F9AEFFD9BFCD77FDCDFE666377FF737EA2075DFDFDD7F77FF5E15C15103"D%B%A"8"B%B"8">%8"9$@' 07F6FDFF7FFAEFFBFBFFDFFEEFFEFEF7F7E0887DC1C107707FFEBE0BC28443"D%D"E"D"E"?(8%@' 03F07DFEFFF7BFFDEFEA207FFFFFFFFFFFFFFFFFFF5E15C15103"D%B%A%B%B%>#J' 07FEDDDEF7BB5EEFBBFDDAF7BDEEEFBBEE777DEF77E0885FEBE0BC28443"E%A%A&A%B%>#J' 03E38EF8FFC7BC60C7FE3DE3BE3FF18318318C18EF8FEA205FF5E15C15103"D%B%A&A%B%>#J' 07FFFFDFFFFFFEFFFFFFFFF7FFFFFFFFBFFFFFFDFFFFE0885FEBE0BC28443"F"D"E"E"D"@#J' 03FFFFFFFFFFEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J(8$A' 07OKE08870410DDFF7DD041DFEBE0BC28443"J(8$A' 03OKEA207DDF75DFE7CD7F79FF5E15C15103"J#8$:"A' 07OKE088749FD775FEBE0BC28443"J#8$8$A' 03OKEA20755FF7D57F7DFF5E15C15103"J&8%B' 07OKE0887DC30DFC1FD50FFEBE0BC28443"J,B' 03OKEA207DDF5DDFF7FFFFD97FFF5E15C15103"J#8"H' 07OKE0886DFEBE0BC28443"J#8":"C' 03OKEA2075DDFF5E15C15103"J%8"9$@' 07OKE0887DC1C107707FFEBE0BC28443"J(8%@' 03OKEA207FFFFFFFFFFFFFFFFFFF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J&=$J#J' 07IF831BA0FFDEFF7FEAE0885FEBE0BC28443"J&>$J#J' 03IFEFBBAFFFBFBFF7F@EA205FF5E15C15103"J"B"J#J' 07K92BF@E0885FEBE0BC28443"J/J#J' 03KAAFFF7A71A71C71C71A70C7DFFDF@EA205FF5E15C15103"J.J#J' 07L1FF79BE9AEBAEBAE9AEBBD83EF@E0885FEBE0BC28443"J/J#J' 03KBAFFF7BB0BAECE0BEEBAECFDFFDF@EA205FF5E15C15103"J'8%J#J' 07MFBBAEBAEF6FBEF7BFFBF@E0885FEBE0BC28443"J)J#J' 03O#BAEBAEBAEBBBFF7F@EA205FF5E15C15103"J0J#J' 07JF1BA0FFDBB0BB1C71C71BB0C77FEFF@E0885FEBE0BC28443"JZJ#J' 03I/AEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103"J#J' 07OKE0885FEBE0BC28443"J#J' 03OKEA205FF5E15C15103j"J' OM885FEBE0BC28443"z"J' 0AOLAA205FF5E15C15103j#J' OL08885FEBE0BC28443"z#J' 05OK5542205FF5E15C15103"Z#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0BC28443"J#J' 07OKE2205FF5E15C15103"J#J' 03OKE8885FEBE0A028443"J#J' 07OKE2205FF5E14015103"J#J' 03OKE8885FEBE08028443"J#J' 07OKE2205FF5E10015103"J#J' 03OKE8885FEBE00028443"J#J' 07OKE2205FF5E15555103"J#J' 03OKE8885FEBE0AA28443"J#J' 07OKE2205FF5E07E15103"J#J' 03OKE8885FEBE0BE28443"J#J' 07OKE2205FF5E05C15103"J#J' 03OKE8885FEBE03C28443"J#J' 07OKE2205FF5E01815103"J#J' 03OKE8885FEBE02828443"J#J' 07OKE2205FF5E01015103"J#J' 03OKE8885FEBE00028443"J#J' 07OKE2205FF5E00015103"J$z& 03OKE8882A5AABE0AAA8443"J#z& 07OKE2206555E15555103"J#z& 03OKE8886AABE2AAA8443"J#z& 07OKE2216555E55555103"J#Z# 03OKE88F9C443"J#J# 07OKE2279D103"J#J# 03OKE88F9C443"J#J# 07OKE2279D103"J#j"8# 03OKE88861FC443"J#J"8# 07OKE22063FD103"J#J"8# 03OKE88865FC443"J#J"8# 07OKE2206BFD103"J%z$8# 03OKE888001525544015FC443"J%z$8# 07OKE22000A22AA8A00BFD103"J%z$8# 03OKE888014525505415FC443"J%z$8# 07OKE2200AC22AA0BA0BFD103"J&Z%8# 03OKE88817C57F0FE07D55FC443"J&G$8# 07OKE2202FC2FF0BF0BFD103"J&G$8# 03OKE88803C57F07C15FC443"J&j$8# 07OKE22000C28010B00BFD103"J&G$8# 03OKE88800050004015FC443"J%H$8# 07OKE22000020800BFD103"J%H$8# 03OKE888000400015FC443"J$z"8# 07OKE2202A5AABFD103"J#z"8# 03OKE8886555FC443"J#z"8# 07OKE2206AABFD103"J#z"8# 03OKE8896555FC443"J#j# 07OKE22091103"J#z# 03OKE88A9AAA443"J"j# 07OKE2:0103"J#z# 03OKE8D59555443j"j# OL02:0503"z"z# 0AOKAAA8:AAA043j#Z# OL0A1F9F503"z#J# 05OK5540BF9F043j"j#J# I80O"0A1F9F503"z#z#J# 05G55542AO"AAA0BF9F043"Z#Z#J# 00GFE9FO"8A1F9F503"J"J#v#u% 05H3FO"A0BFAABFD5555FFFF043"J"J#v"v% 00H9FO"8A1F553FAA9FFFF503"J"J#v#u% 05H3FO"A0BFAA3FD5551FFFF043"J"J#u#v8# 00H9FO"8A1F55543FAAF503"J"J$T$T"8# 05H3FO"A0BFAFFC3FD7FEF043"J"J$A"B# 00H9FO"8A1F5FAFF503"J"J$A"B# 05H3FO"A0BFAFD7F043"J"J$A"B# 00H9FO"8A1F5FAFF503"J"J&8"8*8$9# 05H3FO"A0BFADDFFDE7F79E7C3FD7F87FFFFCFEF3CFF043"J"J$8$8#8&8$9# 00H9FO"8A1F5DDFFFF7EBDFAFFDBBFFFEFD7BEFF503"J"J$8":"9$:#:# 05H3FO"A0BFADFFDDD7FDBFFBBBF043"J"J+:(<# 00H9FO"8A1F5DD4E19E30F78DDFAFFDB3C61EF1BBF503"J"J*;'=# 05H3FO"A0BFADD35DDDD777F5D7FDBBBAEEFEF043%8%J"J,9"8':# 00FFFE0FFC7FFFFC?9FO"8A1F5DD75DDE777785DFC1AFCEEEF0BBF83BF503%8'J"J$8'9"8':# 05FFFFEFFBBFFFFEFFDF=3FO"A0BFADDFB777759FDDD7F6EEEEB3FBBBF043"8"9"J"J$8&:"8%<# 00DFFFA9FO"8A1F5DDDD0F7765FAFBA1EEECBF503"8+J"J59# 05DC7197FBF1961EF1871F<3FO"8A0BFAE37618E37E387DFDD8E3C3FD7F871C6FC70FBFBB1C7F043"8+J%J59# 00BBAEABFBEEAAEEEEDEEF<9FFFFC1FM88A1F5FFFFFFFF7FFFDDFFFFFFC3FAFFFFFFEFFFFBBFFFFFFF503"8"<$J%J$;#:";"<# 057BE0DE0F<3FFFFFFFMA0BFAFFE3FD7C7F043"?$J"J$9%:"8"8"<# 00EFDEFF<9FO"8A1F5FFFFFFFFFAFFFFFF503%9'J"J$A"B# 05FFFEFBAEAA1EEEDAEF<3FO"A0BFAFD7F043"8+J"J$e#e8# 000C71BBFC71BAFC71E71F<9FO"8A1F503FA8F503"R&J"J$A"B# 05FEFFFFFFFF<3FO"A0BFA0D0F043"J"J$A"B# 00H9FO"8A1F40A0F503"="J"J$A"B# 05FF@3FO"A0BF80C0F043"J"J#Z# 00H9FO"8A1F9F503"J"J#J# 05H3FO"A0BF9F043"J"J#J# 00H9FO"8A1F9F503"J"J#J# 05H3FO"A0BF9F043"J"J#J# 00H9FO"8A1F9F503"J"J#j" 05H3FO"A080:43"J"J"z" 00H9FO"8A;5503"j"j" 04OK20;43"z"z"z" 02HAAD5O"554B;5503j" P:43"z" 0AP9AA83j" P:03 ENDBITMAP %%EndBinary 229.13 295.88 229.13 529.88 2 L 1 H 2 Z N 317.75 291 317.75 525 2 L N 379.5 293.62 379.5 527.62 2 L N 1 12 Q (D) 236.25 296.37 T (E) 325 294.5 T (F) 385.63 298.87 T 72 258 540 582 C 0 0 612 792 C 0 0 0 1 0 0 0 K FMENDPAGE %%EndPage: "2" 2 %%Trailer %%BoundingBox: 0 0 612 792 %%PageOrder: Ascend %%Pages: 2 %%DocumentFonts: Helvetica %%+ Helvetica-Bold %%+ Times-Roman %%EOF From Derrick_Duehren@ccm2.jf.intel.com Wed May 4 21:23:41 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03752; Wed, 4 May 94 21:23:41 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0pyuuo-000MNVC; Wed, 4 May 94 21:20 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 4 May 94 21:20:02 PST Date: Wed, 4 May 94 21:20:02 PST From: Derrick Duehren Message-Id: <940504212002_1@ccm.hf.intel.com> To: Jerry_Budelman@ccm2.jf.intel.com, Randy_L_Wilhelm@ccm.fm.intel.com, IBIS@vhdl.org Subject: IBIS: 4/29 Minutes Text item: Text_1 Date: May 4, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum 4/29/94 To: Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Kumar* Contec Maah Sango, Clark Cochran Digital Equipment Corp. Barry Katz* High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* IBM Jay Diepenbrock IBM-Motorola alliance Lynn Warriner, Hoa Quoc*, John Burnett Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, D. Duehren*, R. Rosenbaum* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Mei Wong, Mei-Ling Wei MicroSim Arthur Wong, Jerry Brown, Graham Bell National Semiconductor Syed Huq* North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell* Quantic Labs Mike Ventham, Zhen Mu Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl* CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by * Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 5/13/94 (415) 904-8944 721619 5/20/94 Face-to-face, editing committee 5/27/94 (415) 904-8800 744468 All meetings are 8:00 AM to 10:00 AM PST (15:00 to 17:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org) send e-mail to ibis-request@vhdl.org. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ 4/15/94 Meeting Agenda ---------------------- Check-in Intros of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues All Opens for new issues All New models available All IBIS 2.0 Ratification/DAC/Other 2.0 Issues Hobbs - Birds of a Feather session (6/8) - Rev 2.0 Ratification Summit (6/9) - Levels of support (see 12/3/93 discussion) IBIS Cookbook Hobbs, Rosenbaum BIRD 8, Spec. of V/I data monotonicity Crisafulli BIRD 9.2, Terminator Specification Ross BIRD 10, Coupling effects in package models Bracken BIRD 11, Sign of current checking Hobbs, All BIRD 12, Non-Linear Ramps Peters BIRD 2, VIH, VIL Thresholds for Inputs Powell Egg 3, Simulation temperatures Ward The rest of the nest (Eggs 4, 5...) All Wrap-up, Next Meeting Plans Hobbs ------------------------------------------------------------------------ 1. Intros of new IBIS participants New participants: None. 2. Review of Pervious Meeting's Minutes The following correction was made to last month's minutes: In item 12, "Bob W." should be "Bob R." 3. Miscellany/Announcements Barry believes ad-hoc nature of ibis forum causes problems for DEC. He prefers $500 dues, rather than a source license (easier for corporations to justify). Will gave a short history of the Golden Parser licensing. We will discuss this issue at the ratification meeting. IBIS is mentioned briefly in Steve Ohr's column in Computer Design, April 1994, pg. 112. The vhdl.org \birds directory is up-to-date as of 5/3/94. 4. Opens for new issues BIRDs 13 and 14 added to the agenda. 5. New models available The IntelDX4(TM) processor and Pentium(TM) processor-to-PCI bridge component IBIS files have been posted to vhdl.org. 6. IBIS 2.0 Ratification/DAC - May 20 Editing Committee AR Derrick: Get room, time, hotel info out to May 20 participants within next week. DONE The agenda for the ratification meeting will be published after the May 20 meeting. Old AR Will: Engage Paul Munsey after 5/20 for parsability study of the proposed version 2.0 to minimize a need for a version 2.1 soon after 2.0. - Rev 2.0 Ratification Summit (6/9/94) Kumar has arranged a room near the conference center for 30 to 40 people. - Birds of a Feather session (6/8/94) No discussion. Arrangements are made for a Marriott room. - Levels of support (see 12/3/93 discussion) Will be discussed at the ratification meeting. 9. IBIS Cookbook Robin Rosenbuam (an Intel Technical Writer) led a short discussion of the cookbook. Kellee and Jon received and reviewed copies, and will be giving Robin their comments. Will asked for volunteers to create new examples for the book; no one volunteered. Hoa Quoc requested a review copy. Robin later tried to send it to an email address Hoa provided, but the address failed. AR Hoa: Call Robin at (503) 696-4554 to make arrangements. Also please provide name, address, phone number, etc. to Derrick for the Roster document. 11. BIRD 8, Spec. of V/I data monotonicity We need resolution to Jon and Arpad's disagreement. Originally, the forum requested that IBIS require monotonicity of data, which Kellee codified in BIRD 8 and later revised to only require one monotonic axis. Most of the discussion revolved around what is and is not monotonic. Non-zero? Non-slope changing? No change in sign of slope? Slope going to zero? We concluded that zero slope is OK, we can allow "flat spots", and could issue a warning for non compliance. Jon feels nonmonotonic behavior can only take place in the presence of feedback, which implies delay, which IBIS doesn't describe. Some simulator vendors currently filter out non-monotonic data. Will proposed: Require monotonic data on at least one axis. Simulators can issue a warning message to customers if data on the other axis is monotonic. Customers can put whatever they want in the model. It would be very difficult to have the GP do the filtering. We can put a guideline/note in the spec.: "If you have non-monotonic data, some simulators will convert it to monotonic data." Simulator vendors are responsible for warning user how it will be handled (e.g., filtered out). Barry wants an example of a nonmonotonic transistor. Arpad said the irf50 CMOS transistor is an example. AR Kellee: Update BIRD 8 per this discussion. 12. BIRD 9, Other model types Vote taken: Approved unanimously with the Model_type name changes from "Discrete" to "Terminator". AR Bob R.: Update the approved BIRD and post to the reflector. 13. BIRD 10, Coupling effects in package models Digital and TI have this data and will likely make it available under this BIRD. Vote taken: Approved unanimously. 14. BIRD 11, Sign of current checking Vote taken: Approved unanimously. 15. BIRD 12, Non-linear Ramps Stephen Peters clarified some misunderstandings, proposed a few additions to the BIRD. We need to be able to optionally override the package parameters. Kellee suggested allowing R_pkg, etc., to be overridden. He suggested naming the sub-parameters the same as for the package with _dut suffix. Also add a drawing. The end point of the waveform must line up with the steady DC state current, according to the discussion. However, measurement errors will inevitably prevent the steady, DC states to not line up. This is the model creator's problem. Bob Ward recommends that we add a steady-state agreement as part of the measurement guideline. Kellee suggested limiting the table length to 100 entries, others agreed. We discussed supporting more complex loads, and concluded no one would trust the reference waveforms in the model into anything but fairly simple loads, due to low quality transmission line models in older simulators. The consensus is to keep only simple r, l, c loads, not topologies such as the PCI speedway. Jon: We need to figure out a way to sync up the curves -- VT curves in different tables, the starting point or some point has to be able to correlate the waveforms in time. Jon proposed that we create 2 pictures for forum review, one to sync curves, one to ??? AR Stephen: Reissue the BIRD per this discussion. Revise names, add c_dut, l_dut, r_dut, Set max of 100 data points in the table, set character limits, and add a schematic showing where these elements go. DONE 16. BIRD 2, VIH, VIL Thresholds for Inputs Vote taken: Approved unanimously. 17. BIRD 13, Simulation temperatures Bob W. put this BIRD out to get discussion going. This BIRD could migrate into a simple wording-fix BIRD for the IBIS specification. It clarifies that temperatures are die temperatures, not ambient. Also, bjt min and max are backwards. AR Will: Send note to Bob W. with suggested wording change to Version 1.1 spec. Discussion to continue via the reflector. 18. The rest of the nest (Eggs 4, 5..., BIRD 14) No discussion. 19. Wrap-up, Next Meeting Plans Next meeting is 5/13/94. From ventham@quantic.mb.ca Thu May 5 12:58:56 1994 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14252; Thu, 5 May 94 12:58:56 PDT Received: by access.mbnet.mb.ca with UUCP id AA01202 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 5 May 1994 14:57:36 -0500 Received: from gauss by quantic.mb.ca (4.1/SMI-4.1) id AA15536; Thu, 5 May 94 14:44:04 CDT Received: by gauss (4.1/SMI-4.1) id AA01769; Thu, 5 May 94 14:44:02 CDT From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9405051944.AA01769@gauss> Subject: Flock of Birds in Rev 2.0 To: ibis@vhdl.org (IBIS Forum) Date: Thu, 5 May 94 14:43:59 CDT X-Mailer: ELM [version 2.3 PL11] Gentle IBIS folk, Given that there is to be a ratification meeting at DAC of version 2.0, when will the first version 2.0 specification be issued incorporating all the approved (cooked?) birds in with the V2.0 spec? Looking forward to seeing you at the meeting to turn birds into rats at DAC. Mike -- +=============================================================================+ | Mike Ventham Vice President Engineering | | Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email ventham@quantic.mb.ca | +=============================================================================+ From bward@sugar.NeoSoft.COM Thu May 5 13:36:04 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14658; Thu, 5 May 94 13:36:04 PDT Received: by sugar.NeoSoft.COM id AA21765 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 5 May 1994 15:33:13 -0500 Message-Id: <199405052033.AA21765@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Student Pspice Date: Thu, 5 May 94 15:33:10 CDT During the last forum meeting someone mentioned the student version of PSPICE. It was also mentioned that it was available fpor legitimate copying. Anyone care to say from where it cna be obtained? Is it on the i'net somewhere to be copied or only available by mail order? Any insight appreciated! Thanks, Bob Ward bward@neosoft.com or bward@dadhb1.ti.com From Will_Hobbs@ccm2.jf.intel.com Thu May 5 13:42:15 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14664; Thu, 5 May 94 13:42:15 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 5 May 94 13:39:06 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Thu, 5 May 94 13:38:35 -0700 Received: from ccMail by jfsmt2.intel.com id AA768170331 Thu, 05 May 94 13:38:51 PDT Date: Thu, 05 May 94 13:38:51 PDT From: "Hobbs, Will" Message-Id: <9404057681.AA768170331@jfsmt2.intel.com> To: ibis@vhdl.org (IBIS Forum), ventham@quantic.mb.ca (Mike Ventham) Subject: Re: Flock of Birds in Rev 2.0 Mike, There is an editing session in Oregon on May 20 to roll up all the passed birds into a draft of IBIS V2.0. Within a few days of this, the roll-up will be posted to the reflector. Will Gentle IBIS folk, Given that there is to be a ratification meeting at DAC of version 2.0, when will the first version 2.0 specification be issued incorporating all the approved (cooked?) birds in with the V2.0 spec? Looking forward to seeing you at the meeting to turn birds into rats at DAC. Mike -- +=============================================================================+ | Mike Ventham Vice President Engineering | | Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email ventham@quantic.mb.ca | +=============================================================================+ From Will_Hobbs@ccm2.jf.intel.com Thu May 5 14:07:37 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14848; Thu, 5 May 94 14:07:37 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 5 May 94 14:05:10 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Thu, 5 May 94 14:04:46 -0700 Received: from ccMail by jfsmt2.intel.com id AA768171905 Thu, 05 May 94 14:05:05 PDT Date: Thu, 05 May 94 14:05:05 PDT From: "Hobbs, Will" Message-Id: <9404057681.AA768171905@jfsmt2.intel.com> To: ibis@vhdl.org Subject: IBIS in COMPUTER DESIGN IBISers, Bob Ross sent this notice to Derrick and me. I thought you all would be interested. Will Will and Derrick IBIS is mentioned briefly in Steve Ohr's column in Computer Design, April 1994, pg 112. Bob Ross Interconnectix, Inc. From bward@sugar.NeoSoft.COM Thu May 5 15:30:37 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15459; Thu, 5 May 94 15:30:37 PDT Received: by sugar.NeoSoft.COM id AA26500 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 5 May 1994 17:27:08 -0500 Message-Id: <199405052227.AA26500@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: BOF at DAC Date: Thu, 5 May 94 17:27:05 CDT All - I have just finished a conversation with the folks at the DAC office about the arrangements for the BOF session at DAC. All is in line and ready ( he says bravely! ), but I got corrected on one thing. And this is from the final arbitor of these matters All the folks interested in attending, escpially the 11 of us ( myself included ) who have expressed interest in being there need to sign up at the information desk at DAC registration. I had previously been lead to believe that I could collect the names and pass them to the DAC folk, but not so. I will still be arriving early, and so we should be set up for the registration right from the start. Thanks, Bob bward@neosoft.com or bward@dadhb1.ti.com From jonp@qdt.com Thu May 5 17:47:26 1994 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16517; Thu, 5 May 94 17:47:26 PDT Received: from uucp1.uu.net by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwoqk16122; Thu, 5 May 94 20:44:59 -0400 Received: from qdt.UUCP by uucp1.uu.net with UUCP/RMAIL ; Thu, 5 May 1994 20:45:00 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01093; Thu, 5 May 94 16:22:47 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA09137; Thu, 5 May 94 16:22:46 PDT Date: Thu, 5 May 94 16:22:46 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9405052322.AA09137@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA05934; Thu, 5 May 94 16:22:46 PDT To: uunet!sugar.NeoSoft.Com!bward@uunet.UU.NET Cc: ibis@vhdl.org In-Reply-To: Bob Ward's message of Thu, 5 May 94 17:27:05 CDT <199405052227.AA26500@sugar.NeoSoft.COM> Subject: BOF at DAC re: registration Will they let us register if we are merely lowlife Exhibitors? (or Exhibitionists as they used to say). jonp From bward@sugar.NeoSoft.COM Thu May 5 18:21:10 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16720; Thu, 5 May 94 18:21:10 PDT Received: by sugar.NeoSoft.COM id AA08339 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 5 May 1994 20:18:15 -0500 Message-Id: <199405060118.AA08339@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: BOF at DAC Registration Date: Thu, 5 May 94 20:18:11 CDT All - As far as I understand it the genral public is welcome to sign up for the BOF sessions. All you need is appropriate interest. Yes, even the Exhibitionists are welcome :-) !!! See Jon's letter for context! Got to be some kind of bird related reference here, but it escapes me. Sigh! So com'on now, y'all, y'hear?!! Bob Ward bward@neosoft.com or bward@dadhb1.ti.com From bob@icx.com Fri May 6 10:57:55 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25625; Fri, 6 May 94 10:57:55 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02152 for ; Fri, 6 May 94 13:21:26 -0400 Date: Fri, 6 May 94 10:17:21 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18278; Fri, 6 May 94 10:17:21 PDT Message-Id: <9405061717.AA18278@icx.com> To: ibis@vhdl.org Subject: VERSION1.1Y 4 OF 4 5.00V 0.00pA NA NA -> V/I table increasing (0 > -680) [Pullup] | Voltage I(typ) I(min) I(max) -5.00V 38.14mA 27.33mA 54.76mA -4.50V 37.49mA 26.87mA 53.79mA -1.00V 17.13mA 12.81mA 23.55mA -0.50V 9.26mA 6.96mA 12.66mA 0.00V 13.57pA 613.51pA 11.04pA 100.00mV -1.96mA -1.48mA -2.67mA 200.00mV -3.87mA -2.92mA -5.27mA 500.00mV -9.26mA -6.96mA -12.66mA 1.80V -26.79mA -19.79mA -37.25mA 1.90V -27.74mA -20.46mA -38.64mA 4.60V -37.62mA -26.97mA -54.00mA 4.70V -37.76mA -27.06mA -54.20mA 5.00V -38.14mA -27.33mA -54.76mA 10.00V -44.52mA -33.72mA -61.15mA -> V/I table decreasing [POWER_clamp] | Voltage I(typ) I(min) I(max) -5.00V 1.05A NA NA -1.10V 79.00mA NA NA -1.00V 54.00mA NA NA -900.00mV 29.00mA NA NA -800.00mV 10.40mA NA NA -200.00mV 0.00uA NA NA -100.00mV 0.00uA NA NA 0.00V 0.00pA NA NA -> V/I table decreasing 3) IF the model is any of the following types:(Input_ECL, Output_ECL, I/O_ECL) { Verify that: - Pullup V/I table has equal or decreasing current - POWER_clamp V/I table has equal or decreasing current - Pulldown V/I table has equal or decreasing current - GND_clamp V/I table has equal or increasing current } ELSE { Verify that: - Pullup V/I table has equal or decreasing current - POWER_clamp V/I table has equal or decreasing current - Pulldown V/I table has equal or increasing current - GND_clamp V/I table has equal or increasing current } Note: This specifically allows constant current generators and 0 current tables. 0 current tables may be used to indicate table is unused. 4) If any table verification fails report the following error message: 'Error found in xxx V/I table at line number nnn!'. Where xxx is one of the following Pullup, Pulldown, POWER_clamp, GND_clamp. Where nnn is the line number. *************************************************************************** Change 3- Add a header comment statement at the TOP of the IBIS_CHK program to insure that new changes to the IBIS_CHK program donot break tests that worked in old MAJOR versions. This approach makes the program larger however it insures the parser always works the same on older versions of IBIS. This apporach uses more memory, but has the reward of low maintaining costs. The IBIS_CHK program is very small and would not be effected by this until many revisions have occured. *************************************************************************** NOTICE TO ANY PERSON MODIFING THIS PROGRAM! ------------------------------------------- This program SHALL NOT BE MODIFIED unless there is an associated IBIS BIRD. Said BIRD shall be agreed upon by IBIS committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is allowed to modify the source code. The present CZAR is Jon Powell (April 1994). The IBIS committee may also hire programmers from time to time to make major changes to the source code. Note: Source licensees are free to modify their own copies of this source code in any way they choose. Source licensees shall not redistribute the source code modified or otherwise. Source licensing is available from the IBIS open forum. The IBIS open forum is non-profit. The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED when adding code for the next version of the IBIS specification. Instead completely new code for all functions and features shall be created. This may require duplication of numerous functions. Each function shall be preceded by VXX_ where XX is the MAJOR version of the IBIS specification which is being parsed and tested. A MAJOR version would for example be 1.x going to 2.x. A MINOR version would for example be 1.1 to 1.2. Functions using the above syntax would look as follows: V01_GetValue MINOR revisions DO NOT required new code. Startup code shall be provided at the top of the program which reads the version number from the IBIS file and runs the portion of the program corresponding to that MAJOR version. Code which is used only by the program startup function is not duplicated. ****************************************************************************** From bob@icx.com Fri May 6 10:59:51 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25631; Fri, 6 May 94 10:59:51 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02136 for ; Fri, 6 May 94 13:21:17 -0400 Date: Fri, 6 May 94 10:16:29 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18272; Fri, 6 May 94 10:16:29 PDT Message-Id: <9405061716.AA18272@icx.com> To: ibis@vhdl.org Subject: VERSION1.1Y 3 OF 4 | Points for each curve must span the voltages listed below: | | | | Curve Low Voltage High Voltage | | ----------- ----------- ------------ | | [Pulldown] GND - POWER POWER + POWER | | [Pullup] GND - POWER POWER + POWER | | [GND_clamp] GND - POWER GND + POWER | | [POWER_clamp] POWER POWER + POWER | | | | For example, a device with a 5 V power supply voltage should be | | characterized between (0 - 5) = -5 V and (5 + 5) = 10 V; | | and a device with a 3.3 V power supply should be characterized | | between (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the | | pulldown curve. | | |****************************************************************************** |* BIRD4 ADDITION FOR VERSION 1.1X |* When tabulating output data for ECL type devices, the voltage points |* must span the range of VCC to VCC - 2.2V. This range applies to both the |* pullup and pulldown tables. Note that this range applies ONLY when |* characterizing an ECL output. |****************************************************************************** | | | 3) Ramp Rates: | | The ramp rates (listed in AC characteristics below) should be | | derived by: | | 1. Start with silicon model, remove all packaging. | | 2. Attach 50 Ohm resistor to GND to derive rising edge ramp. | | 3. Attach 50 Ohm resistor to POWER to derive falling edge ramp. | | 4. Due to the resistor, output swings will not make a full | | transition as expected. However the pertinent data can still | | be collected as follows: | | a) determine the 20% to 80% voltages of the 50 Ohm swing | | b) measure this voltage change as "dv" | | c) measure the amount of time required to make this swing "dt" | | 5. Post the value as a ratio "dv/dt", the simulation tool vendor | | will extrapolate this value to span the required voltage swing | | range in the final model. | | 6. Typ, Min, and Max must all be posted, and are derived at the | | same extremes as the V/I curves, which are: | | | | Ramp times for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "Y%" | | max = hi voltage tol, 0 degrees C, typical process, plus "Y%" | | | | Ramp times for bipolar devices: | | To be determined by manufacturer. | | | | Note that the derate factor, "Y%", may be different than that used | | for the V/I curve data. This factor is similar to the X% factor | | described above. As in the case of V/I curves, temperatures are | | junction temperatures here also. | | | | 7. The rise time of an open-drain device must be measured into | | a 50 Ohm pullup resistor tied to the power pin. | | | |****************************************************************************** |* BIRD7.2 REPLACEMENT OF 3) FOR VERSION 1.1X |* NOTE, Items 3. and 7. above deleted, Items 4. thru 6. renumbered 3. thru 5. |* |* 3) Ramp Rates: |* The ramp rates (listed in AC characteristics below) should be derived |* as follows: |* |* 1. Start with the silicon model, remove all packaging. |* |* 2. If: The Model_type is one of the following: Output, I/O, or |* 3-state (not open or ECL types); |* Then: Attach a 50 ohm resistor to GND to derive the rising edge |* ramp. Attach a 50 ohm resistor to POWER to derive the |* falling edge ramp. |* |* If: the Model_type is Output_ECL or I/O_ECL; |* Then: Attach a 50 ohm resistor to the termination voltage |* (Vterm = VCC - 2v). Use this load to derive both the |* rising and falling edges. |* |* If: The Model_type is either an open_sink type or open_drain type; |* Then: Attach either a 50 ohm resistor or the vendor suggested |* termination resistance to either POWER or the vendor suggested |* termination voltage. Use this load to derive both the rising |* and falling edges. |* |* If: The Model_type is an open_source type; |* Then: Attach either a 50 ohm resistor or the vendor suggested |* termination resistance to either GND or the vendor suggested |* termination voltage. Use this load to derive both the rising |* and falling edges. |* |* 3. Due to the resistor, output swings will not make a full |* transition as expected. However the pertinent data can still |* be collected as follows: |* a) determine the 20% to 80% voltages of the 50 Ohm swing |* b) measure this voltage change as "dv" |* c) measure the amount of time required to make this swing "dt" |* 4. Post the value as a ratio "dv/dt", the simulation tool vendor |* will extrapolate this value to span the required voltage swing |* range in the final model. |* 5. Typ, Min, and Max must all be posted, and are derived at the |* same extremes as the V/I curves, which are: |* |* Ramp times for CMOS devices: |* typ = nominal voltage, 50 degrees C, typical process |* min = low voltage tol, 100 degrees C, typical process, minus "Y%" |* max = hi voltage tol, 0 degrees C, typical process, plus "Y%" |* |* Ramp times for bipolar devices: |* To be determined by manufacturer. |* |* Note that the derate factor, "Y%", may be different than that used |* for the V/I curve data. This factor is similar to the X% factor |* described above. As in the case of V/I curves, temperatures are |* junction temperatures here also. |****************************************************************************** | | It is expected that this data will be created from silicon vendor | | proprietary silicon-level models, and later correlated with actual device | | measurement. | |==============================================================================| |******************************************************************************| | ADDITIONAL NOTES FOR IBIS EXTENSIONS (BIRDS) | |******************************************************************************| ******************************************************************************* NOTES ON BIRD2.2 3) Add the following requirements to [Model]: The model types Input, I/O, I/O_open_drain, I/O_open_sink, I/O_open_source must have Vinl and Vinh defined. If they are not defined, the parser will issue a warning and the default values of Vinl=.8V and Vinh=2.0V will be assumed. The model types Input_ECL and I/O_ECL must have Vinl and Vinh defined. If they are not defined, the parser will issue a warning and the default values of Vinl=-1.475V and Vinh=-1.165V will be assumed. ECL defaults derived from FAIRCHILD F100K ECL data book specification of Guaranteed input HIGH and LOW. 4) The following is added to the differential specification to clarify Differential input threshold: If a pin is a differential input pin the differential input threshold (vdiff) overrides and supercedes the need for Vinh and Vinl. If vdiff is not defined for a pin that is defined as requiring a Vinh by its [Model] type, the parser will issue a warning and vdiff will be set to the default value of 200mV. 5) The golden parser must be modified to allow "Terminators" and (4) and check for (3) and (4). ****************************************************************************** NOTES ON BIRD9.3 A set of terminator components is useful to be formatted using IBIS because they are found as packaged components. All of the options can support (typ), (min) and (max) specifications. (1) Parallel Resistor Termination: The additonal elements [Rpower] and [Rgnd] provide terminations to Vcc, Gnd or both. Devices such as the Motorola MCC142233 to MCC142236 Switchable SCSI Passive Bus Terminator series would be modeled with these elements. At least two other techniques could be used in IBIS Version 1.1. The [POWER_clamp] or [GND_clamp] tables could be used (with as few as two data points each) to represent resistors. Another method could be to use R_pkg (or R_pin) with [POWER_clamp] or [GND_clamp] structures configured as a very low impedance. Processing tabular data for these purposes would be less efficient and less obvious than working with resistive elements directly. (2) RC (or AC) Termination: R_pkg (or R_pin) and C_comp can provide RC terminations. This proposal specifies [Rac] connected to [Cac] elements. This will allow packaged RC terminations which include built in clamping diodes to be modeled directly. Diode terminators already can be modeled using IBIS Version 1.1: (3) Diode Termination: Devices such as the TI SN74S1050 thru SN74S1056 Schottky Barrier Diode Bus-Termination Arrays can be modeled using existing [POWER_clamp] and [GND_clamp] structures. The total context model is attached showing the proposed additions. |<-------------TERMINATOR Model--------------->| VOLTAGE RANGE or POWER_CLAMP REF o | POWER_ |---o---| CLAMP | | |--o--| \ | | / | VI | \ RPOWER PACKAGE Keyword | | / Parameters |--o--| | |<----------------->| | | | | PIN o-----o-------o-----o-----/\/\/\--UUUUUU---o--o | |GND_ | | R_PKG L_PKG | | |CLAMP | | | | |--o--| | | | | | | \ | | | | VI | /RGND | | | | | \ \ | | |--o--| / / RAC | | | | \ | | |---o---| / | | | | | C_COMP --- o --- CAC C_PKG --- --- GND or --- --- | GND_CLAMP REF | | | | | |-------------------o----------------------| | o GND |<-------->| Proposed Terminator Keywords ****************************************************************************** NOTES ON BIRD10.1 Refer to BIRD10.1 for the complete specification and description STATEMENT OF THE RESOLVED SPECIFICATIONS: Summary: ------- A new keyword, [Package Model], is added to the .ibs file. This keyword is used within a [Component] to indicate (by name) the package model that should be used for a part. Package models can be found either in separate package model files, which bear the .pkg extension, or within the same .ibs file as the [Component]. An additional new keyword, [Define Package Model], is also added to the specification; this is used to mark the beginning of the actual package model data. The purpose of breaking up the package model and the component model is to make associations between the two more flexible: several components may share a single package model, or one component may have several different incarnations which use different packages (and thus, different package models). Use of [Package Model] is OPTIONAL. If it is not provided, then the table of RLC values listed in the [Pin] section of the [Component] is used as the "package model" for the part. On the other hand, if the [Package Model] IS given, then the R_pin, L_pin and C_pin values in the [Pin] section may either be ignored, or may be used for less detailed simulations without coupling. Probably this data will simply be left out of the [Pin] section when a [Package Model] is used; this practice is permitted by the IBIS Ver. 1.1 specification since [Pin] data may contain either 3 or 6 columns. A .pkg file is just an ordinary IBIS file, with the restriction that it cannot contain [Component]'s or [Model]'s. Only package models declared by the [Define Package Model] keyword may be contained within these files. Of course, all of the necessary components of an IBIS file ([IBIS Ver], [File Name], [File Rev], etc. through [End]) must still be included within a .pkg file. The package model to be used treats every package as a collection of current carrying "paths," which lead from the board, through the packages pins, leadframe traces and bonding wires to a bonding pad on the die itself. Each path has a self-resistance, self-inductance and self-capacitance associated with it. In addition, there is the flexibility to describe mutual inductance, mutual resistance and coupling capacitance drops between every path. This data can be listed concisely as three RLC parameter matrices. This BIRD describes how these matrices are to be formatted. ****************************************************************************** NOTES ON BIRD11.2 ... THESE NOTES REFER TO CHANGES IN THE IBIS_CHK PROGRAM *************************************************************************** Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. *************************************************************************** For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, GND_clamp 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The current in the TYPICAL column corresponding to Vmax is less than the current in the TYPICAL column corresponding to Vmin than the table is assumed to have decreasing current. ELSE IF:The current in the TYPICAL column corresponding to Vmax is greater than the current in the TYPICAL column corresponding to Vmin than the table is assumed to have increasing current. ELSE: The table is assumed to have equal current." Note: This works for all cases of discontinuities unless the magnitude of discontinuity is such that this model is in all probability competely unrealistic. Examples: *** example with non-monotonic data at the end point V: I: 0.00 0.0 4.90 50.0ma 4.91 49.9ma 4.93 56.7ma 5.00 3.0ma -> V/I table has increasing current (3.0 > 0) Vmax = 5.0, I =3.0mA Vmin = 0.0, I =0.0 *** example with negative to positve voltages with negative first V: I: -5.00 -0.1ma 0.00 0.0 5.00 100.0ma -> V/I table has increasing current (100 > -0.1) Vmax = 5.0, I=100mA Vmin = -5.0, I=-0.1mA *** example with table data entered postive voltages first V: I: 5.00 10.1ma 0.00 0.0 -5.00 -10.1ma -> V/I table has increasing current (10.1 > -10.1) Vmax = 5.0, I=10.1mA Vmin = -5.0, I=-10.1mA *** example with only two entrys V: I: 0.00 0.0 -5.00 10.1ma -> V/I table has decreasing current (0 < 10.1) Vmax = 0.0, I=0 Vmin = -5.0, I=10.1mA *** ECL example [Pullup] Voltage I(typ) I(min) I(max) 0.0 0 0 0 0.7 -0.2m -0.2m -0.2m 0.73 -0.4m -0.4m -0.4m 0.75 -0.8m -0.8m -0.8m 0.76 -1.2m -1.2m -1.2m 0.77 -1.6m -1.6m -1.6m 0.8 -4.4m -4.4m -4.4m 0.82 -7.6m -7.6m -7.6m 0.85 -14.2m -14.2m -14.2m 0.9 -30.0m -30.0m -30.0m 1.0 -58.0m -50.0m -68.0m -> V/I table has decreasing current ( -58 < 0) Vmax = 1.0, Ityp=-58mA Vmin = 0, Ityp=0 [Pulldown] Voltage I(typ) I(min) I(max) 0.0 0 0 0 1.6 -0.2m -0.2m -0.2m 1.62 -0.4m -0.4m -0.4m 1.64 -0.6m -0.6m -0.6m 1.65 -0.8m -0.8m -0.8m 1.66 -1.2m -1.2m -1.2m 1.67 -1.6m -1.6m -1.6m 1.68 -2.4m -2.4m -2.4m 1.69 -3.2m -3.2m -3.2m 1.70 -4.4m -4.4m -4.4m 1.72 -7.4m -7.4m -7.4m 1.75 -14.2m -14.2m -14.2m 1.8 -30.5m -30.5m -30.5m 1.9 -65.0m -60.0m -75.0m -> V/I table has decreasing current ( -65 < 0) Vmax = 1.9, Ityp=-65mA Vmin = 0.0, Ityp= 0 *** An abreviated INTEL model for a CMOS output |**************************************************************************** [Pulldown] | Voltage I(typ) I(min) I(max) -5.00V -38.70mA -29.47mA -51.22mA -1.00V -24.88mA -19.18mA -32.90mA -0.50V -14.35mA -11.06mA -19.05mA 0.00V -11.84pA -554.66pA -11.03pA 100.00mV 3.20mA 2.47mA 4.27mA 200.00mV 6.24mA 4.80mA 8.30mA 4.90V 38.68mA 29.45mA 51.18mA 5.00V 38.70mA 29.47mA 51.22mA 10.00V 39.96mA 30.37mA 53.06mA -> V/I table increasing [GND_clamp] | Voltage I(typ) I(min) I(max) -5.00V -680.00mA NA NA -1.10V -75.50mA NA NA -600.00mV -950.00uA NA NA -500.00mV -78.00uA NA NA -200.00mV 0.00pA NA NA -100.00mV 0.00pA NA NA 0.00V 0.00pA NA NA From bob@icx.com Fri May 6 11:00:06 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25678; Fri, 6 May 94 11:00:06 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02115 for ; Fri, 6 May 94 13:21:06 -0400 Date: Fri, 6 May 94 10:15:45 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18266; Fri, 6 May 94 10:15:45 PDT Message-Id: <9405061715.AA18266@icx.com> To: ibis@vhdl.org Subject: VERSION1.1Y 2 OF 4 |* the [Model] Polarity specification such that the pin in the |* [Diff_pin] column will be Non-Inverting and the pin in the |* inv_pin column will be Inverting. This convention allows |* one [Model] to be used for both pins. |* |* Column length limits are: |* [Diff_Pin] 5 characters max |* inv_pin 5 characters max |* vdiff 9 characters max |* tdelay_typ 9 characters max |* tdelay_min 9 characters max |* tdelay_max 9 characters max |* |* Each line must contain either four or six columns. If "NA" is |* entered in the vdiff, tdelay_typ or tdelay_min columns, its |* entry will be interpreted as 0V or 0ns. If "NA" appears in |* the tdelay_max column, its value will be interpreted as the |* tdelay_typ value. When using six columns, the headers |* tdelay_min and tdelay_max must be listed. Entries for the |* tdelay_min column are based on minimum magnitudes; and |* tdelay_max column, maximum magnitudes. One entry of vdiff |* regardless of its polarity is used for difference magnitudes. |*--------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max |* 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V |****************************************************************************** |==============================================================================| | Keyword: [Model] | | Required: Yes | | Description: Used to define a model, and its attributes. | | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | |* |* BIRD7.2 and 9.3 modifications |* Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, |* Open_sink, I/O_open_sink, Open_source, I/O_open_source, |* Input_ECL, Output_ECL, I/O_ECL and Terminator model must |* | begin with the keyword [Model]. The model_name must match | | the one that is listed under the [Pin] keyword and must not | | contain more than 20 characters. An .ibs file must contain | | enough [Model] keywords to cover all of the model_names | | specified under the [Pin] keyword, except for those | | model_names which use reserved words (POWER, GND and NC). | | Model_names with reserved words are an exception and | | they do not have to have a corresponding [Model] keyword. | | C_comp is allowed to use "NA" for the min and max values only. | |* |* BIRD2.2 addition |* The model types Input, I/O, I/O_open_drain, I/O_open_sink, |* I/O_open_soure must have Vinl and Vinh defined. If |* they are not defined, the parser will issue a warning and the default |* values of Vinl=.8V and Vinh=2.0V will be assumed. |* |* The model types Input_ECL and I/O_ECL must have Vinl and Vinh defined. If |* they are not defined, the parser will issue a warning and the default |* values of Vinl=-1.475V and Vinh=-1.165V will be assumed. |* |* BIRD9.3 change |* Other Notes: A complete [Model] description normally contains the following |* keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], |* [POWER_clamp], [Rgnd], [Rpower], [Rac], [Cac], |* and [Ramp]. However, some models may have only |* a subset these keywords. For example, an input structure |* normally only needs the [Voltage range], [GND_clamp], and |* possibly the [POWER_clamp] keywords. If one or more of |* [Rgnd], [Rpower], [Rac] and [Cac] keywords are used, then |* the Model_type must be Terminator. |* |* BIRD2.2 addition |* A "Terminator" is an input only device that can have analog loading effects |* on the circuit being simulated but has no digital logic thresholds. |* Examples of "Terminators" are: Capacitors, Termination Diodes, Pullup |* resistors etc. |* |* BIRD7.2 addition |* Model_types with "open_sink" specify that the output has |* an OPEN side (the [Pullup] keyword is not used or I = 0mA |* for all voltages specified) AND the output SINKS current. |* Model_types with "open_drain" have the identical meaning and |* are retained for backward compatibility. Model_types with |* "open_source" specify that the output has an OPEN side (the |* [Pulldown keyword is not used or I = 0mA for all voltages |* specified) AND the output SOURCES current. Model_types with |* "_ECL" specify that the model represents and ECL type logic |* which follows different conventions for the [Pulldown] keyword. |* | Note that C_comp defines the silicon die capacitance. This | | value should not include the capacitance of the package. | | | |------------------------------------------------------------------------------| [Model] model_name |* |* BIRD7.2 and BIRD9.3 modification Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Input_ECL, Output_ECL, I/O_ECL, Terminator | List one only |* Polarity Non-Inverting, Inverting | List one only, if any Enable Active-High, Active-Low | List one only, if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, if desired Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |==============================================================================| | Keyword: [Voltage range] | | Required: Yes | | Description: Used to define the power supply voltage tolerance over which | | the model is intended to operate. | | Usage Rules: Actual voltages (not percentages) are to be presented in the | | usual typ, min, max format. "NA" is allowed for the min and | | values only. | | Other Notes: [Voltage range] also describes the voltage range over which | | the various V/I curves and ramp rates were derived. | |------------------------------------------------------------------------------| | variable typ min max [Voltage range] 5.0V 4.5V 5.5V |****************************************************************************** |* BIRD3 replacement of [Voltage range] text above for VERSION 1.1X |*========================================================================== |* Keyword: [Voltage range] |* Required: Yes, if [Pullup reference], [Pulldown reference], |* [Power_clamp reference], and [GND_clamp reference] are not |* present |*Description: Used to define the power supply voltage tolerance over which |* the the model is intended to operate. It also specifies the |* default voltage rail the pullup and POWER_clamp V/I data is |* referenced to. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*--------------------------------------------------------------------------- |* variable typ min max [Voltage range] 5.0v 4.5v 5.5v |*=========================================================================== |* Keyword: [Pullup reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a voltage rail other than that defined by |* the [Voltage range] keyword as the reference voltage |* for the pullup V/I data. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: This keyword, if present, also defines the voltage range over |* which the min and max dV/dt_r values are derived. |*--------------------------------------------------------------------------- |* variable typ min max [Pullup reference] 5.0V 4.5V 5.5V |*=========================================================================== |* Keyword: [Pulldown reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a power supply rail other than 0v as the |* reference voltage for the pulldown V/I data. If this keyword |* is not present the voltage data points in the pulldown V/I table |* are referenced to 0v. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: This keyword, if present, also defines the voltage range over |* which the min and max dV/dt_f values are derived. |*--------------------------------------------------------------------------- |* variable typ min max [Pulldown reference] 0V 0V 0V |* Keyword: [POWER_clamp reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a voltage rail other than that defined by |* the [Voltage range] keyword as the reference voltage |* for the POWER_clamp V/I data. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |*--------------------------------------------------------------------------- |* variable typ min max [POWER_clamp reference] 5.0V 4.5V 5.5V |*=========================================================================== |* Keyword: [GND_clamp reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a power supply rail other than 0v as the |* reference voltage for the GND_clamp V/I data. If this keyword |* is not present the voltage data points in the GND_clamp V/I table |* are referenced to 0v. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |*--------------------------------------------------------------------------- |* variable typ min max [GND_clamp reference] 0V 0V 0V |*============================================================================ |* NOTES ON SPECIFYING POWER SUPPLIES |* It is the intention that standard TTL and CMOS devices be specified |* using only the [Voltage range] keyword. However, in cases where |* the output characteristics of a device depend on more than a single |* supply and ground, or a pullup, pulldown or clamp structure is referenced |* to something other than the default supplys, the additional 'reference' |* keywords are to be used. |* If the [Voltage range] keyword is not present then all four of the |* other keywords must be present. If the [Voltage range] keyword is |* present the other keywords are optional and may or may not be used as |* required. It is legal (although redundant) for an optional keyword to |* specify the same voltage as specified by the [Voltage range] keyword. |****************************************************************************** |==============================================================================| | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | | Required: Yes, if they exist in the device | | Description: The data points under these keywords define the V/I curves of | | the pulldown and pullup structures of an output buffer and the | | V/I curves of the clamping diodes connected to the GND and the | | POWER pins, respectively. | |* |* BIRD11.2 Continuation of Previous Paragraph: |* Currents are considered positive |* when their direction is into the component. |* | Usage Rules: In each of these sections the first column contains the | | voltage value, and the three remaining columns hold the | | typical, minimum, and maximum current values. The four | | entries, Voltage, I(typ), I(min), and I(max) must be placed on | | a single line and must be separated by at least one white | | space or tab character. | | All four columns are required under these keywords, however | | data is only required in the typical column. If minimum | | and/or maximum current values are not available, the reserved | | word "NA" must be used. "NA" can be used for currents in the | | typical column, but numeric values MUST be specified for the | | first and last voltage points on any V/I curve. Each V/I | | curve must have at least 2, but not more than 100, voltage | | points. | | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | | [POWER_clamp] structures are 'Vcc relative', meaning that the | | voltage values are referenced to the Vcc pin. The voltages in | | the data tables are derived from the equation: | | Vtable = Vcc - Voutput | | Therefore, for a 5V component, -5 V in the table actually | | means 5 V above Vcc, which is +10 V with respect to ground; | | and 10 V means 10 V below Vcc, which is -5 V with respect to | | ground. Vcc-relative data is necessary to model a pullup | | structure properly, since the output current of a pullup | | structure depends on the voltage between the output and Vcc | | pins and not the voltage between the output and ground pins. | | Note that the [GND_clamp] V/I curve can include quiescent | | input currents, or the currents of a 3-stated output if so | | desired. | |****************************************************************************** |* BIRD4 ADDITION FOR VERSION 1.1X |* When tabulating data for ECL devices, the data in the pulldown table |* is measured with the output in the 'logic low' state. In other words, |* the data in the table represents the V-I characteristics of the |* output when the output is at the most negative of its two logic |* levels. Likewise, the data in the pullup table is measured with the |* output in the 'logic one' state and represents the V-I characteristics |* when the output is at the most positive logic level. Note that in BOTH |* these cases the data is referenced to the VCC supply voltage, using |* the equation Vtable = Vcc - Voutput. |****************************************************************************** |------------------------------------------------------------------------------| [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND_clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER_clamp] | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA |******************************************************************************* |* BIRD9.3 ADDITION FOR VERSION 1.1Y |*========================================================================== |* Keywords: [Rgnd], [Rpower], [Rac], [Cac] |* Required: Yes, if they exist in the device |* Description: The data for these keywords define the resistance values of |* Rgnd and Rpower connected to GND and the POWER pins, |* respectively. |* Usage Rules: For each of these sections the three columns hold the |* typical, minimum, and maximum resistance values. The three |* entries for R(typ), R(min), and R(max) or C(typ), C(min), |* and C(max) must be placed on a single line and must be |* separated by at least one white space or tab character. |* All three columns are required under these keywords, however |* data is only required in the typical column. If minimum |* and/or maximum values are not available, the reserved word |* "NA" must be used indicating the R(typ) or C(typ) value by |* default. |* Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and |* [Rgnd] is connected to 'GND'. However, [GND_clamp reference] |* voltages, if defined, apply to [Rgnd]. [POWER_clamp reference] |* voltages, if defined, apply to [Rpower]. |* Either or both [Rgnd] and [Rpower] may be defined and may |* co-exist with [GND_clamp] and [POWER_clamp] structures. |* If an AC terminator is specified, then both [Rac] and [Cac] |* are required. |* When [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the |* Model_type must be Terminator. |*------------------------------------------------------------------------------ |* variable R(typ) R(min) R(max) |* [Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator [Rpower] 220Ohm 200Ohm NA | |* [Rac] 30Ohm NA NA | |* |* variable C(typ) C(min) C(max) | AC terminator |* [Cac] 50pF NA NA | |******************************************************************************* |==============================================================================| | Keyword: [Ramp] | | Required: Yes, except for inputs | | Description: Used to define the rise and fall times of a buffer. | | Sub-Params: dV/dt_r, dV/dt_f | | Usage Rules: These parameters describe an ideal slope and can be expressed | | as a ratio of any reasonable voltage and time values as shown | | in the examples. The [Ramp] values are allowed to use "NA" | | for the min and max values only. | |------------------------------------------------------------------------------| [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n |==============================================================================| | Keyword: [End] | | Required: Yes | | Description: Used to define the end of the .ibs file. | |------------------------------------------------------------------------------| [End] |==============================================================================| | | | NOTES ON DATA DERIVATION METHOD | | | | This section explains how data values are derived. The intention here is to | | avoid over-guardbanding, enabling simulation results that are meaningful and | | useful. This is accomplished by having each silicon vendor base their data | | on typical process data, and then derate by voltage and temperature, and a | | proprietary "X%" factor. This methodology also has the nice feature that | | the data can be derived either from vendor-proprietary silicon models, or | | typical device measurement over temperature/voltage. | | | | 1) V/I curves for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "X%" | | max = hi voltage tol, 0 degrees C, typical process, plus "X%" | | | | V/I curves for bipolar devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 0 degrees C, typical process, minus "X%" | | max = hi voltage tol, 100 degrees C, typical process, plus "X%" | | | | where X% should be statistically determined by the silicon vendor | | based on numerous fab lots, test chips, process controls, ... The | | value of X need not be published in the IBIS file, and may decrease | | over time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | | | 2) Voltage Ranges: | From bob@icx.com Fri May 6 11:00:22 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25684; Fri, 6 May 94 11:00:22 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02100 for ; Fri, 6 May 94 13:20:52 -0400 Date: Fri, 6 May 94 10:14:39 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18257; Fri, 6 May 94 10:14:39 PDT Message-Id: <9405061714.AA18257@icx.com> To: ibis@vhdl.org Subject: VERSION1.1Y 1 OF 4 To IBIS Members: The long text that follows is an UNOFFICIAL DRAFT designated IBIS Version 1.1Y which uses IBIS Version 1.1 as the baseline and includes the BIRDS which have been approved to date. It expands from Version 1.1X issued on February 20, 1994. THIS MAIL WILL COME IN 4 SECTIONS so that it will pass through most mail programs. Since this is an interim document, the NOTES ON BIRDS section at the end will only contain information on BIRD2.2, BIRD9.3, BIRD10.1 and BIRD11.2. This document has been produced mostly through "cut and paste", with some minor corrections, but without concern about formatting and consistency details. The intent is to capture the approved changes and show WHERE they apply. This should serve as a reminder to all of us of what has been done so far, and should be useful to the newer members when they hear references to work already done. Bob Ross, Interconnectix, Inc. |****************************************************************************** |* ENHANCED VERSION OF IBIS VERSION 1.1 DESIGNATED "VERSION 1.1Y" SHOWING |* APPROVED "BIRDS" (BIRD = BUFFER ISSUE RESOLUTION DOCUMENT). |* CHANGES FOR ADDITIONS AND REPLACEMENT DESIGNATED BY "|*" SECTIONS PLUS |* NOTES ON BIRDS AT END. |* BIRDS INCLUDED IN VERSION 1.1X ARE BIRD3, BIRD4, BIRD5.2, BIRD6.2, BIRD7.2. |* FEBRUARY 20, 1994. |* BIRDS INCLUDED IN VERSION 1.1Y ARE BIRD2.2, BIRD9.3, BIRD11.2 AND REFERENCE |* TO BIRD10.1, MAY 6, 1994 |****************************************************************************** |==============================================================================| | | | Statement of Intent: | | | | In order to enable an industry standard method to electronically transport | | IBIS Modeling Data between silicon vendors, simulation software vendors, and | | end customers, this template is proposed. The intention of this template is | | to specify a consistent format that can be parsed by software, allowing each | | simulation vendor to derive models compatible with their own product. | | | | One goal of this template is to represent the current state of IBIS data, | | while allowing a growth path to more complex models / methods (when deemed | | appropriate). This would be accomplished by a revision of the base | | template, and possibly the addition of new keywords or categories. | | | | Another goal of this template is to ensure that it is simple enough for | | silicon vendors and customers to use and modify, while ensuring that it is | | rigid enough for software simulation vendors to write reliable parsers. | | | | Finally, this template is meant to contain a complete description of the I/O | | elements on an entire component. Consequently, several models will need to | | be defined in each file, as well as a table that equates the appropriate | | buffer to the correct pin and signal name. | | | | Version 1.1 of this electronic template was finalized by an industry-wide | | group of simulation experts representing various companies and interests. | | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | | ASCII file format. It represents the minimum amount of I/O buffer | | information required to create an accurate IBIS model of common CMOS and | | bipolar I/O structures. Future revisions of the ASCII file will add items | | considered to be "enhancements" to Version 1.0 to allow accurate modeling | | of new, or other, I/O buffer structures. Consequently, all future | | revisions will be considered super sets of Version 1.0, allowing backward | | compatibility. In addition, as modeling platforms develop support for | | revisions of the IBIS ASCII template, all previous revisions of the | | template must also be supported. | | | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | | comments have been added for further clarification. | | | |==============================================================================| | | | General syntax rules and guidelines: | | | | 1) The content of the IBIS_ASCII file is case sensitive, except for file | | names, reserved words and keywords. Reserved words and keywords are not | | case sensitive, and file names must be all lower case. | | | | 2) The following words are reserved words and must not be used for | | any other purposes in the document: | | POWER - reserved model name, used with power supply pins, | | GND - reserved model name, used with ground pins, | | NC - reserved model name, used with no connect pins, | | NA - used where data not available. | | | | 3) File names used in the IBIS_ASCII file must only have lower case | | characters to enhance UNIX compatibility and must conform to DOS rules. | | (The length of a file name should not exceed eight plus three characters | | and it must not contain special characters which are illegal in DOS). | | | | 4) The IBIS_ASCII file must have no more than 80 characters per line. | | | | 5) Anything following the comment character is ignored and considered a | | comment on that line. The default "|" (pipe) character can be changed by | | the keyword [Comment char] to any other character. The [Comment char] | | keyword can be used throughout the file as desired. | | | | 6) Keywords must be enclosed in square brackets, [], and must start in | | column 1 of the line. | | | | 7) Valid scaling factors are: | | M = mega, k = kilo, m = milli, u = micro, n = nano, p = pico. | | When no scaling factors are specified, the appropriate base units are | | assumed. (These are Volts, Amperes, Ohms, Farads and Henries). The parser | | will look at only one alphabetic character after a numerical entry, | | therefore it is enough to use only the prefixes to scale the parameters. | | However, for clarity, it is allowed to use full abbreviations for the | | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | | allowed (e.g., 1.2345e-12). | | | | 8) The V/I data tables should use enough data points around sharply curved | | areas of the V/I curves to describe the curvature accurately. In linear | | regions there is no need to define unnecessary data points. | | | | 9) Currents are considered positive when their direction is into the | | component. | | | |==============================================================================| | Keyword: [IBIS Ver] | | Required: Yes | | Description: Used to specify the IBIS ASCII template version. This will be | | used to inform an electronic parser of the kinds of data types | | that will be present in the file. | | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | | normally on the first line of the file, but can be preceded | | by comment lines (that must begin with a "|"). | |------------------------------------------------------------------------------| [IBIS Ver] 1.1 | Used for template variations |==============================================================================| | Keyword: [Comment char] | | Required: Optional | | Description: Used to define a new comment character to replace the default | | "|" (pipe), if desired. | | Usage Rules: The new comment character which is to be defined must be | | followed by the underscore character and the letters "char". | | For example: "|_char" redundantly redefines the comment | | character to be the pipe character. The new comment character | | will be in effect only following the [Comment char] keyword. | | The following characters can NOT be used: A B C D E F G H I J | | K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o | | p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = | | Other Notes: The [Comment char] keyword can be used throughout the file, as | | desired. | |------------------------------------------------------------------------------| [Comment char] |_char |==============================================================================| | Keyword: [File name] | | Required: Yes | | Description: Used to specify the name of the IBIS file, "filename.ibs". | | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | | and no characters that are illegal in DOS). In addition, it | | must be all lower case, and use the extension ".ibs". | |------------------------------------------------------------------------------| [File name] ver1_1.ibs |==============================================================================| | Keyword: [File Rev] | | Required: Yes | | Description: Used to track the revision level of a particular .ibs file. | | Usage Rules: Revision level can be set at the discretion of the engineer | | defining the file. The following guidelines are recommended: | | 0.x silicon and file in development | | 1.x pre-silicon file data from silicon model only | | 2.x file correlated to actual silicon measurements | | 3.x mature product, no more changes likely | |------------------------------------------------------------------------------| [File Rev] 1.0 | Used for .ibs file variations |==============================================================================| | Keywords: [Date] [Source] [Notes] [Disclaimer] | | Required: Optional | | Description: Optionally used for further file clarifications. | | Usage Rules: The [Date] information is allowed to contain blanks, and be of | | any format up to 40 characters. | |------------------------------------------------------------------------------| [Date] 04/19/93 | Latest file revision date [Source] Put originator and source of information here. For example: From silicon level SPICE model at Intel, From lab measurement at IEI, Compiled from manufacturer's data book at Quad Design, etc... [Notes] This section can be used for any special notes related to the file. [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component |==============================================================================| | Keyword: [Component] | | Required: Yes | | Description: Used to mark the beginning of the IBIS description of the | | integrated circuit named after the keyword. | | Usage Rules: If the .ibs file contains data for more than one component, | | each section must begin with a new [Component] keyword. The | | length of the Component Name must not exceed 40 characters, | | and blank characters are allowed. | |------------------------------------------------------------------------------| [Component] Component Name |==============================================================================| | Keyword: [Manufacturer] | | Required: Yes | | Description: Used to clarify the component's manufacturer. | | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | | characters (blank characters are allowed, e.g., Texas | | Instruments). In addition, each manufacturer must use a | | consistent name in all .ibs files. | |------------------------------------------------------------------------------| [Manufacturer] Manufacturer's Name | e.g., Intel |==============================================================================| | Keyword: [Package] | | Required: Yes | | Description: Used to define a range of values for the default packaging | | resistance, inductance, and capacitance of the component pins. | | Sub-Params: R_pkg, L_pkg, C_pkg | | Usage Rules: Typical column must be specified. If data for the other | | columns are not available, they must be noted with "NA". | | Other Notes: If RLC parameters are available for individual pins, they can | | be listed in columns 4-6 under keyword [Pin]. The values | | listed in the [Pin] description section override the default | | values defined here. | |------------------------------------------------------------------------------| [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF |==============================================================================| | Keyword: [Pin] | | Required: Yes | | Description: Used to associate the component's I/O models to its various | | external pins and signal names. | | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | | Usage Rules: All pins on a component must be specified. The first column | | must contain the pin name. The second column, signal_name, | | gives the data book name for the signal on that pin. The | | third column, model_name, associates the I/O model for that | | pin. Each model_name must have a [Model] keyword below, | | unless it is a reserved model name (POWER, GND, or NC). | | | | Each line must contain either three or six columns. A pin | | line with three columns only associates the pin's signal and | | model. Six columns can be used to override the default | | package values (specified under [Package]) FOR THAT PIN ONLY. | | When using six columns, the headers R_pin, L_pin, and C_pin | | must be listed. If "NA" is in columns 4 through 6, the | | default packaging values must be used. | | | | Column length limits are: | | [Pin] 5 characters max | | model_name 20 characters max | | signal_name 20 characters max | | R_pin 9 characters max | | L_pin 9 characters max | | C_pin 9 characters max | |------------------------------------------------------------------------------| [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 VCC3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF |******************************************************************************* |* BIRD10.1 ADDITION FOR VERSION 1.1Y |*============================================================================== |* Keyword: [Package Model] |* Required: No |* Description: Used to indicate the name of the package model |* Usage Rules: The Package_Model_Name is limited to 40 characters. |* Spaces are allowed in the name. |* Other Notes: |* The [Package_Model] keyword is used within a [Component] to indicate |* which package model should be used for that part. |* |* The resolved specification permits .ibs files to contain [Define |* Package Model] keywords as well. These are described |* "Syntax for the .pkg file", below. 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 which have the same |* name. |*------------------------------------------------------------------------------ |* [Package Model] Package_Model_Name |******************************************************************************* |******************************************************************************* |* BIRD10.1 ADDITION FOR VERSION 1.1Y |*============================================================================== |* NOTE, KEYWORDS FOR [Define Package Model] through [End Model Data] |* FOR EACH "Package_Model_Name" ARE CURRENTLY DEFINED IN BIRD10.1. THESE |* PACKAGE MODELS MAY IN A SEPARATE FILE .pkg ACCORDING |* TO BIRD10.1. THE KEYWORDS MAY ALSO EXIST IN IBIS FILES .ibs |* WITHIN [Define Package Model] ... [End Model Data] BLOCKS FOR EACH |* PACKAGE MODEL THAT IS DEFINED. FOR REFERENCE, THESE KEYWORDS THAT |* MAY EXIST IN THE IBIS FILE ARE LISTED HERE. REFER TO BIRD10.1 FOR |* THEIR FULL DESCRIPTION, SYNTAX AND USAGE. |* |* [Define Package Model] |* [Manufacturer] |* [OEM] |* [Description] |* [Number of Pins] |* [Pin Names] |* [Model Data] |* [Resistance Matrix] |* [Inductance Matrix] |* [Capacitance Matrix] |* [Row] |* [Bandwidth] |* [End Model Data] |*============================================================================== |******************************************************************************* |******************************************************************************* |* BIRD5.2 ADDITION FOR VERSION 1.1X |*========================================================================== |* Keyword: [Pin_Mapping] |* Required: Optional |*Description: Used to indicate which power and ground buses a given driver |* or receiver is connected. |* Sub-Params: gnd, pwr |*Usage Rules: Each power and ground bus is given a unique name which must |* not exceed 20 characters. The first column contains a pin |* number. Each pin number must match one of the pin numbers |* declared previously in the [Pin] section of the IBIS file. |* The second column, "gnd", designates the ground bus connection |* for that pin. Similarly, the third column, "pwr", designates |* the power bus connection. |* |* If the [Pin_Mapping] keyword is present, then the bus |* connections for EVERY pin listed in the [Pin] section must |* be given. |* |* If a pin has no connection, then both the "pwr" and "gnd" |* entries for it may by NC. |* |* Column length limits are: |* [Pin_Mapping] 5 characters max |* gnd 20 characters max |* pwr 20 characters max |*--------------------------------------------------------------------------- [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections ..... ..... ..... 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. ..... 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC ..... 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. ..... 41 NC PWRBUS2 | second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 |******************************************************************************* |******************************************************************************* |* BIRD6.2 ADDITION FOR VERSION 1.1X |*========================================================================== |* Keyword: [Diff_Pin] |* Required: Optional |*Description: Used to associate differential pins, their differential |* threshold voltages and differential timing delays. |* Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |*Usage Rules: Entries follow these rules: Only differential pin pairs |* are entered. The [Diff_pin] column contains a non-inverting |* pin number and the inv_pin column always contains the |* corresponding inverting pin number for output and I/O output. |* The vdiff column contains the specified differential threshold |* voltage between pins if the pins are Input or I/O Model_types. |* For Output only differential pins, the vdiff entry is 0V. |* The tdelay columns contain launch delays of the non-inverting |* pins relative to the inverting pins. The values can be either |* polarity. |* |* BIRD2.2 Addition within BIRD6.2 |* If a pin is a differential input pin the differential input threshold |* (vdiff) overrides and supercedes the need for Vinh and Vinl. |* |* If vdiff is not defined for a pin that is defined as requiring a Vinh by |* its [Model] type, the parser will issue a warning and vdiff will be set to |* the default value of 200mV. |* |*Other Notes: The output pin polarity specification in the table overrides From Derrick_Duehren@ccm2.jf.intel.com Fri May 6 23:13:50 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00428; Fri, 6 May 94 23:13:50 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0pzfaQ-000MNUC; Fri, 6 May 94 23:10 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 6 May 94 23:10:06 PST Date: Fri, 6 May 94 23:10:06 PST From: Derrick Duehren Message-Id: <940506231006_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Intel IBIS models now avail. in vhdl.org Text item: Text_1 Intel Corporation Parts now in vhdl.org \pub\ibis\models\intel: Directory File name Part # --------- --------- -------- 82420 cdc.iibs 82424zx 82420 dpu.ibs 82423tx 82420 sio.ibs 82378ib 82430 sio.ibs 82378ib 82430 pcmc.ibs 82434lx 82430 pceb.ibs 82375eb 82430 ibx.ibs 82433lx 82430 esc.ibs 82374eb dx4 dx4pga.ibs dx4pga neptune esc_b0.ibs 82374sb neptune pceb_b0.ibs 82375sb neptune sio_za0.ibs 82378zb neptune psc_a2.ibs 82425ex neptune ib_a1.ibs 82426ex - Derrick Duehren Intel Corp. From bob@icx.com Sat May 7 19:47:35 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10018; Sat, 7 May 94 19:47:35 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17638 for ; Sat, 7 May 94 22:44:47 -0400 Date: Sat, 7 May 94 19:39:27 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA22095; Sat, 7 May 94 19:39:27 PDT Message-Id: <9405080239.AA22095@icx.com> To: ibis@vhdl.org Subject: BIRD13 Comment To Bob and IBIS Committee: Some comments were already made and recorded in the minutes on BIRD13. Here are two additional minor points. (1) I feel that the clarification at the end of 2) and before 3) should be restated or deleted. It concerns allowing a relaxation of the voltage ranges for measurement derived data vs simulation derived data. I actually support reasonable ranges for data regardless of the source and let the simulators take care of any necessary extrapolations. Many simulators automatically extrapolate data, but those that do not would have to provide mathematically from the IBIS data the added points to, for example build the piece-linear sources. However, based on the fact that the conversions to such simulators currently do not require such extrapolations, there may be objection to relaxing the data range requirements for only measurement derived data. Either the data ranges would have to be relaxed for ALL data or for NO data because the simulator does not know the source of the data. As it stands, my current expectations are that models produced by measurements (or simulations) may have to provide mathematically extended data points to comply with the IBIS ranges. So the note could be rewritten to state this, or else deleted, or the measurement range requirement be for guidance only. (2) The proposal to add a note after step 7 that the rise/fall time typical of actual circuit in operation, I feel, may go too far. For some configurations, I do not think that a source ramp with slight rounding of corners should have any effect on the output. Many inputs are in the 0 to 3V or 0 to 5V range, and the actual switching thresholds are only several hunderd millivolts in the center of the ranges. So, while the intent of the statement is good, I think it extends into an unneccessary detail. Furthermore, there are some other technical considerations on how sensitive the actual response is to the input rise/fall times, the source impedance, etc,. and whether we are getting data for validation of specs or whether we are getting MODELING data. So I would prefer that this recommendation be deleted and expect that the manufacturers do what is necessary to get the data best suited for modeling the part. With the discussed corrections including using "load" notation of BIRD12.1, the other aspects of BIRD13 look good to me. Bob Ross, Interconnectix, Inc. From bob@icx.com Sat May 7 20:57:39 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10385; Sat, 7 May 94 20:57:39 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA27137 for ; Sat, 7 May 94 23:48:54 -0400 Date: Sat, 7 May 94 20:43:59 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA22173; Sat, 7 May 94 20:43:59 PDT Message-Id: <9405080343.AA22173@icx.com> To: ibis@vhdl.org Subject: BIRD14 Comment To John Keifer, Arpad Muranyi, and IBIS Committee: There are two proposals in BIRD14. The first concerns a new keyword [Specs] to override parameters of a particular [Model]. There is merit in this idea, but I am currently opposed to doing this now for some contradictory reasons - it overrides some parameters that I feel should not touched, and it does not include some parameters which would really be useful for efficiency. Furthermore, it provides an unneccessary level of indirection which can add to confusion to IBIS at this time and perhaps create a real problem for implementors using IBIS. Before we introduce [Specs] we really need a lot more consideration as to what is to be included (e.g, should Model_type also be included as a practical override, is Cref needed in IBIS, etc.). Your point is well taken, however, that such a keyword can help reduce much redundant [Model] data. The second proposal is about adding two more Sub Parameters to [Model]. The one parameter I really like is Vt for "test voltage". This is different than the V_fixture of BIRD12.1 and is more like the Output counterpart of Vinh and Vinl. I think it should be available as a timing sub-parameter, particularly for 3-state and Output models where Vinh and Vinl may not be available to help provide an estimate of Vt. As you show in the example, Vt will give the intended voltage on which timing at the output is based such as 1.5V or 2.5V. However, I think Cref should NOT be included because it is really a timing specification test capacitance (the specification resistance typically 500 Ohm would then also have to be included), and IBIS at this time does not cover actual absolute internal delay characterization. Other databases cover this area, and IBIS could incorrectly specify a load condition that is not used in the other databases. Bob Ross Interconnectix, Inc. From bob@icx.com Mon May 9 18:39:08 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02715; Mon, 9 May 94 18:39:08 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA21295 for ; Mon, 9 May 94 21:34:00 -0400 Date: Mon, 9 May 94 18:21:11 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA26551; Mon, 9 May 94 18:21:11 PDT Message-Id: <9405100121.AA26551@icx.com> To: ibis@vhdl.org Subject: WaVEFORMS FOR BIRD12.1 To Jon Powell, Arpad Muranyi, and IBIS Committee: This is an open implementation preference question based on the waveforms you have sent. In particular, refer to Jon Powell's "Synchronizing Measure AC Waveforms ... " document recently sent which illustrates the synchronization of rising and falling waveforms measured into 50 Ohm loads at 0, 2.5 and 5V. How do you "blend" certain data combinations that would be allowed via the BIRD12 [Rising waveform] and [Falling waveform] mechanisms? And which form would you prefer seeing? Cases --> (1) (2) (3) (4) Low_To_High: 50 Ohm to Vcc * * 50 Ohm to Vcc/2 * * 50 Ohm to GND * * * High_To_Low: 50 Ohm to Vcc * * * 50 Ohm to Vcc/2 * * 50 Ohm to GND * * Note, Case (1) corresponds to the [Ramp] specification conditions in IBIS Version 1.1. Bob Ross Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Tue May 10 22:52:08 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16807; Tue, 10 May 94 22:52:08 PDT Received: from ccm.jf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q179R-000MPAC; Tue, 10 May 94 22:48 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 10 May 94 22:48:11 PST Date: Tue, 10 May 94 22:48:11 PST From: Will Hobbs Message-Id: <940510224811_1@ccm.jf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Cc: John_M_Keifer@ccm.fm.intel.com, Don_A_Telian@ccm.fm.intel.com Subject: Assumptions BIRD Text item: Text_1 BIRD ID#: 15 ISSUE TITLE: Clarification on the usage of the V/I tables. REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: May 10, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: There is room for different interpretations regarding the usage of the various V/I tables in the current IBIS specification because it does not clearly explain all of the initial assumptions. If models are generated with one assumption and a simulation tool is based on another, inaccurate results may occur. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new section must be added to the IBIS specification, in which the assumptions governing model generation and usage is clearly spelled out. This section should be placed at the end of the "Usage Rules" of the [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] keyword section in the IBIS specification and should say the following: | Other Notes: ... | | Assumptions: It is assumed that the simulator sums the clamp | curves together with the appropriate pullup or | pulldown curve when a buffer is driving high or low, | respectively. From this assumption and the nature | of 3-statable buffers it follows that the data in | the clamping curve sections are handled as | constantly present curves and the pullup and | pulldown curves are used only when needed in the | simulation. | | The clamp curves of an input or I/O buffer can be | measured directly with a curve tracer, the I/O | buffer being 3-stated. However, sweeping enabled | buffers results in curves that are the sum of the | clamping curves and the output structures. Based on | the assumption outlined above, the pullup and | pulldown curves of an IBIS model must represent the | difference of the 3-stated and the enabled buffer's | curves. (Note that the resulting difference curve | may demonstrate a non-monotonic shape). This allows | the simulator to sum the curves, without the danger | of double counting, and arrive at an accurate model | in both the 3-stated and enabled conditions. | | Since in the case of a non 3-statable buffer this | difference curve cannot be generated through lab | measurements (because the clamping curves can not be | measured alone), the pullup and pulldown curves of | an IBIS model may contain the sum of the clamping | characteristics and the output structure. In this | case the clamping curves must contain all zeroes, or | the keywords must be omitted. | ************************************************************************* EXAMPLES: N/A ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Confusion raised in the IBIS open forum meetings during April 1994 led to the generation of this clarification for the IBIS specification. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: N/A ************************************************************************* From Will_Hobbs@ccm2.jf.intel.com Tue May 10 22:54:38 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16813; Tue, 10 May 94 22:54:38 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 10 May 94 22:52:05 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 10 May 94 22:51:31 -0700 Received: from ccMail by jfsmt2.intel.com id AA768635517 Tue, 10 May 94 22:51:57 PDT Date: Tue, 10 May 94 22:51:57 PDT From: "Hobbs, Will" Message-Id: <9404107686.AA768635517@jfsmt2.intel.com> To: bob@icx.com ( Bob Ross), ibis@vhdl.org Subject: WaVEFORMS FOR BIRD12.1 Bob, If I understand your question, for the Vcc/2 waveform, wouldn't (4) be the only valid option? Option (2) would also be correct if the load were 100 ohms each, for a total Thevenin equivalent of 50 ohms. Or am I out in left field? Will To Jon Powell, Arpad Muranyi, and IBIS Committee: This is an open implementation preference question based on the waveforms you have sent. In particular, refer to Jon Powell's "Synchronizing Measure AC Waveforms ... " document recently sent which illustrates the synchronization of rising and falling waveforms measured into 50 Ohm loads at 0, 2.5 and 5V. How do you "blend" certain data combinations that would be allowed via the BIRD12 [Rising waveform] and [Falling waveform] mechanisms? And which form would you prefer seeing? Cases --> (1) (2) (3) (4) Low_To_High: 50 Ohm to Vcc * * 50 Ohm to Vcc/2 * * 50 Ohm to GND * * * High_To_Low: 50 Ohm to Vcc * * * 50 Ohm to Vcc/2 * * 50 Ohm to GND * * Note, Case (1) corresponds to the [Ramp] specification conditions in IBIS Version 1.1. Bob Ross Interconnectix, Inc. From 71436.1314@CompuServe.COM Wed May 11 01:48:20 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18249; Wed, 11 May 94 01:48:20 PDT Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.940406sam) id EAA10007; Wed, 11 May 1994 04:45:53 -0400 Date: 11 May 94 04:42:53 EDT From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Assumptions BIRD Message-Id: <940511084253_71436.1314_HHB28-2@CompuServe.COM> From: Kellee Crisafulli To: Will and IBIS others I like Bird 15! It seemed to me to be easy to understand and it addresses a valid problem. Good job! Kellee.. From 71436.1314@CompuServe.COM Wed May 11 01:48:20 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18248; Wed, 11 May 94 01:48:20 PDT Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id EAA26178; Wed, 11 May 1994 04:45:53 -0400 Date: 11 May 94 04:42:52 EDT From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Bird 8.1 (The monotonic bird from 'L' files again) Message-Id: <940511084252_71436.1314_HHB28-1@CompuServe.COM> From: Kellee Crisafulli, Hyperlynx Inc. To: IBIS all Re: BIRD 8.1 (The bird from hell on monotonicity) Date: 5-10-94 I wrote down the following comments after the last meeting: (some editoral liberty was used) 1) The goal is to insure that simulators have a single valued function of current v.s. voltage to insure that they remain stable (i.e. the data is monotonic) 2) Monotonic will be defined to include 0 slope, i.e. a flat spot is ok. 3) The IBIS_CHK program should generate a WARNING if non-monotonic data is found. The warning should indicate that MOST simulators will filter the non-monotonic portion of the data out. The warning should also indicate that SOME simulators may go into oscillation as a result of using the non-monotonic data. 4) It is expected that simulators will load and filter the non-monotonic data without warnings to a user. This makes it possible for a semiconductor vendor to create data that is NOT monotonic and have it run without warnings on simulators. 5) To keep the IBIS_CHK program simple no attempt will be made to include the sum of currents form both the clamp and output stage. It was recognized that the sum of the two tables may be a monotonic output. I have revised birdy 8 based on what I believe was the general wisdom from the last meeting. Please give it a look and let me know if I accurately captured the thinking. ) ) ) ) \ \ \ \ \ \ ^^^^^ o o ( \___/ Have a sunny day....Kellee ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 8.1 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: January 29, 1994 DATE REVISED: 5-9-94 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:'. Note: An '*' is used to denote the changed lines) |============================================================================== | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves -of | the pulldown and pullup structures of an output buffer -and the | V/I curves of the clamping diodes connected to the GND -and the | POWER pins, respectively. | Usage Rules: In each of these sections the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All four columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | * The V/I table DATA SHOULD BE MONOTONIC to insure that most * simulators provide stable simulations. Monotonic data is * needed to insure that all data is single valued. MONOTONIC * DATA IS NOT REQUIRED to provide a valid IBIS model. * It is recognized that automated measurement equipment may * be used to acquire this data and as such may include "noise" * which causes the data to be non-monotonic. It is also recognized * that some device may be non-monotonic in certain regions. * Therefore the IBIS specification allows non-monotonic data. * Simulation tools should filter out non-monotonic data if * such data causes instabilities in the simulation results. * To be monotonic the V/I table data must meet any one of the * following 8 criteria: * 1- The CURRENT axis either increases or remains constant as * the voltage axis is increased. * 2- The CURRENT axis either increases or remains constant as * the voltage axis is decreased. * 3- The CURRENT axis either decreases or remains constant as * the voltage axis is increased. * 4- The CURRENT axis either decreases or remains constant as * the voltage axis is decreased. * * 5- The VOLTAGE axis either increases or remains constant as * the current axis is increased. * 6- The VOLTAGE axis either increases or remains constant as * the current axis is decreased. * 7- The VOLTAGE axis either decreases or remains constant as * the current axis is increased. * 8- The VOLTAGE axis either decreases or remains constant as * the current axis is decreased. * * The IBIS_CHK program will test for non-monotonic data and * provide the following warning if such data is found: * "WARNING: xxxx V/I table for model yyyy is non-monotonic! * Most simulators will filter this data to remove the * non-monotonic data." * Where xxxx is Pullup, Pulldown, GND_clamp or POWER_clamp. * Where yyyy is the name of the model. * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the version 2.0 IBIS_CHK program, it will consider only one * V/I table at a time monotonicity testing. * | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | [POWER_clamp] structures are 'Vcc relative', meaning that the | voltage values are referenced to the Vcc pin. The voltages in | the data tables are derived from the equation: | Vtable = Vcc - Voutput | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND_clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output if so | desired. |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions the results of the 1993 summit. Considerable email has passed on this discussion. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The IBIS_CHK program must also be modified to test for this condition. ------------------------------------------------------------------------------ From meeting Nov 5, 1993 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ------------------------------------------------------------------------------ 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------- ******************************************************************************** From cpk@Cadence.COM Wed May 11 07:04:36 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22048; Wed, 11 May 94 07:04:36 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id HAA22964 for ; Wed, 11 May 1994 07:02:07 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma022933; Wed May 11 07:01:34 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA16150; Wed, 11 May 94 06:45:52 -0700 Received: by hot (5.65+/1.5) id AA07429; Wed, 11 May 94 10:01:12 -0400 Date: Wed, 11 May 94 10:01:12 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9405111401.AA07429@hot> To: ibis@vhdl.org Subject: Re: Assumptions BIRD Since in the case of a non 3-statable buffer this | difference curve cannot be generated through lab | measurements (because the clamping curves can not be | measured alone), the pullup and pulldown curves of | an IBIS model may contain the sum of the clamping | characteristics and the output structure. In this | case the clamping curves must contain all zeroes, or | the keywords must be omitted. | In the above case non-3statable buffer, I will pprefer if the clamping curves are not present at all, rather than zeroing them. But either of the choices should not affect the parsing or the final simulation. - kumar From Will_Hobbs@ccm2.jf.intel.com Wed May 11 09:12:13 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22732; Wed, 11 May 94 09:12:13 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 May 94 09:09:38 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Wed, 11 May 94 09:08:31 -0700 Received: from ccMail by jfsmt2.intel.com id AA768672546 Wed, 11 May 94 09:09:06 PDT Date: Wed, 11 May 94 09:09:06 PDT From: "Hobbs, Will" Message-Id: <9404117686.AA768672546@jfsmt2.intel.com> To: ibis@vhdl.org, Kellee Crisafulli <71436.1314@CompuServe.COM> Subject: Re: Assumptions BIRD Kellee, I'm only the messanger. The praise goes to Arpad, and I concur-- well done! Will From: Kellee Crisafulli To: Will and IBIS others I like Bird 15! It seemed to me to be easy to understand and it addresses a valid problem. Good job! Kellee.. From Will_Hobbs@ccm2.jf.intel.com Wed May 11 09:22:34 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22805; Wed, 11 May 94 09:22:34 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 May 94 09:20:06 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Wed, 11 May 94 09:19:25 -0700 Received: from ccMail by jfsmt2.intel.com id AA768673203 Wed, 11 May 94 09:20:03 PDT Date: Wed, 11 May 94 09:20:03 PDT From: "Hobbs, Will" Message-Id: <9404117686.AA768673203@jfsmt2.intel.com> To: ibis@vhdl.org Subject: IBIS Agenda for 5/13 meeting IBIS Open Forum Meeting Agenda for 5/13/94 Bridge: Res: (415) 904-8944 721619 All meetings are 8:00 AM to 10:00 AM PST (15:00 to 17:00 UTC). When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. 8:00 Check-in Intros of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues All New models available All IBIS 2.0 Ratification/DAC/Other 2.0 Issues Hobbs - May 20 Editing meeting - DAC IBIS Birds of a Feather Session - Rev 2.0 Ratification Summit IBIS Cookbook Rosenbaum 8:30 BIRD 8, Spec. of V/I data monotonicity Crisafulli CLOSURE EXPECTED BIRD 12, Non-Linear Driver Waveforms Peters BIRD 13, Clarify Some Conditions of Measurements Ward BIRD 14, New section for [Model] sub-parameters Keifer BIRD 15, V/I Table Usage Clarifications Muranyi 9:55 Wrap-up, Next Meeting Plans Hobbs Important: Because of the 5/20 IBIS Specification editing session, I strongly urge us to close on all of these BIRDS at Friday's meeting. -- WH From bob@icx.com Wed May 11 09:32:35 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22876; Wed, 11 May 94 09:32:35 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18124 for ; Wed, 11 May 94 12:15:29 -0400 Date: Wed, 11 May 94 09:02:59 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA02539; Wed, 11 May 94 09:02:59 PDT Message-Id: <9405111602.AA02539@icx.com> To: Will_Hobbs@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re: WaVEFORMS FOR BIRD12.1 Will, I see the confusion. What I meant was that for Case (2), you would provide 4 waveforms for each of the R_fixture and V_fixture combinations listed. In Case (3), 6 waveforms would be provided. Jon's document showed six waveforms, all of which could be included in the IBIS [Model] description. I have no objection to having as much waveform characterization information as possible provided. It becomes a simulator vendor's problem to figure out how best to use this information (or to choose what information not to use). I raised the question to see if there were any preferred combinations, and any preferred ways of dealing with multiple sets of data. Bob > Bob, > If I understand your question, for the Vcc/2 waveform, > wouldn't (4) be the only valid option? Option (2) would > also be correct if the load were 100 ohms each, for a total > Thevenin equivalent of 50 ohms. Or am I out in left field? > Will > To Jon Powell, Arpad Muranyi, and IBIS Committee: > This is an open implementation preference question based on the waveforms > you have sent. In particular, refer to Jon Powell's "Synchronizing > Measure AC Waveforms ... " document recently sent which illustrates > the synchronization of rising and falling waveforms measured into > 50 Ohm loads at 0, 2.5 and 5V. > How do you "blend" certain data combinations that would be allowed via the > BIRD12 [Rising waveform] and [Falling waveform] mechanisms? And which > form would you prefer seeing? > Cases --> (1) (2) (3) (4) > Low_To_High: > 50 Ohm to Vcc * * > 50 Ohm to Vcc/2 * * > 50 Ohm to GND * * * > High_To_Low: > 50 Ohm to Vcc * * * > 50 Ohm to Vcc/2 * * > 50 Ohm to GND * * > Note, Case (1) corresponds to the [Ramp] specification conditions in IBIS > Version 1.1. > Bob Ross > Interconnectix, Inc. From coleman@SSD.intel.com Wed May 11 10:18:36 1994 Return-Path: Received: from SSD.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23191; Wed, 11 May 94 10:18:36 PDT Received: from fuji.SSD.intel.com by SSD.intel.com (4.1/SMI-4.1) id AA05139; Wed, 11 May 94 10:16:04 PDT From: David Coleman Message-Id: <9405111716.AA05139@SSD.intel.com> Subject: BIRD 15 To: ibis@vhdl.org Date: Wed, 11 May 1994 10:16:01 -0700 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 321 I wish to thank all involved for clearing up (simplifying) the use of shunt I/V curves. It just makes sense since the I/V curve represents a point source which by definition must superimpose all the included I/V sources. Thanks, Dave Coleman Intel Supercomputer Systems Division coleman@SSD.intel.com (503) 629 4336 From jonp@qdt.com Wed May 11 11:18:13 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24257; Wed, 11 May 94 11:18:13 PDT Received: from uucp3.uu.net by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16138; Wed, 11 May 94 14:15:47 -0400 Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Wed, 11 May 1994 14:15:45 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00717; Wed, 11 May 94 10:40:37 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA28691; Wed, 11 May 94 10:40:37 PDT Date: Wed, 11 May 94 10:40:37 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9405111740.AA28691@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA06845; Wed, 11 May 94 10:40:39 PDT To: ibis@vhdl.org In-Reply-To: Will Hobbs's message of Tue, 10 May 94 22:48:11 PST <940510224811_1@ccm.jf.intel.com> Subject: Assumptions BIRD I disagree with bird 15. I believe that the possition taken, though teniable, is not necessarily the best approach and should NOT be required. jonp From jonp@qdt.com Wed May 11 11:18:16 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24258; Wed, 11 May 94 11:18:16 PDT Received: from uucp3.uu.net by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16149; Wed, 11 May 94 14:15:50 -0400 Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Wed, 11 May 1994 14:15:48 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00746; Wed, 11 May 94 10:59:57 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA28747; Wed, 11 May 94 10:59:57 PDT Date: Wed, 11 May 94 10:59:57 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9405111759.AA28747@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA06849; Wed, 11 May 94 10:59:59 PDT To: ibis@vhdl.org Subject: BIRD 15 I think bird 15 is a bandaid. It goes agaiinst what IBIS reas now and changes the flavor of things. I think that if a person cannot make the necessary measurements for the way the IBIS drivers are stated to work (That is, clamp currents go in the clamp sectioons) then they should use the alternative data format that is being defined in the other ongoin bird that Steve is working on. We don't need two ways to solve this problem and I feel we are muddyling the waters as opposed to clearing them. really, jonp From Arpad_Muranyi@ccm.fm.intel.com Wed May 11 17:35:58 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28289; Wed, 11 May 94 17:35:58 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q1Oh0-000MNVC; Wed, 11 May 94 17:32 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 11 May 94 17:32:01 PST Date: Wed, 11 May 94 17:32:01 PST From: Arpad Muranyi Message-Id: <940511173201_5@ccm.hf.intel.com> To: ibis@vhdl.org Cc: John_M_Keifer@ccm.fm.intel.com Subject: Re: BIRD14 Comment ---------------------------- Forwarded with Changes --------------------------- From: John M Keifer Date: 5/11/94 4:22PM To: Arpad Muranyi Subject: Re[4]: BIRD14 Comment ------------------------------------------------------------------------------- To Bob Ross, and The IBIS Committee: In response to the BIRD14 Comment below, I don't understand why you have problems with overriding the IBIS [Model] sub-parameters. The IBIS [Model]s are not supposed to be specs out of a data book; however, the entire .IBS file should follow what is found in data books. The [Specs] section would not contradict this. I expect this would only reduce the number of redundant [Model]s, as you noted. My intention with the [Specs] section is not to provide an unnecessary level of indirection which could add to confusion to IBIS. Unfortunately I don't see any better way to eliminate the redundant [Model]s without adding this new section. Although I do believe we should make IBIS simple and straightforward, that should not prevent us from making improvements. I am open to adding sub-parameters to the [Specs] section that might be useful for efficiency. Regarding the Model-types as sub-parameters, the Model-types I can see now that might overlap (i.e. have the same IV curves, C_comp, and ramp rates) would be Output, I/O, and 3-state buffers. However, if an Output is specified without clamp sections as described in BIRD 15, (i.e. the clamps are included in the pullup and pulldown sections because they cannot be measured separately) then only the I/O and 3-state [Model]s would have the same data. Still, I can see this as a potential gain in simplification, and if the IBIS Committee agrees to it, I would not be opposed. A couple of people have already suggested adding Rref and Vref in order to cover open-drain [Model]s. I would also not be opposed to this if the IBIS Committee agrees it is a good idea. I am glad to hear that you agree with adding Vt. It IS the Output counterpart of Vinl and Vinh; however, Cref is just as important. Cref is not an actual absolute internal delay characterization. Valid delays are specified into a Cref at a Vt, and therefore, the timing at an output is based on this same Cref at Vt. Cref is not just a test capacitance. It is a parameter that all simulators MUST use in order to determine timings. Even though Cref is 0pF in many cases, it is still used. It poses a serious handicap to those performing simulations to have to add in this parameter manually because it is not included in the IBIS [Model]. What database contains the load condition? Cref is obtained from a data book and therefore should not contradict any other database. John Keifer Intel Corporation To John Keifer, Arpad Muranyi, and IBIS Committee: There are two proposals in BIRD14. The first concerns a new keyword [Specs] to override parameters of a particular [Model]. There is merit in this idea, but I am currently opposed to doing this now for some contradictory reasons - it overrides some parameters that I feel should not touched, and it does not include some parameters which would really be useful for efficiency. Furthermore, it provides an unnecessary level of indirection which can add to confusion to IBIS at this time and perhaps create a real problem for implementors using IBIS. Before we introduce [Specs] we really need a lot more consideration as to what is to be included (e.g., should Model_type also be included as a practical override, is Cref needed in IBIS, etc.). Your point is well taken, however, that such a keyword can help reduce much redundant [Model] data. The second proposal is about adding two more Sub Parameters to [Model]. The one parameter I really like is Vt for "test voltage". This is different than the V_fixture of BIRD12.1 and is more like the Output counterpart of Vinh and Vinl. I think it should be available as a timing sub-parameter, particularly for 3-state and Output models where Vinh and Vinl may not be available to help provide an estimate of Vt. As you show in the example, Vt will give the intended voltage on which timing at the output is based such as 1.5V or 2.5V. However, I think Cref should NOT be included because it is really a timing specification test capacitance (the specification resistance typically 500 Ohm would then also have to be included), and IBIS at this time does not cover actual absolute internal delay characterization. Other databases cover this area, and IBIS could incorrectly specify a load condition that is not used in the other databases. Bob Ross Interconnectix, Inc. From speters@ichips.intel.com Wed May 11 17:50:26 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28385; Wed, 11 May 94 17:50:26 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 May 94 17:47:55 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 11 May 94 17:47:10 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 11 May 94 17:47:51 PDT Message-Id: <9405120047.AA03108@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD 12 comment solicitation Date: Wed, 11 May 1994 17:47:50 -0700 From: Stephen Peters Hello fellow IBISans -- This is just a friendly reminder that BIRD 12 is due for a vote at Fridays meeting. If you have any comment/concerns/objections please speak up before the teleconference. Thanks..... Regards, Stephen Peters Intel Corp. From bob@icx.com Wed May 11 22:38:16 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29948; Wed, 11 May 94 22:38:16 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA25047 for ; Thu, 12 May 94 01:30:30 -0400 Date: Wed, 11 May 94 22:22:34 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA05037; Wed, 11 May 94 22:22:34 PDT Message-Id: <9405120522.AA05037@icx.com> To: ibis@vhdl.org Subject: BIRD14 Reply To John Keifer and IBIS Committee: Thank you John for your response. I still have a problem with Cref being in IBIS (as a timing spec validation capacitor), but you may have a valid argument for having it in. My problem is that IBIS models are used for signal integrity applications and also for timing applications ON THE NET under the actual (transmission line like) load conditions. Cref does not enter into the picture other than perhaps computing some timing calibration adjustment parameter to correlate timing specified based by data book test conditions, and waveform shape timing change due to actual load conditions. So if Cref is really useful then I would not object to having it in. At this time, however, I do not see Cref or any other proposed parameter as being required. Any parameter that is not required cannot be relied upon to exist by simulator vendors. So at worst the additional parameters may be for information only. I am not familiar with timing data bases, but I accept as you indicated that they would be based on the data book specification load conditions. Comments anyone? My primary concern about [SPECS] is that it is a good idea that needs to be thought out thoroughly before it is adopted because it would be harmful to IBIS for compatibilty reasons to be stuck with a poor (or limited) implementation. In terms of "indirection", one complication may be to those implementers who are providing model parameter display capability. Now they may also have to consider actual [Component] and the actual pin number to correctly characterize the [Model] (Several components can refer to the same model in a file). The "indirection" issue can be resolved easily, but we already have complicaitons with new keywords for [Package Model], [Pin_Mapping], [Diff_Pin], some of which override parameters. Currently IBIS [Models] can reside in separate files (but potentially have the same name) and (optional) package models can reside in other files. This all may imply some simulator specific indexing techniques to tie all of the variations together, so appropriate care is needed before adding another variation. Should the [Specs] include all available sub-parameters? Should it be split up into two keyword: [Required Specs] and [Optional Specs]? What happens if a new sub-parameter is added at a later date? Alternatively, should [Specs] just contain a minimal set of overrides so that it cannot be overused?, E.g., does C_comp really vary significantly in practice for the I/O structure with the same set of VI data? Adding Model_type could be one of the more useful additions. It is possible with just one filled [Model] (e.g. an I/O model) to use it for all of the model_types of a buffer including Input and the Open_drain, Open_sink cases. Tables which are not used can still exist in the [Model]. For example, IBIS_CHK accepts an Input model with a [Ramp] specificaton. Assuming the clamping curves are the same, the C_comp for I/O would be larger than C_comp for the same model as an Input, and [Spec] captures this variation. This would be an example of a very robust usage of the [Spec] capability. What about optional sub-parameters of Polarity and Enable? It would be wasteful to repeat a complete model if just the Polarity has changed. I am raising these questions to promote discussion and consideration. I believe that support of the proposed [Spec] keyword would be REQUIRED by all implementors because the keyword intentionally alters the [Model] for a specific pin. Therefore, I feel that extra care and consideration be taken before we adopt this part of BIRD14. Bob Ross Interconnectix, Inc. From speters@ichips.intel.com Thu May 12 09:00:12 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06695; Thu, 12 May 94 09:00:12 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 12 May 94 08:57:37 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 12 May 94 08:56:29 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 12 May 94 08:57:21 PDT Message-Id: <9405121557.AA04640@xtg801.intel.com> To: ibis@vhdl.org Subject: Bird 14 comments Date: Thu, 12 May 1994 08:57:20 -0700 From: Stephen Peters Hello Fellow IBISans -- I've been following the comments going back and forth on Bird 14, and somthing Bob Ross said in this last reply struck me as fundemental to how we wish to 'grow' this specification. Bob's comment was: "....So if Cref is really useful then I would not object to having it in. At this time, however, I do not see Cref or any other proposed parameter as being required. Any parameter that is not required cannot be relied upon to exist by simulator vendors. So at worst the additional parameters may be for information only....." As I see it, bird 14 takes IBIS beyond simply providing basic information for signal integry analysis into providing 'data book' information; enough for full board timing simulation. If this type ^^^^^^ of information is not *required* or directly used by the simulator to produce waveforms, then we have two distinct types of models -- one for signal integrey analysis and a more complex one that helps in full board timing simulations. Perhaps this is a good place to make the break between Level 1 models and Level 2 models. Comments, anyone? From cpk@Cadence.COM Thu May 12 09:46:36 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07015; Thu, 12 May 94 09:46:36 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id JAA15059 for ; Thu, 12 May 1994 09:44:08 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma014965; Thu May 12 09:43:40 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA05806; Thu, 12 May 94 09:27:47 -0700 Received: by hot (5.65+/1.5) id AA08229; Thu, 12 May 94 12:43:17 -0400 Date: Thu, 12 May 94 12:43:17 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9405121643.AA08229@hot> To: ibis@vhdl.org Subject: Re: Bird 14 comments > Hello Fellow IBISans -- > > I've been following the comments going back and forth on Bird 14, > and somthing Bob Ross said in this last reply struck me as fundemental > to how we wish to 'grow' this specification. Bob's comment was: > > "....So if Cref is really useful then I would not object to having it in. At > this time, however, I do not see Cref or any other proposed parameter as > being required. Any parameter that is not required cannot be relied upon to > exist by simulator vendors. So at worst the additional parameters may be > for information only....." > > > As I see it, bird 14 takes IBIS beyond simply providing basic > information for signal integry analysis into providing 'data book' > information; enough for full board timing simulation. If this type > ^^^^^^ > of information is not *required* or directly used by the simulator to > produce waveforms, then we have two distinct types of models -- one for > signal integrey analysis and a more complex one that helps in full board > timing simulations. Perhaps this is a good place to make the break between > Level 1 models and Level 2 models. Comments, anyone? > This goes back to my suggestion few weeks ago. I suggested that it is natural to have timing information under IBIS. Timing information can follow a a format similar to the one proposed for package models. - Kumar From bward@sugar.NeoSoft.COM Thu May 12 11:29:25 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07784; Thu, 12 May 94 11:29:25 PDT Received: by sugar.NeoSoft.COM id AA06753 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Thu, 12 May 1994 13:26:46 -0500 Message-Id: <199405121826.AA06753@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Bird 14 thread Date: Thu, 12 May 94 13:26:40 CDT Hi, all you ibis folk - I have just seen some mail suggesting that this bird takes ibis beyond SI and into timing analysis. I opened that box a while ago, as Kumar referred to in suggesting setup and hold times. The concensus was that we should not try to be all things to all people at this time, and I agree. In particular I feel that if we are going to go to general board level timing capabilities, which I feel is a good way to go and is very valuable, we need to discuss it a LOT more deeply than we possibly can before version 2. I move that we table this until after version 2 and some resolution of the specifics of levels and nest this in version 3 discussions. Or at least 2.n where n > 0. This is worthy of careful work as it offers a very real selling point for IBIS, but if it is not carefully done the selling value will be negative. Bob Ward bward@neosoft.com or bward@dadhb1.ti.com From cpk@Cadence.COM Thu May 12 11:45:37 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07919; Thu, 12 May 94 11:45:37 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id LAA24974 for ; Thu, 12 May 1994 11:43:09 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma024925; Thu May 12 11:42:43 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA17102; Thu, 12 May 94 11:26:50 -0700 Received: by hot (5.65+/1.5) id AA08290; Thu, 12 May 94 14:42:21 -0400 Date: Thu, 12 May 94 14:42:21 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9405121842.AA08290@hot> To: ibis@vhdl.org Subject: Re: Bird 14 thread I second Bob on that. That is , timing is important and worthwhile for us to do but can wait till 2.0 is out of the door. - kumar From intgrty!phil@kksys.com Thu May 12 13:12:15 1994 Return-Path: Received: from kksys.skypoint.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08456; Thu, 12 May 94 13:12:15 PDT Received: by kksys.skypoint.net (Smail3.1.28.1 #15) id m0q1goG-0007xcC; Thu, 12 May 94 14:52 CDT Received: by intgrty.intgrty.mn.org (4.1/SMI-4.1) id AA03413; Thu, 12 May 94 11:50:34 CDT Date: Thu, 12 May 94 11:50:34 CDT From: kksys!intgrty!phil (Phil Kleineschay ) Message-Id: <9405121650.AA03413@intgrty.intgrty.mn.org> To: IBIS@kksys.com, Committee@kksys.com From: Greg Doyle gdoyle@intgrty.mn.org Subject: Including Vt, Cref, Rref & Vref in IBIS models I support adding this information to the IBIS models for the following reason(s). People use signal integrity tools for many different reasons. Some use them for up front rules generation, some for back end signal integrity verification and (ugh!) people use them for debug. The byproduct of the powerful capabilities we all provide to the users is that they can get timing delays for the interconnects and then use them to check system level paths. We have all read the papers showing how as the clock speeds go up, the interconnects start to become the critical path. This makes the ability for a SI tool to easily fit into the design process more important. As a result of this, system designers see the signal integrity tools as satisfying two needs. One is to give the circuit designer a toy to play with. The second is to get the circuit designer to get accurate delay values back into a system timing simulation. One of the problems with doing this over time has been that the delay through SSI devices were typically specified at a predetermined load condition, typically 50pF and perhaps a pullup resistor or diode. This was done to give some guard band for the testing environment and also to give the design engineer some margin to account for a "representative" load seen by the driver in an application. Unfortunately, this method is somewhat dated as a high speed driver sees a transmission line, not a lumped load. Many devices today are characterized at no load because the SI tools will allow the designer to calculate the interconnect delays, where in the past they were not available. Secondly, the tester environments look nearly invisible to a driver under testing conditions, so the need to add guard banding is gone. To simply add the interconnect delay defined as the delay from the output of the driver to the input to a receiver to the part delay would create the situation of double counting. Therein lies the problem. Different tools try to account for this in different ways. The common piece of information needed to try and adjust for this is the loading conditions for the delay characterization measurements/simulations. So after all of this testimonial, what I am saying is that SI tools are being used for a variety of purposes today. IBIS was designed to allow these SI tools be used with much more ease. Namely, to prevent users from having to build/edit models by hand. This has been a barrier to making SI tools proliferate. As time goes on, speeds will increase, making the role of the SI tools even more tied to system level timing analysis. To allow IBIS to be used as it is perceived, "Everything you need to define a part", we must be open to allowing new parameters be supported by the IBIS model. The users are going to demand this from the committee when they get IBIS models and then are asked to edit/supplement them with additional information. As users join the forum, they will demand that the IBIS spec be extended to make all databook parameters used by a SI tool available (and required?). This makes the IBIS model as transparent to the user as possible. Typically, the functionality of the device is supplied to the user in a Verilog or VHDL model, thus it is not important to include this. What John Keifer proposed was to make these parameters optional. It is my feeling that IBIS should be extended to include as much databook information about a part as possible. If a simulation tool does not use certain information, it should skip over the data. This philosophy allows the user community to benefit the most from the models. If they have to continually add and edit the vendor supplied model to fit into their simulator, IBIS will lose its appeal and we will all lose. OK, I'll shut up for now. Greg Doyle From canright@neptune.convex.com Fri May 13 07:37:45 1994 Return-Path: Received: from convex.convex.com (convex-inet.convex.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18659; Fri, 13 May 94 07:37:45 PDT Received: from neptune.convex.com by convex.convex.com (5.64/1.35) id AA10903; Fri, 13 May 94 09:31:55 -0500 Received: by neptune.convex.com (5.64/1.28) id AA18519; Fri, 13 May 94 09:32:16 -0500 From: canright@neptune.convex.com (Robert Canright) Message-Id: <9405131432.AA18519@neptune.convex.com> Subject: comment on signal integrity To: gdoyle@intgrty.mn.org Date: Fri, 13 May 94 9:32:16 CDT Cc: ibis@vhdl.org X-Mailer: ELM [version 2.3 PL11] Greg, On the ibis reflector you posted email with the subject: Including Vt, Cref, Rref & Vref in IBIS models. You made a comment: "As a result of this, system designers see the signal integrity tools as satisfying two needs. One is to give the circuit designer a toy to play with. The second is to get the circuit designer to get accurate delay values back into a system timing simulation." From your comment it sounds like in your opinion the only thing you can count on a circuit designer to acheive with a signal integrity tool is to get delay. Anything else he might achieve is a roll of the dice. And mostly the circuit designer uses the signal integrity tool to teach himself transmission line behavior empirically: by playing with it. This means that the circuit designer does not know enough about transmission line theory to be an effective user of signal integrity tools. So for signal integrity tools to be effective, a company needs at least 1 signal integrity specialist that is an effective user of the tools. The 1 specialist can tell the many circuit designers how to most effectively use the tools. I believe that the poor sales of signal integrity tools is related to the lack of specialists in the companies to use them. I'm sure the companies will resist having a specialist, but they need at least one expert-- and I don't mean a talented amateur who dabbles in signal integrity. I've seen lots of amateurs that empress other circuit designers with their knowledge, but that actually do as much harm as good because their knowledge is shallow. When have you ever seen an advertisement saying a company wanted to hire a signal integrity specialist? When Convex advertised for the position I now have, they advertised for a high performance packaging engineer. I don't do any packaging. I do signal integrity. If the signal integrity tools are not used, then the IBIS models will not be used. You have to sell more that IBIS models or CAD tools. You have to sell the need for an entirely "new" profession: signal integrity. -- Bob Canright Convex Computer Corp. Richardson, Texas 214-497-4474 (desk) canright@convex.com 214-497-4500 (FAX) disclaimer: It's not my typing, the Sun keyboard repeeeatsss. From JAYD@RALVM29.VNET.IBM.COM Fri May 13 09:38:39 1994 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19483; Fri, 13 May 94 09:38:39 PDT Message-Id: <9405131638.AA19483@vhdl.vhdl.org> Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 6382; Fri, 13 May 94 12:34:59 EDT Date: Fri, 13 May 94 12:19:30 EDT From: "J. C. (Jay) Diepenbrock ((919)-543-8804)" X-Addr: Transceiver Technology Dev't, D63/061 IBM Network Hdwe. Div. P. O. Box 12195 Research Triangle Park, NC 27709 To: ibis@vhdl.org Subject: Signal Integrity engineers, Cref, etc. Greetings IBISers, I have a couple of comments on recent discussions. I agree wholeheartedly with Greg Canright's comments regarding the need for "Signal Integrity Engineers" and the difficulty in selling that need to management. The common belief seems to be that the realm of signal integrity management is something that can be picked up whenever it's needed by the average logic designer, rather than a specialty that should be developed and kept around to prevent problems before they happen rather than fix them after the fact. The latter of course causes missed system announcments, blown budgets and schedules, etc., etc. I hope that Greg Doyle is mistaken when he says that one of the primary uses of SI tools is for what I'll call "learning by fooling around," but perhaps not. On the need for Cref, I can see how it would be useful to be able to generate a test waveform using an IBIS model that one could compare to hardware with the same standard test load (typically 500 Ohms and 50 pF to Ground), but IBIS models as I understand them are really not intended to provide what might be called Block Delay information anyway, just the Net Delay due to transmission line effects and such. My understanding was that if one wanted real PATH delays that a timing analysis tool such as Motive (tm) from Quad was required, to add the intrinsic block delay to the output net delay. I see no real benefit in doing SI analysis on a real board with any lumped load other than checking the SI/timing tools against a databook (debugging models?), since there's no such thing as a board with a 50 pf, 500 Ohm load to Ground except characterization boards deliberately built that way. Input thresholds are a different matter, since they are needed to calculate the net delays, check for multiple threshold crossings, etc. Did I miss some- thing here? Jay Diepenbrock From 71436.1314@CompuServe.COM Fri May 13 09:55:29 1994 Return-Path: <71436.1314@CompuServe.COM> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19593; Fri, 13 May 94 09:55:29 PDT Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.940406sam) id MAA14137; Fri, 13 May 1994 12:53:00 -0400 Date: 13 May 94 12:50:42 EDT From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: Bird 8.2 update from Kellee per meeting today Message-Id: <940513165042_71436.1314_HHB75-1@CompuServe.COM> From: Kellee Crisafulli, Hyperlynx Inc. To: IBIS all Re: BIRD 8.2 (The bird from hell on monotonicity) Date: 5-13-94 I have added 2 more things to the BIRD per our meeting today. 1) Change WARNING to NOTE in IBIS_CHK output 2) Specify that the IBIS_CHK program will output line numer of line which is non-monotonic The following changes were previously made for rev 8.1 1) The goal is to insure that simulators have a single valued function of current v.s. voltage to insure that they remain stable (i.e. the data is monotonic) 2) Monotonic will be defined to include 0 slope, i.e. a flat spot is ok. 3) The IBIS_CHK program should generate a WARNING if non-monotonic data is found. The warning should indicate that MOST simulators will filter the non-monotonic portion of the data out. The warning should also indicate that SOME simulators may go into oscillation as a result of using the non-monotonic data. 4) It is expected that simulators will load and filter the non-monotonic data without warnings to a user. This makes it possible for a semiconductor vendor to create data that is NOT monotonic and have it run without warnings on simulators. 5) To keep the IBIS_CHK program simple no attempt will be made to include the sum of currents form both the clamp and output stage. It was recognized that the sum of the two tables may be a monotonic output. I have revised birdy 8 based on what I believe was the general wisdom from the last meeting. Please give it a look and let me know if I accurately captured the thinking. ) ) ) ) \ \ \ \ \ \ ^^^^^ o o ( \___/ Have a sunny day....Kellee ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 8.1 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: January 29, 1994 DATE REVISED: 5-9-94 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:'. Note: An '*' is used to denote the changed lines) |============================================================================== | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves -of | the pulldown and pullup structures of an output buffer -and the | V/I curves of the clamping diodes connected to the GND -and the | POWER pins, respectively. | Usage Rules: In each of these sections the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All four columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | * The V/I table DATA SHOULD BE MONOTONIC to insure that most * simulators provide stable simulations. Monotonic data is * needed to insure that all data is single valued. MONOTONIC * DATA IS NOT REQUIRED to provide a valid IBIS model. * It is recognized that automated measurement equipment may * be used to acquire this data and as such may include "noise" * which causes the data to be non-monotonic. It is also recognized * that some device may be non-monotonic in certain regions. * Therefore the IBIS specification allows non-monotonic data. * Simulation tools should filter out non-monotonic data if * such data causes instabilities in the simulation results. * To be monotonic the V/I table data must meet any one of the * following 8 criteria: * 1- The CURRENT axis either increases or remains constant as * the voltage axis is increased. * 2- The CURRENT axis either increases or remains constant as * the voltage axis is decreased. * 3- The CURRENT axis either decreases or remains constant as * the voltage axis is increased. * 4- The CURRENT axis either decreases or remains constant as * the voltage axis is decreased. * * 5- The VOLTAGE axis either increases or remains constant as * the current axis is increased. * 6- The VOLTAGE axis either increases or remains constant as * the current axis is decreased. * 7- The VOLTAGE axis either decreases or remains constant as * the current axis is increased. * 8- The VOLTAGE axis either decreases or remains constant as * the current axis is decreased. * * The IBIS_CHK program will test for non-monotonic data and * provide a maximum of one note per V/I table if non-montonic * data is found. * "NOTE: Line xxx of V/I table yyy for model zzz is * non-monotonic! Most simulators will filter this data * to remove the non-monotonic data." * Where xxx is the line number in the IBIS file. * Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. * Where zzz is the name of the model. * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the version 2.0 IBIS_CHK program, it will consider only one * V/I table at a time monotonicity testing. * | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | [POWER_clamp] structures are 'Vcc relative', meaning that the | voltage values are referenced to the Vcc pin. The voltages in | the data tables are derived from the equation: | Vtable = Vcc - Voutput | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND_clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output if so | desired. |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions the results of the 1993 summit. Considerable email has passed on this discussion. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The IBIS_CHK program must also be modified to test for this condition. ------------------------------------------------------------------------------ From meeting Nov 5, 1993 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ------------------------------------------------------------------------------ 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------- ******************************************************************************** From speters@ichips.intel.com Fri May 13 10:43:07 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19883; Fri, 13 May 94 10:43:07 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 13 May 94 10:40:07 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 13 May 94 10:38:51 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 13 May 94 10:40:02 PDT Message-Id: <9405131740.AA07555@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD 12.1 Date: Fri, 13 May 1994 10:40:01 -0700 From: Stephen Peters Hello Fellow IBISians -- I've updated Bird 12.1 to 12.2, adding in the changes agreed on before the vote. The specific changes are 1) added the limit of 100 waveform tables maximum and 2) corrected a typo in the last paragraph in the 'statement of the resolved specifications' section dealing with the required subparameters. The required subparamters are R_fixture and V_fixture. Thanks again for all your input. Best Regards, Stephen Peters Intel Corp. ----------------------- CUT HERE ------------------------------ Buffer Issue Resolution Document (BIRD) BIRD ID#: 12.1 ISSUE TITLE: Non-Linear Driver Waveforms REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: April 25, 1994, Revised April 29, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: May 13, 1994 ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The IBIS specification does not contain enough information to adequately describe the characteristics of a device whose output switching waveform is significantly non-linear. This BIRD proposes a method to describe these non-linear ramp waveforms. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are added to the specification, [Rising waveform] and [Falling waveform]. These keywords introduce a table of time vs. voltage points that describe the shape of a waveform. | | Keywords: [Rising waveform], [Falling waveform] | Required: No | Description: Used to describe the shape of the rising and falling edge | waveforms of a driver. | Sub-params: R_fixture, V_fixture, C_fixture, L_fixture, | R_dut, L_dut, C_dut | Usage Rules: Each [Rising waveform] and [Falling waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required, however, data | is only required in the typical column. If minimum | or maximum data is not available the reserved word "NA" | is used. The first value in the time column does not | have to be '0'. Time values must increase as | one parses down the table. The waveform table may | contain a maximum of 100 data points. There is a | maximum of 100 waveform tables allowed per model. | Note that for backwards compatibility the existing | [Ramp] keyword is still required. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. | | A [Model] specification can contain more than one | rising edge or falling edge waveform table; | however, each new table must begin with the appropriate | keyword and sub-parameter list as shown below. If more | than one rising or falling edge waveform table is | present, then the data in each of the respective tables | must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a | common reference point on the input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. | The R_dut, C_dut, and L_dut are analogous to the the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | | \/ | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | [Rising waveform] R_fixture = 500 V_fixture = 5.0 C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Currently, the IBIS specification assumes that all devices can be described accurately using a single risetime and falltime parameter. In other words, the switching waveform of the device is a relatively linear ramp. However, devices that shape the output waveform (risetime controlled devices) do not have a linear switching ramp. Trying to model devices of this type using a linear ramp model results in mis-predicting both the time to logic threshold and maximum edge rate. As IBIS is a specification that focuses on the behavior of a device rather than it structure or implementation, it would be ideal if there were a simple set of measurements one could take in order to describe the non-linearity. Obviously, the waveform shape itself is a good place to start. The fundamental assumption here is that the shape of the waveform, combined with the loading conditions, give simulator vendors enough additional information to construct accurate models of non-linear waveform drivers. Ideally, an IBIS model will include waveforms taken under several different loading conditions (R_fixture and V_fixture). By choosing the appropriate loading conditions a modeler can give the simulator vendors enough information to accurately simulate a device. The most straight forward way to describe a waveform shape is with a table of time vs. voltage points. (Note that one could take this table and enter it into a spreadsheet or graphing program and produce a picture of the waveform -- and that is one of the intents of the format.) One remaining issue is the ability to align the starting points of waveforms taken under different loading conditions (i.e. waveforms in two different tables). Jon Powell (Quad Design) has an action item to produce various waveforms and show this is possible. (PLEASE SEE THE NOTE BELOW ON VERSION 12.0 TO 12.1 CHANGES) In addition to providing more complete information to simulator vendors, explicitly describing the waveform allows one to validate a particular simulator's results. By performing a simulation into the specified load(s) and then comparing the results with the waveform(s) as listed in the IBIS file, one can perform anything from a quick sanity check of the data to a detailed analysis between simulators. A 'self-validating' model is a very powerful tool for checking and maintaining model quality. VERSION 12.0 TO 12.1 CHANGES: Based on e-mail suggestions and conversions in the April 29th IBIS open forum the following changes were made: 1. The sub-parameters now have an '=' between the sub-parameter name and value. 2. The maximum number of data points in a waveform table has been specified (100 max). 3. A statement was added that requires that all rising/falling edge data be time correlated. To make this perfectly clear: the data in one rising edge table must be time correlated to the data in any other RISING edge waveform table. Likewise for falling edge data. There is no requirement for time correlation between the data in rising and falling waveform tables. Note also the requirement that the correlation be to a reference point on the input stimulus waveform. This is to prevent a user from time correlating the waveforms to a point on an output waveform -- this defeats the purpose of time correlation. 4. The sub_parameters were expanded and changed from 'load' to 'dut' and 'fixture' to better indicate there proper use. A connection diagram was also added. 5. Cleaned up a few typos in the original version. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From bracken@bacon.performance.com Fri May 13 11:05:32 1994 Return-Path: Received: from bacon.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20106; Fri, 13 May 94 11:05:32 PDT Received: by bacon.performance.com (4.1/SMI-4.1) id AA18879; Fri, 13 May 94 14:05:48 EDT Message-Id: <9405131805.AA18879@bacon.performance.com> To: ibis@vhdl.org Subject: Re: Egg 5.3 Date: Fri, 13 May 94 14:05:46 -0400 From: bracken@bacon.performance.com This seems like a good idea to me. The only problem is that BIRD 5.2 stated that power/ground bus names could be 20 characters long. Once you have 4 columns with bus names, your 80 characters per line are used up. But I think it would incovenience no one to reduce the bus name length to 10 characters or so. I would also suggest renaming the columns. Rather than use "gnd" and "pwr", why not just call them "pullup", "pulldown", "gnd_clamp" and "pwr_clamp" to make it extremely clear which parts of the model use which bus? This is just an idea--I'm not adamant about this. Bob (Ross), are you going to write up a new BIRD-let on this? --Eric From cpk@Cadence.COM Fri May 13 11:33:41 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20401; Fri, 13 May 94 11:33:41 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id LAA21871 for ; Fri, 13 May 1994 11:31:12 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma021758; Fri May 13 11:30:48 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA10025; Fri, 13 May 94 11:14:43 -0700 Received: by hot (5.65+/1.5) id AA08689; Fri, 13 May 94 14:30:24 -0400 Date: Fri, 13 May 94 14:30:24 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9405131830.AA08689@hot> To: ibis@vhdl.org Subject: Re: Egg 5.3 I have no objections to the egg. However , I strongly support renaming the the columns My favorite is pullup_reference pulldown_reference gndclamp_reference pwrclamp_reference - Kumar From bward@sugar.NeoSoft.COM Fri May 13 12:15:44 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20695; Fri, 13 May 94 12:15:44 PDT Received: by sugar.NeoSoft.COM id AA24066 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Fri, 13 May 1994 14:12:22 -0500 Message-Id: <199405131912.AA24066@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Bird 13.2 Date: Fri, 13 May 94 14:12:19 CDT All Ibis folk - This is a second try at publishing BIRD 13 to try to clarify some conditions of measurement. I have incorporated most comments that I received, I think. On behalf of the network administration folks here at TI, I apollogize for the previous attempt not getting out. Our e-mail facility has _again_ entered the definitely unreliable region. Thus I have moved most of my Ibis work to my alternate Internet connection at Neosoft. Replies to my neosoft address are less likely to get lost in the shuffle. Thanks for your patience. ++++++++++++++++++++++++++++++++ SNIP SNIP ++++++++++++++++++++++++++++++++++++ Buffer Issue Resolution Document (BIRD) BIRD ID#: 13.2 ISSUE TITLE: Clarify Some Conditions of Measurements REQUESTOR: Bob Ward Texas Instruments DATE SUBMITTED: 22 APR 94, 13 MAY 94 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Certain statements are made in the Version 1.1 standard that need clarification for the sake of newcomers to the Ibis community regarding the conditions under which measured data is taken. These changes bring the standard more into line with the discussions on the forum and the cookbook, which is taken to reflect the intention and not just the letter of the specification. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The majority of the change is to the NOTES TO DATA DERIVATION METHOD section of the spec. In paragraph numbered 1) Old text is: | V/I Curves for CMOS devices: | typ = nominal voltage, 50 degrees C, typical process | min = low voltage tol, 100 degrees C, typical process, minus "X%" | max = hi voltage tol, 0 degrees C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = nominal voltage, 50 degrees C, typical process | min = low voltage tol, 0 degrees C, typical process, minus "X%" | max = hi voltage tol, 100 degrees C, typical process, plus "X%" Proposed text is: | V/I Curves for CMOS devices: | typ = nominal voltage, nominal temperature deg C, typical process | min = low voltage tol, max temperature deg C, typical process, minus"X%" | max = hi voltage tol, min teperature deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = nominal voltage, nominal temperature deg C, typical process | min = low voltage tol, min temperature deg C, typical process, minus "X%" | max = hi voltage tol, max teperature deg C, typical process, plus "X%" | | where nominal, min, and max temperature are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min and 100C max temperatures. Add after the end of paragraph numbered 2) and before 3): These voltage ranges must be spanned by the ibis data. Data derived from lab measurements may not be able to span these ranges as such and so may need to be extrapolated to cover the fullrange. This must not be left for the simulator Add in paragraph numbered 3) after step 3 and before step 4 the following note: There may be devices which will not drive a load of only 50 ohms into any useful level of dynamics. In these cases use the manufacturers suggested ( non- reactive ) load and add the load sub parameter to the [Ramp] specification. Under the heading Ramp times for CMOS devices, make the same temerature specifications as above. Add a note after step 7. in the same section that during the IV measurements the driving waveform should be of a rise/fall time fast enough to avoid thermal feedback which is probably not realistic but slow enough that package parasitics do not distort the data. The specific choice of sweep time is left to the modelling engineer. Add specification of the sub parameter 'load' to the [Ramp] keyword. Under Keyword: [Ramp] change Sub-Params: dV/dt_r, dV/dt_f, load Add text to the Usage Rules: The load sub-parameter is optional if the preferred 50 ohm load is used. It is required if a non-standard load is used. Add to the example as follows: [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n load 300ohms Add to the discussion of voltage ranges [ item numbered 2) in the spec ] : The voltage range is determined by the typical conditions, so that if nominal Vcc is 5 volts, all voltage extremes run from -5 to +10 volts. There is no derating for the min and max conditions. So in this example, if min called for Vcc of 4.5 volts, the range is still -5 to +10, not -4.5 to +9. Similarly for the max range. Add after the [Volatge range] keyword discussion: |==============================================================================| | Keyword: [Temperature range] | | Required: Yes, if other than the preferred 0, 50, 100 degree C range | | Description: Used to define the temperature range over which the model is | | to operate. | | Usage Rules: Actual temperatures (not percentages) are to be presented in | | the usual typ, min, max format. "NA" is not allowed. | | Other Notes: [Temperature range] also describes the temperature range over | | which the various V/I curves and ramp rates were derived. Note| | that these are die temperatures, not ambient temperatures. | |------------------------------------------------------------------------------| | variable typ min max [Temperature range] 27.0C -50C 130.0C ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The spec should have flexibility enough to handle models of parts manufactured to MIL spec and automotive spec as well as parts for special purposes which are perhaps more sensitive than even consumer or commercial spec allows. Thus the relaxation , or tightening as the case may be, of the temperature and voltage range mandates. The added keyword and sub-parameter are to allow the simulator useable specification of the relaxed or tightened ranges for the relevant measurements. The ramp rate is still mandated to be determined between 20 and 80 % of actual swing to promote the linearity of the measured portion of the edge. The load is mandated to be non-reactive so as to preserve the inherent dynamics of the driver, and not introduce false dynamics due to the load. Backward compatibility is addressed by making the new specifications optional if the preferred votage and temperature ranges and load resistance are used. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: N/A ******************************************************************************* ++++++++++++++++++++++++++++++++++++ SNIP ++++++++++++++++++++++++++++++++++++++ ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com -or- (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ bward@neosoft.com 713+274-4146 Voice 713+274-3911 Fax ============================================================================= ___ (o o) -------------------------------ooO-(_)-Ooo----------------------------------- Here I sit in endless joy, 'cause I was here before Kilroy!!! From bracken@bacon.performance.com Fri May 13 14:40:30 1994 Return-Path: Received: from bacon.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22009; Fri, 13 May 94 14:40:30 PDT Received: by bacon.performance.com (4.1/SMI-4.1) id AA19472; Fri, 13 May 94 17:40:45 EDT Message-Id: <9405132140.AA19472@bacon.performance.com> To: ibis@vhdl.org Subject: More Press Date: Fri, 13 May 94 17:40:43 -0400 From: bracken@bacon.performance.com I forgot to mention this at the meeting--I have an article in the most recent Printed Circuit Design magazine (May 1994) which mentions IBIS. --Eric From bob@icx.com Fri May 13 15:34:41 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22391; Fri, 13 May 94 15:34:41 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22014 for ; Fri, 13 May 94 18:15:39 -0400 Date: Fri, 13 May 94 15:01:33 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10510; Fri, 13 May 94 15:01:33 PDT Message-Id: <9405132201.AA10510@icx.com> To: ibis@vhdl.org Subject: BIRD5.3 To Eric Bracken, C. Kumar and IBIS Committee Refer to the "ANY OTHER BACKGROUND INFORMATION" section for cover letter comments concerning this reopened bird designated BIRD5.3. Thank you Eric and Kumar for your comments. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 5.3 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REOPENED BY: Bob Ross, Interconnectix, Inc. DATE REOPENED: May 13, 1994 DATE REVISED: DATE REVISION ACCEPTED BY IBIS OPEN FORUM: BIRD ID#: 5.2 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: 6 December 1993 DATE REVISED: 17 December 1993 DATE ACCEPTED BY IBIS OPEN FORUM: Jan 7, 1994 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 15 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] pulldown_ref pullup_ref 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ...... ..... ..... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ...... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ...... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ...... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "pulldown_ref" column indicates the ground bus to which it is attached. The entry in the "pullup_ref" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "pulldown_ref" and "pullup_ref" columns +designate the ground and power buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pullup_ref" and "pulldown_ref" entries for it may be NC. Optional Extension: [Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP ...... ..... ..... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ...... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ...... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ...... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 ...... 51 GNDCLMP NC 52 NC PWRCLMP Explanation of Optional Extension: This extension illustrates a hypothetical situation where the clamping circuitry is connected to different rails than those of the pullup and pulldown tables. Pins 51 and 52 are hypothetical clamping supplies, and their attachments are shown at pins 3 and 4. While the nomenclature can lead to some potential confusion, the intended operation is according to this interpretation: The "pulldown_ref" column contains the power connection for the [Pulldown] table for non-ECL type [Models]. This is also the power connection for the [GND_clamp] table unless overriden by a specification in the gnd_clamp_ref column. The "pullup_ref" column contains the power connection for the [Pullup] table and for ECL type models, the [Pulldown] table. This is also the power connection for the [POWER_clamp] table unless overriden by a specification in the power_clamp_ref column. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation, while still observing an 80-character-per-line limit. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. Bird 5.2 has been issued in response to comments from the Forum members over the use of the term "NA" in Bird to indicate the lack of a connection. NA = "not available," which would have caused confusion. This version of the Bird has been updated to use "NC" (= "no connection") instead. Otherrwise, there are no changes from Bird 5.1. Reopened BIRD5.3 Background Information: BIRD5.2 is suitable as an extension to IBIS Version 1.1, but it needs some additional columns to be FULLY compatible with BIRD3 which supports up to 4 DIFFERENT Voltage References. Per the May 13, 1994 Forum and comments from Eric and Kumar, BIRD5.3 is issued. The extension consists of two additional, OPTIONAL columns for specifically designating [GND_clamp] and [POWER_clamp] connections. They will be rarely used. But in cases where the [PULLUP] is referenced to 3.3V, and the [POWER_clamp] to 5V, this extension would be useful. Also, there may need to be some clarification for ECL model types. Using BIRD5.2 as a basis and showing it completely for reference, the changes consist of "optional extension" and "explanation of optional extension" in the STATEMENT OF THE RESOLVED SPECIFICATIONS section. Two further changes are included: Per Eric's comment, I have reduced the column lengths. While 10 was suggested, I selected 15 as being a less drastic reduction while maintaining an 80 chararters per line. I do not see expansion in the number of rails, so I think this is reasonable. I agree with modifying the column names and have opted for a 3rd (compromise) choice from those selected by Kumar and Eric. The names suggested by Kumar caused the keyword line to exceed 80 characters, so I truncated the "_reference" to "_ref". I also changed "pwr" to "power" since "power" is is used throughout Version1.1 and in the proposed BIRDS. I used the underbar separation by Eric for "gnd_clamp_ref" and "power_clamp_ref". Note, while BIRD5.3 was originally intended for ground bounce simulation, it also provides the table to map external supplies connected to the pins to any [Model] within the [Component]. ****************************************************************************** From bob@icx.com Fri May 13 16:10:55 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22634; Fri, 13 May 94 16:10:55 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02344 for ; Fri, 13 May 94 19:00:25 -0400 Date: Fri, 13 May 94 15:47:56 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10641; Fri, 13 May 94 15:47:56 PDT Message-Id: <9405132247.AA10641@icx.com> To: ibis@vhdl.org Subject: More Press 2 April 1994 issue of Printed Circuit Design has an article by Greg Seltzer which mentions IBIS. Bob Ross, Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Sat May 14 01:44:43 1994 Return-Path: Received: from mail.barrnet.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26434; Sat, 14 May 94 01:44:43 PDT Received: from hermes.intel.com by mail.barrnet.net (5.67/1.37) id AA12180; Sat, 14 May 94 01:42:14 -0700 Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Sat, 14 May 94 01:40:49 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Sat, 14 May 94 01:39:18 -0700 Received: from ccMail by jfsmt2.intel.com id AA768904224 Sat, 14 May 94 01:30:24 PDT Date: Sat, 14 May 94 01:30:24 PDT From: "Hobbs, Will" Message-Id: <9404147689.AA768904224@jfsmt2.intel.com> To: ibis@vhdl.org, Stephen Peters Subject: Re: BIRD 12.1-- correction Please note, Stephen's revision should be numbered 12.2 Will Buffer Issue Resolution Document (BIRD) BIRD ID#: 12.2 ISSUE TITLE: Non-Linear Driver Waveforms REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: April 25, 1994, Revised April 29, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: May 13, 1994 ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The IBIS specification does not contain enough information to adequately describe the characteristics of a device whose output switching waveform is significantly non-linear. This BIRD proposes a method to describe these non-linear ramp waveforms. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are added to the specification, [Rising waveform] and [Falling waveform]. These keywords introduce a table of time vs. voltage points that describe the shape of a waveform. | | Keywords: [Rising waveform], [Falling waveform] | Required: No | Description: Used to describe the shape of the rising and falling edge | waveforms of a driver. | Sub-params: R_fixture, V_fixture, C_fixture, L_fixture, | R_dut, L_dut, C_dut | Usage Rules: Each [Rising waveform] and [Falling waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required, however, data | is only required in the typical column. If minimum | or maximum data is not available the reserved word "NA" | is used. The first value in the time column does not | have to be '0'. Time values must increase as | one parses down the table. The waveform table may | contain a maximum of 100 data points. There is a | maximum of 100 waveform tables allowed per model. | Note that for backwards compatibility the existing | [Ramp] keyword is still required. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. | | A [Model] specification can contain more than one | rising edge or falling edge waveform table; | however, each new table must begin with the appropriate | keyword and sub-parameter list as shown below. If more | than one rising or falling edge waveform table is | present, then the data in each of the respective tables | must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a | common reference point on the input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. | The R_dut, C_dut, and L_dut are analogous to the the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | | \/ | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | [Rising waveform] R_fixture = 500 V_fixture = 5.0 C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Currently, the IBIS specification assumes that all devices can be described accurately using a single risetime and falltime parameter. In other words, the switching waveform of the device is a relatively linear ramp. However, devices that shape the output waveform (risetime controlled devices) do not have a linear switching ramp. Trying to model devices of this type using a linear ramp model results in mis-predicting both the time to logic threshold and maximum edge rate. As IBIS is a specification that focuses on the behavior of a device rather than it structure or implementation, it would be ideal if there were a simple set of measurements one could take in order to describe the non-linearity. Obviously, the waveform shape itself is a good place to start. The fundamental assumption here is that the shape of the waveform, combined with the loading conditions, give simulator vendors enough additional information to construct accurate models of non-linear waveform drivers. Ideally, an IBIS model will include waveforms taken under several different loading conditions (R_fixture and V_fixture). By choosing the appropriate loading conditions a modeler can give the simulator vendors enough information to accurately simulate a device. The most straight forward way to describe a waveform shape is with a table of time vs. voltage points. (Note that one could take this table and enter it into a spreadsheet or graphing program and produce a picture of the waveform -- and that is one of the intents of the format.) One remaining issue is the ability to align the starting points of waveforms taken under different loading conditions (i.e. waveforms in two different tables). Jon Powell (Quad Design) has an action item to produce various waveforms and show this is possible. (PLEASE SEE THE NOTE BELOW ON VERSION 12.0 TO 12.1 CHANGES) In addition to providing more complete information to simulator vendors, explicitly describing the waveform allows one to validate a particular simulator's results. By performing a simulation into the specified load(s) and then comparing the results with the waveform(s) as listed in the IBIS file, one can perform anything from a quick sanity check of the data to a detailed analysis between simulators. A 'self-validating' model is a very powerful tool for checking and maintaining model quality. VERSION 12.0 TO 12.1 CHANGES: Based on e-mail suggestions and conversions in the April 29th IBIS open forum the following changes were made: 1. The sub-parameters now have an '=' between the sub-parameter name and value. 2. The maximum number of data points in a waveform table has been specified (100 max). 3. A statement was added that requires that all rising/falling edge data be time correlated. To make this perfectly clear: the data in one rising edge table must be time correlated to the data in any other RISING edge waveform table. Likewise for falling edge data. There is no requirement for time correlation between the data in rising and falling waveform tables. Note also the requirement that the correlation be to a reference point on the input stimulus waveform. This is to prevent a user from time correlating the waveforms to a point on an output waveform -- this defeats the purpose of time correlation. 4. The sub_parameters were expanded and changed from 'load' to 'dut' and 'fixture' to better indicate there proper use. A connection diagram was also added. 5. Cleaned up a few typos in the original version. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From Will_Hobbs@ccm2.jf.intel.com Sat May 14 01:46:43 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26478; Sat, 14 May 94 01:46:43 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Sat, 14 May 94 01:40:53 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Sat, 14 May 94 01:39:24 -0700 Received: from ccMail by jfsmt2.intel.com id AA768904245 Sat, 14 May 94 01:30:45 PDT Date: Sat, 14 May 94 01:30:45 PDT From: "Hobbs, Will" Message-Id: <9404147689.AA768904245@jfsmt2.intel.com> To: ibis@vhdl.org, Kellee Crisafulli <71436.1314@CompuServe.COM> Subject: Re: Bird 8.2 update from Kellee per meeting today Correction This should be Bird 8.2 Will ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 8.2 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: January 29, 1994 DATE REVISED: 5-9-94 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:'. Note: An '*' is used to denote the changed lines) |============================================================================== | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves -of | the pulldown and pullup structures of an output buffer -and the | V/I curves of the clamping diodes connected to the GND -and the | POWER pins, respectively. | Usage Rules: In each of these sections the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | All four columns are required under these keywords, however | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | * The V/I table DATA SHOULD BE MONOTONIC to insure that most * simulators provide stable simulations. Monotonic data is * needed to insure that all data is single valued. MONOTONIC * DATA IS NOT REQUIRED to provide a valid IBIS model. * It is recognized that automated measurement equipment may * be used to acquire this data and as such may include "noise" * which causes the data to be non-monotonic. It is also recognized * that some device may be non-monotonic in certain regions. * Therefore the IBIS specification allows non-monotonic data. * Simulation tools should filter out non-monotonic data if * such data causes instabilities in the simulation results. * To be monotonic the V/I table data must meet any one of the * following 8 criteria: * 1- The CURRENT axis either increases or remains constant as * the voltage axis is increased. * 2- The CURRENT axis either increases or remains constant as * the voltage axis is decreased. * 3- The CURRENT axis either decreases or remains constant as * the voltage axis is increased. * 4- The CURRENT axis either decreases or remains constant as * the voltage axis is decreased. * * 5- The VOLTAGE axis either increases or remains constant as * the current axis is increased. * 6- The VOLTAGE axis either increases or remains constant as * the current axis is decreased. * 7- The VOLTAGE axis either decreases or remains constant as * the current axis is increased. * 8- The VOLTAGE axis either decreases or remains constant as * the current axis is decreased. * * The IBIS_CHK program will test for non-monotonic data and * provide a maximum of one note per V/I table if non-montonic * data is found. * "NOTE: Line xxx of V/I table yyy for model zzz is * non-monotonic! Most simulators will filter this data * to remove the non-monotonic data." * Where xxx is the line number in the IBIS file. * Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. * Where zzz is the name of the model. * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the version 2.0 IBIS_CHK program, it will consider only one * V/I table at a time monotonicity testing. * | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | [POWER_clamp] structures are 'Vcc relative', meaning that the | voltage values are referenced to the Vcc pin. The voltages in | the data tables are derived from the equation: | Vtable = Vcc - Voutput | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND_clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output if so | desired. |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions the results of the 1993 summit. Considerable email has passed on this discussion. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The IBIS_CHK program must also be modified to test for this condition. ------------------------------------------------------------------------------ From meeting Nov 5, 1993 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ------------------------------------------------------------------------------ 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------- ******************************************************************************** From bward@sugar.NeoSoft.COM Sun May 15 04:50:13 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10066; Sun, 15 May 94 04:50:13 PDT Received: by sugar.NeoSoft.COM id AA08283 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Sun, 15 May 1994 06:47:00 -0500 Message-Id: <199405151147.AA08283@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: New bird13 Date: Sun, 15 May 94 6:46:57 CDT All Ibis folk - This is a second try at publishing BIRD 13 to try to clarify some conditions of measurement. I have incorporated most comments that I received, I think. On behalf of the network administration folks here at TI, I apollogize for the previous attempt not getting out. Our e-mail facility has _again_ entered the definitely unreliable region. Thus I have moved most of my Ibis work to my alternate Internet connection at Neosoft. Replies to my neosoft address are less likely to get lost in the shuffle. Thanks for your patience. ++++++++++++++++++++++++++++++++ SNIP SNIP ++++++++++++++++++++++++++++++++++++ Buffer Issue Resolution Document (BIRD) BIRD ID#: 13.2 ISSUE TITLE: Clarify Some Conditions of Measurements REQUESTOR: Bob Ward Texas Instruments DATE SUBMITTED: 22 APR 94, 13 MAY 94 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Certain statements are made in the Version 1.1 standard that need clarification for the sake of newcomers to the Ibis community regarding the conditions under which measured data is taken. These changes bring the standard more into line with the discussions on the forum and the cookbook, which is taken to reflect the intention and not just the letter of the specification. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The majority of the change is to the NOTES TO DATA DERIVATION METHOD section of the spec. In paragraph numbered 1) Old text is: | V/I Curves for CMOS devices: | typ = nominal voltage, 50 degrees C, typical process | min = low voltage tol, 100 degrees C, typical process, minus "X%" | max = hi voltage tol, 0 degrees C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = nominal voltage, 50 degrees C, typical process | min = low voltage tol, 0 degrees C, typical process, minus "X%" | max = hi voltage tol, 100 degrees C, typical process, plus "X%" Proposed text is: | V/I Curves for CMOS devices: | typ = nominal voltage, nominal temperature deg C, typical process | min = low voltage tol, max temperature deg C, typical process, minus"X%" | max = hi voltage tol, min teperature deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = nominal voltage, nominal temperature deg C, typical process | min = low voltage tol, min temperature deg C, typical process, minus "X%" | max = hi voltage tol, max teperature deg C, typical process, plus "X%" | | where nominal, min, and max temperature are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min and 100C max temperatures. Add after the end of paragraph numbered 2) and before 3): These voltage ranges must be spanned by the ibis data. Data derived from lab measurements may not be able to span these ranges as such and so may need to be extrapolated to cover the fullrange. This must not be left for the simulator Add in paragraph numbered 3) after step 3 and before step 4 the following note: There may be devices which will not drive a load of only 50 ohms into any useful level of dynamics. In these cases use the manufacturers suggested ( non- reactive ) load and add the load sub parameter to the [Ramp] specification. Under the heading Ramp times for CMOS devices, make the same temerature specifications as above. Add a note after step 7. in the same section that during the IV measurements the driving waveform should be of a rise/fall time fast enough to avoid thermal feedback which is probably not realistic but slow enough that package parasitics do not distort the data. The specific choice of sweep time is left to the modelling engineer. Add specification of the sub parameter 'load' to the [Ramp] keyword. Under Keyword: [Ramp] change Sub-Params: dV/dt_r, dV/dt_f, load Add text to the Usage Rules: The load sub-parameter is optional if the preferred 50 ohm load is used. It is required if a non-standard load is used. Add to the example as follows: [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n load 300ohms Add to the discussion of voltage ranges [ item numbered 2) in the spec ] : The voltage range is determined by the typical conditions, so that if nominal Vcc is 5 volts, all voltage extremes run from -5 to +10 volts. There is no derating for the min and max conditions. So in this example, if min called for Vcc of 4.5 volts, the range is still -5 to +10, not -4.5 to +9. Similarly for the max range. Add after the [Volatge range] keyword discussion: |==============================================================================| | Keyword: [Temperature range] | | Required: Yes, if other than the preferred 0, 50, 100 degree C range | | Description: Used to define the temperature range over which the model is | | to operate. | | Usage Rules: Actual temperatures (not percentages) are to be presented in | | the usual typ, min, max format. "NA" is not allowed. | | Other Notes: [Temperature range] also describes the temperature range over | | which the various V/I curves and ramp rates were derived. Note| | that these are die temperatures, not ambient temperatures. | |------------------------------------------------------------------------------| | variable typ min max [Temperature range] 27.0C -50C 130.0C ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The spec should have flexibility enough to handle models of parts manufactured to MIL spec and automotive spec as well as parts for special purposes which are perhaps more sensitive than even consumer or commercial spec allows. Thus the relaxation , or tightening as the case may be, of the temperature and voltage range mandates. The added keyword and sub-parameter are to allow the simulator useable specification of the relaxed or tightened ranges for the relevant measurements. The ramp rate is still mandated to be determined between 20 and 80 % of actual swing to promote the linearity of the measured portion of the edge. The load is mandated to be non-reactive so as to preserve the inherent dynamics of the driver, and not introduce false dynamics due to the load. Backward compatibility is addressed by making the new specifications optional if the preferred votage and temperature ranges and load resistance are used. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: N/A ******************************************************************************* ++++++++++++++++++++++++++++++++++++ SNIP ++++++++++++++++++++++++++++++++++++++ ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com -or- (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ bward@neosoft.com 713+274-4146 Voice 713+274-3911 Fax ============================================================================= ___ (o o) -------------------------------ooO-(_)-Ooo----------------------------------- Here I sit in endless joy, 'cause I was here before Kilroy!!! From bob@icx.com Sun May 15 16:05:21 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13790; Sun, 15 May 94 16:05:21 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02924 for ; Sun, 15 May 94 18:49:38 -0400 Date: Sun, 15 May 94 15:37:36 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA15907; Sun, 15 May 94 15:37:36 PDT Message-Id: <9405152237.AA15907@icx.com> To: ibis@vhdl.org Subject: BIRD5.4 To IBIS Committee BIRD5.4 is issued to further clarify how [Pin_mapping] would be formatted and to address some additional details that were needed when attempting to do the formatting. The proposed format appears first. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 5.4 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REOPENED BY: Bob Ross, Interconnectix, Inc. DATE REOPENED: May 13, 1994 DATE REVISED: May 15, 1994 DATE REVISION ACCEPTED BY IBIS OPEN FORUM: BIRD ID#: 5.2 ISSUE TITLE: Pin Mapping for Ground Bounce Simulation REQUESTOR: J. Eric Bracken, Performance Signal Integrity, Inc. and C. Kumar, Cadence Design Systems, Inc. DATE SUBMITTED: 6 December 1993 DATE REVISED: 17 December 1993 DATE ACCEPTED BY IBIS OPEN FORUM: Jan 7, 1994 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Pin_Mapping] keyword is added: |=========================================================================== | Keyword: [Pin_Mapping] | Required: Optional | Description: Used to indicate which power and ground buses a given driver, | receiver, or terminator is connected. | Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref | Usage Rules: Each power and ground bus is given a unique name which must | not exceed 15 characters. The first column contains a pin | number. Each pin number must match one of the pin numbers | declared previously in the [Pin] section of the IBIS file. | The second column, "pulldown_ref", designates the ground bus | connections for that pin. Here the term "ground bus" can | also mean another "power bus". The third column "pullup_ref" | designates the power bus connection. The forth and fifth | columns "gnd_clamp_ref" and "power_clamp_ref" contain | entries, if needed, to specify different ground bus | and power bus connections than those previously specified. | | If the [Pin_Mapping] keyword is present, then the bus | connections for EVERY pin listed in the [Pin] section must | be given. | | Each line must contain either three or five columns. "NC" | is used for entries which are not needed or which follow | the conditions below: | | If a pin has no connection, then both the "pulldown_ref" | and "pullup_ref" entries for it will be NC. | | GND and POWER pin entries and buses are designated by | entries in either the "pulldown_ref" or "pullup_ref" columns. | There is no implied association to any column other than | through explicit designations in other pins. | | For any other type of pin, the "pulldown_ref" column contains | the power connection for the [Pulldown] table for non-ECL type | [Models]. This is also the power connection for the [GND_clamp] | table and the [Rgnd] model unless overriden by a specification | in the "gnd_clamp_ref" column. | | Also, the "pullup_ref" column contains the power connection | for the [Pullup] table and, for ECL type models, the [Pulldown] | table. This is also the power connection for the [POWER_clamp] | table and the [Rpower] model unless overriden by a specification | in the "power_clamp_ref" column. | | Column length limits are: | [Pin_Mapping] 5 characters max | pulldown_ref 15 characters max | pullup_ref 15 characters max | gnd_clamp_ref 15 characters max | power_clamp_ref 15 characters max | |---------------------------------------------------------------------------- [Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref | 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections | 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP 5 GNDBUS2 PWRBUS2 NC PWRCLAMP 6 GNDBUS2 PWRBUS2 GNDCLMP NC | Some possible clamping connections | ..... | are shown above for illustration | ..... | purposes | ..... 11 GNDBUS1 NC | One set of ground connnections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. | ..... 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC | ..... 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. | ..... 41 NC PWRBUS2 | Second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 | ..... 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps |========================================================================== General Explaination: Each power and ground bus is given a unique name which must not exceed 15 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] pulldown_ref pullup_ref 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ....... ...... ...... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ....... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ....... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ....... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "pulldown_ref", designates the ground bus connection for that pin; similarly, the third column, "pullup_ref", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "pulldown_ref" column indicates the ground bus to which it is attached. The entry in the "pullup_ref" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "pulldown_ref" and "pullup_ref" columns +designate the ground and power buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pullup_ref" and "pulldown_ref" entries for it may be NC. Optional Extension: [Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP ....... ...... ...... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ....... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ....... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ....... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 ....... 51 GNDCLMP NC 52 NC PWRCLMP Explanation of Optional Extension: This extension illustrates a hypothetical situation where the clamping circuitry is connected to different rails than those of the pullup and pulldown tables. Pins 51 and 52 are hypothetical clamping supplies, and their attachments are shown at pins 3 and 4. While the nomenclature can lead to some potential confusion, the intended operation is according to this interpretation: The "pulldown_ref" column contains the power connection for the [Pulldown] table for non-ECL type [Models]. This is also the power connection for the [GND_clamp] table unless overriden by a specification in the gnd_clamp_ref column. The "pullup_ref" column contains the power connection for the [Pullup] table and for ECL type models, the [Pulldown] table. This is also the power connection for the [POWER_clamp] table unless overriden by a specification in the power_clamp_ref column. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: One of the more serious causes of noise in digital circuits is the voltage spike created on a device's power or ground line due to the sudden switching of a very large current into that line. This can occur when other drivers share a power or ground bus with the device in question. Most modern packages incorporate many different power and ground pins and then internally connect them to several different power and ground buses. The drivers and receivers are carefully assigned to certain buses to minimize the potential impact of switching noise on the part's operation. Without a knowledge of this device-to-bus assignment, it becomes impossible to perform even a first-order simulation of the ground bounce effect. One cannot know which pins will influence any given driver or receiver. The proposed BIRD attempts to rectify this situation, while still observing an 80-character-per-line limit. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Please note that, in order to make the simulation possible, the modelling engineer must specify the (self-)resistance and inductance for each power and ground pin in the model. The present BIRD does not address any inductive or resistive drops along the internal bus--these are assumed to be zero (the bus is treated as a perfect short between pins). Under this assumption, the equivalent impedance seen by the drivers on the bus can be found by taking the parallel combination of the series R-L impedances for each of the GND or POWER pins connected to the bus. Bird 5.2 has been issued in response to comments from the Forum members over the use of the term "NA" in Bird to indicate the lack of a connection. NA = "not available," which would have caused confusion. This version of the Bird has been updated to use "NC" (= "no connection") instead. Otherrwise, there are no changes from Bird 5.1. Reopened BIRD5.3 Background Information: BIRD5.2 is suitable as an extension to IBIS Version 1.1, but it needs some additional columns to be FULLY compatible with BIRD3 which supports up to 4 DIFFERENT Voltage References. Per the May 13, 1994 Forum and comments from Eric and Kumar, BIRD5.3 is issued. The extension consists of two additional, OPTIONAL columns for specifically designating [GND_clamp] and [POWER_clamp] connections. They will be rarely used. But in cases where the [PULLUP] is referenced to 3.3V, and the [POWER_clamp] to 5V, this extension would be useful. Also, there may need to be some clarification for ECL model types. Using BIRD5.2 as a basis and showing it completely for reference, the changes consist of "optional extension" and "explanation of optional extension" in the STATEMENT OF THE RESOLVED SPECIFICATIONS section. Two further changes are included: Per Eric's comment, I have reduced the column lengths. While 10 was suggested, I selected 15 as being a less drastic reduction while maintaining an 80 chararters per line. I do not see expansion in the number of rails, so I think this is reasonable. I agree with modifying the column names and have opted for a 3rd (compromise) choice from those selected by Kumar and Eric. The names suggested by Kumar caused the keyword line to exceed 80 characters, so I truncated the "_reference" to "_ref". I also changed "pwr" to "power" since "power" is is used throughout Version1.1 and in the proposed BIRDS. I used the underbar separation by Eric for "gnd_clamp_ref" and "power_clamp_ref". Note, while BIRD5.3 was originally intended for ground bounce simulation, it also provides the table to map external supplies connected to the pins to any [Model] within the [Component]. BIRD 5.4 was needed for specification formatting information and resolution of further details. ****************************************************************************** From fkai@simulate.us.dell.com Mon May 16 08:38:21 1994 Return-Path: Received: from dell2.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21991; Mon, 16 May 94 08:38:21 PDT Received: from dell1.us.dell.com (dell1.us.dell.com [143.166.224.203]) by dell2.us.dell.com (8.6.8.1/8.6.8-DELL-INTERNET-GATEWAY) with SMTP id KAA05816 for ; Sun, 15 May 1994 10:33:36 -0500 Received: from simulate.us.dell.com.us.dell.com by dell1.us.dell.com (4.1/SMI-4.1) id AA03697; Mon, 16 May 94 10:35:32 CDT Received: by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) id AA01592; Mon, 16 May 94 10:36:07 CDT Date: Mon, 16 May 94 10:36:07 CDT From: fkai@simulate.us.dell.com (Francis Kai) Message-Id: <9405161536.AA01592@simulate.us.dell.com.us.dell.com> To: ibis@vhdl.org Subject: Timing information in IBIS Dear IBIS folks: My manager, Ron Sisk, and I both support C. Kumar's suggestions that it will be better for IBIS to include the timing information. We will let you guys decide what kind of format is the best for IBIS. Francis Kai Dell Computer Corporation Mr. C. Kumar's suggestion is listed below: > Hello Fellow IBISans -- > > I've been following the comments going back and forth on Bird 14, > and somthing Bob Ross said in this last reply struck me as fundemental > to how we wish to 'grow' this specification. Bob's comment was: > > "....So if Cref is really useful then I would not object to having it in. At > this time, however, I do not see Cref or any other proposed parameter as > being required. Any parameter that is not required cannot be relied upon to > exist by simulator vendors. So at worst the additional parameters may be > for information only....." > > > As I see it, bird 14 takes IBIS beyond simply providing basic > information for signal integry analysis into providing 'data book' > information; enough for full board timing simulation. If this type > ^^^^^^ > of information is not *required* or directly used by the simulator to > produce waveforms, then we have two distinct types of models -- one for > signal integrey analysis and a more complex one that helps in full board > timing simulations. Perhaps this is a good place to make the break between > Level 1 models and Level 2 models. Comments, anyone? > This goes back to my suggestion few weeks ago. I suggested that it is natural to have timing information under IBIS. Timing information can follow a a format similar to the one proposed for package models. - Kumar From bob@icx.com Mon May 16 09:01:34 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22490; Mon, 16 May 94 09:01:34 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA29607 for ; Mon, 16 May 94 11:49:34 -0400 Date: Mon, 16 May 94 08:45:49 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA17410; Mon, 16 May 94 08:45:49 PDT Message-Id: <9405161545.AA17410@icx.com> To: ibis@vhdl.org Subject: BIRD14 Comment To IBIS Committee: After hearing the discussion last Friday and talking to several people including John Keifer at Intel, I now have changed my views and fully support including Cref as part of IBIS Version 2.0. Furthermore, I support the view of Greg Doyle that Rref and Vref must also be included. This combination seems to cover most of the test setups typical of timing specifications. This specification appropriately puts IBIS right at the signal-integrity/ timing analysis interface. For signal integrity analysis, you set rules or test times of actual signals that have been based on internal device propagation specifications and which are based on specified test load conditions. Completion of the signal integrity timing analysis requires that the loading effects of the actual load be compared with the loading effects of the test load in order that the overall input to input timing requirements are met. So providing the test conditions within the IBIS [Model] is very useful, particularly in relationship to some other features giving different ways of specifying the time response itself. So I strongly support the inclusion of these parameters and could also support making them required for Version 2.0. The only issue in my mind is logistics regarding possible default values and possible assumptions for backward compatibility with Version 1.1 models. Bob Ross Interconnectix, Inc. From bob@icx.com Mon May 16 10:11:58 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22942; Mon, 16 May 94 10:11:58 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA06555 for ; Mon, 16 May 94 13:01:19 -0400 Date: Mon, 16 May 94 09:53:29 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA17672; Mon, 16 May 94 09:53:29 PDT Message-Id: <9405161653.AA17672@icx.com> To: ibis@vhdl.org Subject: BIRD13.2 Comment Bob Ward and IBIS Committee Regarding the syntax of the "load" option associated with [Ramp], I would proposed the following syntax which is consistent with all of the other single value numerical assignments in IBIS and the BIRDS: Change load 300ohms To R_load = 300ohms Bob Ross Interconnectix, Inc. From bward@sugar.NeoSoft.COM Mon May 16 11:47:08 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23746; Mon, 16 May 94 11:47:08 PDT Received: by sugar.NeoSoft.COM id AA00506 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Mon, 16 May 1994 13:44:24 -0500 Message-Id: <199405161844.AA00506@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: Bob Ross comment on bird 13.2 Date: Mon, 16 May 94 13:44:23 CDT Ooops! Bob is right, the '=' separator makes it more consistent and therefore easier to parse and handle in general. I shall make the change, and accumulate others as they arrive and try to put out a version somewhat ahead of the editing meeting on the 20th. Thanks for catching this! Just proves again that one cannot proofread his own stuff. All the best ... Bob bward@neosoft.com or bward@dadhb1.ti.com From Derrick_Duehren@ccm2.jf.intel.com Mon May 16 20:02:55 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26742; Mon, 16 May 94 20:02:55 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q3FO0-000MNYC; Mon, 16 May 94 20:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 16 May 94 20:00:03 PST Date: Mon, 16 May 94 20:00:03 PST From: Derrick Duehren Message-Id: <940516200003_1@ccm.hf.intel.com> To: Jerry_Budelman@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS 5/13/94 Meeting Minutes Text item: Text_1 Date: May 16, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum 5/13/94 To: Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Kumar* Contec Maah Sango, Clark Cochran Digital Equipment Corp. Barry Katz High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli* IBM Jay Diepenbrock IBM-Motorola alliance Lynn Warriner, Hoa Quoc, John Burnett Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, D. Duehren*, John Keifer* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Mei Wong, Mei-Ling Wei NEC Matsamoto Hiroshi* MicroSim Arthur Wong, Jerry Brown, Graham Bell National Semiconductor Syed Huq North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell Quantic Labs Mike Ventham*, Zhen Mu Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl* CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by * Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 5/20/94 (916) 356-9999 315842 (1:00 pm PST) 5/27/94 (415) 904-8800 744468 All meetings are 8:00 AM to 10:00 AM PST (15:00 to 17:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org) send e-mail to ibis-request@vhdl.org. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ 5/13/94 Meeting Agenda ---------------------- Check-in Intros of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues All New models available All IBIS 2.0 Ratification/DAC/Other 2.0 Issues Hobbs - May 20 Editing meeting - Rev 2.0 Ratification Summit (6/9) IBIS Cookbook Hobbs, Rosenbaum BIRD 8, Spec. of V/I data monotonicity Crisafulli BIRD 12, Non-Linear Driver Waveforms Peters BIRD 13, Clarify Some Conditions of Measurements Ward BIRD 14, New section for [Model] sub-parameters Keifer Egg 5.3 Ross Wrap-up, Next Meeting Plans Hobbs 1. Intros of new IBIS participants New participant: Matsamoto Hiroshi, NEC (Japan). Bob W. got a message from a TI person from England. They are interested in IBIS for use in the Telecomm industry and keen on differential inputs. 2. Review of Pervious Meeting's Minutes There were no corrections made to last month's minutes. 3. Miscellany/Announcements After the meeting Eric B. and Bob R. mentioned the following IBIS-in- the-news item: An article in the April/May 1994 Printed Circuit Design magazine mentions IBIS. 4. Opens for new issues Arpad questioned why Zeelan would encrypt IBIS models. Some companies, such as Intel, provide IBIS models free of charge, while others are charging for them. It is a business issue. Kellee pointed out that encryption should be standardized so all simulators can use it without going through extra steps to decrypt for different simulators. AR Kellee: Call George Opshal (Zeelan) and discuss your concerns. Bob Ross added Egg 5.3 to the agenda. 5. New models available Will is receiving requests for IBIS models and is telling them to contact their simulator vendor. 6. IBIS 2.0 Ratification/DAC - May 20 Editing Committee Will has contacted Paul Munsey, who is interested in working on the 2.0 GP. AR Will: Get cost estimates from Paul before DAC. We will have a teleconference meeting 1:00 pm PST, 5/20/94 to get additional feedback and approval on yet pending BIRDs. - Rev 2.0 Ratification Summit (6/9/94) Bob Ward got IBIS posters back from the artist, they look good. AR Will: Have list of IBIS Overview requesters at DAC. - Birds of the Feather (6/8/94) Everyone interested in attending BOF has to sign up in person at DAC, including those who RSVPed. 7. IBIS Cookbook Robin Rosenbaum not present to comment. Kellee submitted a generic example for the cookbook. Thanks Kellee. 8. BIRD 8, Spec. of V/I data monotonicity Kellee read the summary of changes from the last version (see BIRD 8.1). Monotonicity is required on one axis. If another axis is non-monotonic, the Golden Parser will issue a note. Non-monotonic data is not illegal, just suspicious. Added requirement for the line number of the first occurrence in each affected table. Change header from "Warning" to "Note". Vote taken: Approved unanimously with two changes (to 8.2). 9. BIRD 12, Non-linear Driver Waveforms Stephen added the changes from last meeting's discussion. We discussed whether we should specify a maximum number of ramp tables. Bob Ross felt we shouldn't place any limitations or suggestions on the number of tables. Kellee would like at least some arbitrary upper limit, even if it is very big, such as 50. Arpad pointed out that the VI points are limited to 100, so limiting to 100 ramp tables is reasonable. Consensus reached on a maximum of 100 ramp tables. Vote taken: Approved unanimously with change (to 12.2). 10. BIRD 13, Clarify Some Conditions of Measurements Bob W. put out a new version last night that no one received. The IBIS spec. does not specify the voltage sweep range. Re: min, typ, max, does the sweep voltage scale with Vcc or do we specify the sweep range based on the typical range? Consensus is to use the typical range. Recommendation to be added to the BIRD and elaborated in the cookbook. Consensus that Vcc at typical is best. This needs to be reflected in the cookbook, as well as BIRD 13. Not ready to approve. Several changes were suggested. Will try for approval at the May 20 meeting teleconference. AR Bob W.: Make the changes as discussed and repost. AR Stephen: Let Robin R. know this change for the cookbook. 11. BIRD 14, New Section for [Model] Sub-parameters John Keifer described the BIRD. Discussed the understanding of the BIRD. There is much confusion. Discussion revolves around flight time measurements, test conditions during testing done on silicon, not internal propagation delay. Discussion will continue on the reflector and potentially voted on next week. 12. BIRD 15, V/I Table Usage Clarifications Arpad introduced it, Bob R. suggested one minor change in clamping wording. We will vote on it 5/20/94. AR Arpad: Close this issue with Jon Powell ASAP (Jon was not present) and reissue as 15.1 with Bob's comments. 13. Egg 5.3 Bob R. briefly discussed it. 14. Wrap-up, Next Meeting Plans Next meeting is 5/20/94, 1:00 pm PST. From rajiv@parcom.ernet.in Tue May 17 07:14:47 1994 Return-Path: Received: from sangam.ncst.ernet.in by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03481; Tue, 17 May 94 07:14:47 PDT Received: from parcom.UUCP (uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id TAA04300 for ibis@vhdl.org; Tue, 17 May 1994 19:14:16 +0530 Received: from parcom.UUCP by iucaa (4.1/SMI-4.1) id AA07955; Tue, 17 May 94 18:41:43+050 Received: by parcom (4.1/SMI-4.1) id AA05106; Tue May 17 17:34:58 1994 (GMT + 0530) Date: Tue May 17 17:34:58 1994 (GMT + 0530) From: rajiv@parcom.ernet.in (Rajiv Deshpande) Message-Id: <9405171204.AA05106@parcom> Organisation: To: ibis@vhdl.org Please Subscribe me to your Users Group I am interested in having more information on this topic. Rajiv Center for Development of Advance Computing Pune India e-mail rajiv@parcom.ernet.in From cpk@Cadence.COM Tue May 17 09:02:54 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04207; Tue, 17 May 94 09:02:54 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id JAA26699 for ; Tue, 17 May 1994 09:00:09 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma026618; Tue May 17 08:59:27 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA19504; Tue, 17 May 94 08:42:51 -0700 Received: by hot (5.65+/1.5) id AA09990; Tue, 17 May 94 11:59:05 -0400 Date: Tue, 17 May 94 11:59:05 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9405171559.AA09990@hot> To: ibis@vhdl.org Subject: ibis mention Ibis is mentioned prominently in "Signal Integrity Analysis in ASIC Design" By Tai-Yu Chou in May 94 issue of System Design - Kumar From bob@icx.com Tue May 17 09:22:20 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04325; Tue, 17 May 94 09:22:20 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA25107 for ; Tue, 17 May 94 11:49:45 -0400 Date: Tue, 17 May 94 08:22:38 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA20923; Tue, 17 May 94 08:22:38 PDT Message-Id: <9405171522.AA20923@icx.com> To: ibis@vhdl.org Subject: IBIS BIRDS ROLLUP To IBIS Editing Committee Members: This is a complete rollup of all of the approved and pending BIRDS into one document prior to editing committee work with the exception of BIRD10.1 which is complete in itself. This document has been produced mostly through "cut and paste", with some minor corrections, but without concern about formatting and consistency details. The intent is to capture the approved changes and show WHERE they apply. This should serve as a reminder to all of us of what has been done so far, and should be useful to the newer members when they hear references to work already done. Bob Ross, Interconnectix, Inc. |****************************************************************************** |* ENHANCED VERSION OF IBIS VERSION 1.1 DESIGNATED "VERSION 1.1Z" SHOWING |* APPROVED "BIRDS" (BIRD = BUFFER ISSUE RESOLUTION DOCUMENT). |* |* CHANGES FOR ADDITIONS AND REPLACEMENT DESIGNATED BY "|*" SECTIONS PLUS |* NOTES ON BIRDS AT END. |* |* BIRDS INCLUDED IN VERSION 1.1X ARE BIRD3, BIRD4, BIRD5.2, BIRD6.2, BIRD7.2. |* FEBRUARY 20, 1994. |* |* BIRDS INCLUDED IN VERSION 1.1Y ARE BIRD2.2, BIRD9.3, BIRD11.2 AND REFERENCE |* TO BIRD10.1, MAY 6, 1994 |* |* BIRDS INCLUDED IN VERSION 1.1Z ARE BIRD8.2 AND BIRD12.2, MAY 13, 1994 |* |# ALSO INCLUDED ARE THE LATEST VERSIONS OF PENDING BIRDS DESIGNATED BY "|#" |# SO THAT THIS DOCUMENT CAN BE USED DURING THE EDITING COMMITTEE MEETING |# AND DURING THE IBIS FORUM DISCUSSION. PENDING BIRDS INCLUDE BIRD13.2, |# BIRD14, BIRD15, AND BIRD5.4. THE VERSION FOR PEMDING BIRDS IS DENOTED |# VERSION 2.0 - MAY 15, 1994. THIS WILL BE UPDATED DAILY UNTIL THE EDITING |# COMMITTEE MEETS. |****************************************************************************** |==============================================================================| | | | Statement of Intent: | | | | In order to enable an industry standard method to electronically transport | | IBIS Modeling Data between silicon vendors, simulation software vendors, and | | end customers, this template is proposed. The intention of this template is | | to specify a consistent format that can be parsed by software, allowing each | | simulation vendor to derive models compatible with their own product. | | | | One goal of this template is to represent the current state of IBIS data, | | while allowing a growth path to more complex models / methods (when deemed | | appropriate). This would be accomplished by a revision of the base | | template, and possibly the addition of new keywords or categories. | | | | Another goal of this template is to ensure that it is simple enough for | | silicon vendors and customers to use and modify, while ensuring that it is | | rigid enough for software simulation vendors to write reliable parsers. | | | | Finally, this template is meant to contain a complete description of the I/O | | elements on an entire component. Consequently, several models will need to | | be defined in each file, as well as a table that equates the appropriate | | buffer to the correct pin and signal name. | | | | Version 1.1 of this electronic template was finalized by an industry-wide | | group of simulation experts representing various companies and interests. | | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | | ASCII file format. It represents the minimum amount of I/O buffer | | information required to create an accurate IBIS model of common CMOS and | | bipolar I/O structures. Future revisions of the ASCII file will add items | | considered to be "enhancements" to Version 1.0 to allow accurate modeling | | of new, or other, I/O buffer structures. Consequently, all future | | revisions will be considered super sets of Version 1.0, allowing backward | | compatibility. In addition, as modeling platforms develop support for | | revisions of the IBIS ASCII template, all previous revisions of the | | template must also be supported. | | | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | | comments have been added for further clarification. | | | |==============================================================================| | | | General syntax rules and guidelines: | | | | 1) The content of the IBIS_ASCII file is case sensitive, except for file | | names, reserved words and keywords. Reserved words and keywords are not | | case sensitive, and file names must be all lower case. | | | | 2) The following words are reserved words and must not be used for | | any other purposes in the document: | | POWER - reserved model name, used with power supply pins, | | GND - reserved model name, used with ground pins, | | NC - reserved model name, used with no connect pins, | | NA - used where data not available. | | | | 3) File names used in the IBIS_ASCII file must only have lower case | | characters to enhance UNIX compatibility and must conform to DOS rules. | | (The length of a file name should not exceed eight plus three characters | | and it must not contain special characters which are illegal in DOS). | | | | 4) The IBIS_ASCII file must have no more than 80 characters per line. | | | | 5) Anything following the comment character is ignored and considered a | | comment on that line. The default "|" (pipe) character can be changed by | | the keyword [Comment char] to any other character. The [Comment char] | | keyword can be used throughout the file as desired. | | | | 6) Keywords must be enclosed in square brackets, [], and must start in | | column 1 of the line. | | | | 7) Valid scaling factors are: | | M = mega, k = kilo, m = milli, u = micro, n = nano, p = pico. | | When no scaling factors are specified, the appropriate base units are | | assumed. (These are Volts, Amperes, Ohms, Farads and Henries). The parser | | will look at only one alphabetic character after a numerical entry, | | therefore it is enough to use only the prefixes to scale the parameters. | | However, for clarity, it is allowed to use full abbreviations for the | | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | | allowed (e.g., 1.2345e-12). | | | | 8) The V/I data tables should use enough data points around sharply curved | | areas of the V/I curves to describe the curvature accurately. In linear | | regions there is no need to define unnecessary data points. | | | | 9) Currents are considered positive when their direction is into the | | component. | | | |==============================================================================| | Keyword: [IBIS Ver] | | Required: Yes | | Description: Used to specify the IBIS ASCII template version. This will be | | used to inform an electronic parser of the kinds of data types | | that will be present in the file. | | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | | normally on the first line of the file, but can be preceded | | by comment lines (that must begin with a "|"). | |------------------------------------------------------------------------------| [IBIS Ver] 1.1 | Used for template variations |==============================================================================| | Keyword: [Comment char] | | Required: Optional | | Description: Used to define a new comment character to replace the default | | "|" (pipe), if desired. | | Usage Rules: The new comment character which is to be defined must be | | followed by the underscore character and the letters "char". | | For example: "|_char" redundantly redefines the comment | | character to be the pipe character. The new comment character | | will be in effect only following the [Comment char] keyword. | | The following characters can NOT be used: A B C D E F G H I J | | K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o | | p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = | | Other Notes: The [Comment char] keyword can be used throughout the file, as | | desired. | |------------------------------------------------------------------------------| [Comment char] |_char |==============================================================================| | Keyword: [File name] | | Required: Yes | | Description: Used to specify the name of the IBIS file, "filename.ibs". | | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | | and no characters that are illegal in DOS). In addition, it | | must be all lower case, and use the extension ".ibs". | |------------------------------------------------------------------------------| [File name] ver1_1.ibs |==============================================================================| | Keyword: [File Rev] | | Required: Yes | | Description: Used to track the revision level of a particular .ibs file. | | Usage Rules: Revision level can be set at the discretion of the engineer | | defining the file. The following guidelines are recommended: | | 0.x silicon and file in development | | 1.x pre-silicon file data from silicon model only | | 2.x file correlated to actual silicon measurements | | 3.x mature product, no more changes likely | |------------------------------------------------------------------------------| [File Rev] 1.0 | Used for .ibs file variations |==============================================================================| | Keywords: [Date] [Source] [Notes] [Disclaimer] | | Required: Optional | | Description: Optionally used for further file clarifications. | | Usage Rules: The [Date] information is allowed to contain blanks, and be of | | any format up to 40 characters. | |------------------------------------------------------------------------------| [Date] 04/19/93 | Latest file revision date [Source] Put originator and source of information here. For example: From silicon level SPICE model at Intel, From lab measurement at IEI, Compiled from manufacturer's data book at Quad Design, etc... [Notes] This section can be used for any special notes related to the file. [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component |==============================================================================| | Keyword: [Component] | | Required: Yes | | Description: Used to mark the beginning of the IBIS description of the | | integrated circuit named after the keyword. | | Usage Rules: If the .ibs file contains data for more than one component, | | each section must begin with a new [Component] keyword. The | | length of the Component Name must not exceed 40 characters, | | and blank characters are allowed. | |------------------------------------------------------------------------------| [Component] Component Name |==============================================================================| | Keyword: [Manufacturer] | | Required: Yes | | Description: Used to clarify the component's manufacturer. | | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | | characters (blank characters are allowed, e.g., Texas | | Instruments). In addition, each manufacturer must use a | | consistent name in all .ibs files. | |------------------------------------------------------------------------------| [Manufacturer] Manufacturer's Name | e.g., Intel |==============================================================================| | Keyword: [Package] | | Required: Yes | | Description: Used to define a range of values for the default packaging | | resistance, inductance, and capacitance of the component pins. | | Sub-Params: R_pkg, L_pkg, C_pkg | | Usage Rules: Typical column must be specified. If data for the other | | columns are not available, they must be noted with "NA". | | Other Notes: If RLC parameters are available for individual pins, they can | | be listed in columns 4-6 under keyword [Pin]. The values | | listed in the [Pin] description section override the default | | values defined here. | |------------------------------------------------------------------------------| [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF |==============================================================================| | Keyword: [Pin] | | Required: Yes | | Description: Used to associate the component's I/O models to its various | | external pins and signal names. | | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | | Usage Rules: All pins on a component must be specified. The first column | | must contain the pin name. The second column, signal_name, | | gives the data book name for the signal on that pin. The | | third column, model_name, associates the I/O model for that | | pin. Each model_name must have a [Model] keyword below, | | unless it is a reserved model name (POWER, GND, or NC). | | | | Each line must contain either three or six columns. A pin | | line with three columns only associates the pin's signal and | | model. Six columns can be used to override the default | | package values (specified under [Package]) FOR THAT PIN ONLY. | | When using six columns, the headers R_pin, L_pin, and C_pin | | must be listed. If "NA" is in columns 4 through 6, the | | default packaging values must be used. | | | | Column length limits are: | | [Pin] 5 characters max | | model_name 20 characters max | | signal_name 20 characters max | | R_pin 9 characters max | | L_pin 9 characters max | | C_pin 9 characters max | |------------------------------------------------------------------------------| [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 VCC3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF |############################################################################### |# PENDING BIRD14 ADDITION FOR VERSION 2.0 |#============================================================================= |# Keyword: [SPECS] |# Required: No |#Description: Used to list pin-level specifications that differ from |# the more global sub-params listed under [Model] below. |# Sub-Params: Vinl, Vinh, Vt, Cref, C_comp |#Usage Rules: Only pins that have values different from the default |# values specified in [Model] sub-parameters should be |# listed. Sub-parameters not used on a line must be |# filled in with NA. |# The [SPECS] section consists of five characters for a |# pin number, six for Vinl, six for Vinh, five for Vt, |# five for Cref, and six for each of the three |# sub-parameters in C_comp. These three sub-parameters |# represent the following: typ, min, and max. All |# sub-parameters must be separated by at least one |# blank space. This comes to a total of fifty-two |# characters. |#----------------------------------------------------------------------------- [SPECS] |# C_comp Pin Vinl Vinh Vt Cref typ min max 1 0.8V 2.0V 1.5V 50pF 4.5pF 3.0pF 6.0pF 4 NA NA 2.5V 30pF NA NA NA 9 1.5V 3.5V NA NA NA NA NA |############################################################################### |******************************************************************************* |* BIRD10.1 ADDITION FOR VERSION 1.1Y |*============================================================================== |* Keyword: [Package Model] |* Required: No |* Description: Used to indicate the name of the package model |* Usage Rules: The Package_Model_Name is limited to 40 characters. |* Spaces are allowed in the name. |* Other Notes: |* The [Package_Model] keyword is used within a [Component] to indicate |* which package model should be used for that part. |* |* The resolved specification permits .ibs files to contain [Define |* Package Model] keywords as well. These are described |* "Syntax for the .pkg file", below. 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 which have the same |* name. |*------------------------------------------------------------------------------ |* [Package Model] Package_Model_Name |******************************************************************************* |******************************************************************************* |* BIRD10.1 ADDITION FOR VERSION 1.1Y |*============================================================================== |* NOTE, KEYWORDS FOR [Define Package Model] through [End Model Data] |* FOR EACH "Package_Model_Name" ARE CURRENTLY DEFINED IN BIRD10.1. THESE |* PACKAGE MODELS MAY IN A SEPARATE FILE .pkg ACCORDING |* TO BIRD10.1. THE KEYWORDS MAY ALSO EXIST IN IBIS FILES .ibs |* WITHIN [Define Package Model] ... [End Model Data] BLOCKS FOR EACH |* PACKAGE MODEL THAT IS DEFINED. FOR REFERENCE, THESE KEYWORDS THAT |* MAY EXIST IN THE IBIS FILE ARE LISTED HERE. REFER TO BIRD10.1 FOR |* THEIR FULL DESCRIPTION, SYNTAX AND USAGE. |* |* [Define Package Model] |* [Manufacturer] |* [OEM] |* [Description] |* [Number of Pins] |* [Pin Names] |* [Model Data] |* [Resistance Matrix] |* [Inductance Matrix] |* [Capacitance Matrix] |* [Row] |* [Bandwidth] |* [End Model Data] |*============================================================================== |******************************************************************************* |******************************************************************************* |* BIRD5.2 ADDITION FOR VERSION 1.1X |*========================================================================== |* Keyword: [Pin_Mapping] |* Required: Optional |*Description: Used to indicate which power and ground buses a given driver |* or receiver is connected. |* Sub-Params: gnd, pwr |*Usage Rules: Each power and ground bus is given a unique name which must |* not exceed 20 characters. The first column contains a pin |* number. Each pin number must match one of the pin numbers |* declared previously in the [Pin] section of the IBIS file. |* The second column, "gnd", designates the ground bus connection |* for that pin. Similarly, the third column, "pwr", designates |* the power bus connection. |* |* If the [Pin_Mapping] keyword is present, then the bus |* connections for EVERY pin listed in the [Pin] section must |* be given. |* |* If a pin has no connection, then both the "pwr" and "gnd" |* entries for it may by NC. |* |* Column length limits are: |* [Pin_Mapping] 5 characters max |* gnd 20 characters max |* pwr 20 characters max |*--------------------------------------------------------------------------- [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections ..... ..... ..... 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. ..... 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC ..... 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. ..... 41 NC PWRBUS2 | second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 |******************************************************************************* |############################################################################### |# PENDING BIRD5.4 REPLACEMENT OF BIRD5.2 FOR VERSION 2.0 |#========================================================================== |# Keyword: [Pin_Mapping] |# Required: Optional |#Description: Used to indicate which power and ground buses a given driver, |# receiver, or terminator is connected. |# Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref |#Usage Rules: Each power and ground bus is given a unique name which must |# not exceed 15 characters. The first column contains a pin |# number. Each pin number must match one of the pin numbers |# declared previously in the [Pin] section of the IBIS file. |# The second column, "pulldown_ref", designates the ground bus |# connections for that pin. Here the term "ground bus" can |# also mean another "power bus". The third column "pullup_ref" |# designates the power bus connection. The forth and fifth |# columns "gnd_clamp_ref" and "power_clamp_ref" contain |# entries, if needed, to specify different ground bus |# and power bus connections than those previously specified. |# |# If the [Pin_Mapping] keyword is present, then the bus |# connections for EVERY pin listed in the [Pin] section must |# be given. |# |# Each line must contain either three or five columns. "NC" |# is used for entries which are not needed or which follow |# the conditions below: |# |# If a pin has no connection, then both the "pulldown_ref" |# and "pullup_ref" entries for it will be NC. |# |# GND and POWER pin entries and buses are designated by |# entries in either the "pulldown_ref" or "pullup_ref" columns. |# There is no implied association to any column other than |# through explicit designations in other pins. |# |# For any other type of pin, the "pulldown_ref" column contains |# the power connection for the [Pulldown] table for non-ECL type |# [Models]. This is also the power connection for the [GND_clamp] |# table and the [Rgnd] model unless overriden by a specification |# in the "gnd_clamp_ref" column. |# |# Also, the "pullup_ref" column contains the power connection |# for the [Pullup] table and, for ECL type models, the [Pulldown] |# table. This is also the power connection for the [POWER_clamp] |# table and the [Rpower] model unless overriden by a specification |# in the "power_clamp_ref" column. |# |# Column length limits are: |# [Pin_Mapping] 5 characters max |# pulldown_ref 15 characters max |# pullup_ref 15 characters max |# gnd_clamp_ref 15 characters max |# power_clamp_ref 15 characters max |# |#--------------------------------------------------------------------------- [Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref |# 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections |# 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP 5 GNDBUS2 PWRBUS2 NC PWRCLAMP 6 GNDBUS2 PWRBUS2 GNDCLMP NC | Some possible clamping connections |# ..... | are shown above for illustration |# ..... | purposes |# ..... 11 GNDBUS1 NC | One set of ground connnections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. |# ..... 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC |# ..... 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. |# ..... 41 NC PWRBUS2 | Second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 |# ..... 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps |############################################################################### |****************************************************************************** |* BIRD6.2 ADDITION FOR VERSION 1.1X |*========================================================================== |* Keyword: [Diff_Pin] |* Required: Optional |*Description: Used to associate differential pins, their differential |* threshold voltages and differential timing delays. |* Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |*Usage Rules: Entries follow these rules: Only differential pin pairs |* are entered. The [Diff_pin] column contains a non-inverting |* pin number and the inv_pin column always contains the |* corresponding inverting pin number for output and I/O output. |* The vdiff column contains the specified differential threshold |* voltage between pins if the pins are Input or I/O Model_types. |* For Output only differential pins, the vdiff entry is 0V. |* The tdelay columns contain launch delays of the non-inverting |* pins relative to the inverting pins. The values can be either |* polarity. |* |* BIRD2.2 Addition within BIRD6.2 |* If a pin is a differential input pin the differential input threshold |* (vdiff) overrides and supercedes the need for Vinh and Vinl. |* |* If vdiff is not defined for a pin that is defined as requiring a Vinh by |* its [Model] type, the parser will issue a warning and vdiff will be set to |* the default value of 200mV. |* |*Other Notes: The output pin polarity specification in the table overrides |* the [Model] Polarity specification such that the pin in the |* [Diff_pin] column will be Non-Inverting and the pin in the |* inv_pin column will be Inverting. This convention allows |* one [Model] to be used for both pins. |* |* Column length limits are: |* [Diff_Pin] 5 characters max |* inv_pin 5 characters max |* vdiff 9 characters max |* tdelay_typ 9 characters max |* tdelay_min 9 characters max |* tdelay_max 9 characters max |* |* Each line must contain either four or six columns. If "NA" is |* entered in the vdiff, tdelay_typ or tdelay_min columns, its |* entry will be interpreted as 0V or 0ns. If "NA" appears in |* the tdelay_max column, its value will be interpreted as the |* tdelay_typ value. When using six columns, the headers |* tdelay_min and tdelay_max must be listed. Entries for the |* tdelay_min column are based on minimum magnitudes; and |* tdelay_max column, maximum magnitudes. One entry of vdiff |* regardless of its polarity is used for difference magnitudes. |*--------------------------------------------------------------------------- [Diff_Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max |* 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V |****************************************************************************** |==============================================================================| | Keyword: [Model] | | Required: Yes | | Description: Used to define a model, and its attributes. | | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp | |############################################################################### |# PENDING BIRD14 replacement of Sub-Params: |# Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vt, Cref |############################################################################### |* |* BIRD7.2 and 9.3 modifications |* Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, |* Open_sink, I/O_open_sink, Open_source, I/O_open_source, |* Input_ECL, Output_ECL, I/O_ECL and Terminator model must |* | begin with the keyword [Model]. The model_name must match | | the one that is listed under the [Pin] keyword and must not | | contain more than 20 characters. An .ibs file must contain | | enough [Model] keywords to cover all of the model_names | | specified under the [Pin] keyword, except for those | | model_names which use reserved words (POWER, GND and NC). | | Model_names with reserved words are an exception and | | they do not have to have a corresponding [Model] keyword. | | C_comp is allowed to use "NA" for the min and max values only. | |* |* BIRD2.2 addition |* The model types Input, I/O, I/O_open_drain, I/O_open_sink, |* I/O_open_soure must have Vinl and Vinh defined. If |* they are not defined, the parser will issue a warning and the default |* values of Vinl=.8V and Vinh=2.0V will be assumed. |* |* The model types Input_ECL and I/O_ECL must have Vinl and Vinh defined. If |* they are not defined, the parser will issue a warning and the default |* values of Vinl=-1.475V and Vinh=-1.165V will be assumed. |* |* BIRD9.3 change |* Other Notes: A complete [Model] description normally contains the following |* keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], |* [POWER_clamp], [Rgnd], [Rpower], [Rac], [Cac], |* and [Ramp]. However, some models may have only |* a subset these keywords. For example, an input structure |* normally only needs the [Voltage range], [GND_clamp], and |* possibly the [POWER_clamp] keywords. If one or more of |* [Rgnd], [Rpower], [Rac] and [Cac] keywords are used, then |* the Model_type must be Terminator. |* |* BIRD2.2 addition |* A "Terminator" is an input only device that can have analog loading effects |* on the circuit being simulated but has no digital logic thresholds. |* Examples of "Terminators" are: Capacitors, Termination Diodes, Pullup |* resistors etc. |* |* BIRD7.2 addition |* Model_types with "open_sink" specify that the output has |* an OPEN side (the [Pullup] keyword is not used or I = 0mA |* for all voltages specified) AND the output SINKS current. |* Model_types with "open_drain" have the identical meaning and |* are retained for backward compatibility. Model_types with |* "open_source" specify that the output has an OPEN side (the |* [Pulldown keyword is not used or I = 0mA for all voltages |* specified) AND the output SOURCES current. Model_types with |* "_ECL" specify that the model represents and ECL type logic |* which follows different conventions for the [Pulldown] keyword. |* | Note that C_comp defines the silicon die capacitance. This | | value should not include the capacitance of the package. | | | |############################################################################### |# PENDING BIRD14 addition |# Component timings are usually specified into a |# reference capacitance that can be listed as Cref. Vt is |# the test voltage at a driver that timings are specified |# to. (This is usually around the 50% level of the voltage |# thresholds. For example, TTL=1.5V, CMOS=2.5V.) |############################################################################### |------------------------------------------------------------------------------| [Model] model_name |* |* BIRD7.2 and BIRD9.3 modification Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source, Input_ECL, Output_ECL, I/O_ECL, Terminator | List one only |* Polarity Non-Inverting, Inverting | List one only, if any Enable Active-High, Active-Low | List one only, if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, if desired Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any |############################################################################### |# PENDING BIRD14 addition Vt=1.5V |Test voltage timings are specified to Cref=50pF |Reference capacitance timings are specified into |############################################################################### | variable typ min max C_comp 12.0pF 10.0pF 15.0pF |==============================================================================| | Keyword: [Voltage range] | | Required: Yes | | Description: Used to define the power supply voltage tolerance over which | | the model is intended to operate. | | Usage Rules: Actual voltages (not percentages) are to be presented in the | | usual typ, min, max format. "NA" is allowed for the min and | | values only. | | Other Notes: [Voltage range] also describes the voltage range over which | | the various V/I curves and ramp rates were derived. | |------------------------------------------------------------------------------| | variable typ min max [Voltage range] 5.0V 4.5V 5.5V |****************************************************************************** |* BIRD3 replacement of [Voltage range] text above for VERSION 1.1X |*========================================================================== |* Keyword: [Voltage range] |* Required: Yes, if [Pullup reference], [Pulldown reference], |* [Power_clamp reference], and [GND_clamp reference] are not |* present |*Description: Used to define the power supply voltage tolerance over which |* the the model is intended to operate. It also specifies the |* default voltage rail the pullup and POWER_clamp V/I data is |* referenced to. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*--------------------------------------------------------------------------- |* variable typ min max [Voltage range] 5.0v 4.5v 5.5v |*=========================================================================== |* Keyword: [Pullup reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a voltage rail other than that defined by |* the [Voltage range] keyword as the reference voltage |* for the pullup V/I data. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: This keyword, if present, also defines the voltage range over |* which the min and max dV/dt_r values are derived. |*--------------------------------------------------------------------------- |* variable typ min max [Pullup reference] 5.0V 4.5V 5.5V |*=========================================================================== |* Keyword: [Pulldown reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a power supply rail other than 0v as the |* reference voltage for the pulldown V/I data. If this keyword |* is not present the voltage data points in the pulldown V/I table |* are referenced to 0v. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: This keyword, if present, also defines the voltage range over |* which the min and max dV/dt_f values are derived. |*--------------------------------------------------------------------------- |* variable typ min max [Pulldown reference] 0V 0V 0V |* Keyword: [POWER_clamp reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a voltage rail other than that defined by |* the [Voltage range] keyword as the reference voltage |* for the POWER_clamp V/I data. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |*--------------------------------------------------------------------------- |* variable typ min max [POWER_clamp reference] 5.0V 4.5V 5.5V |*=========================================================================== |* Keyword: [GND_clamp reference] |* Required: Yes, if the [Voltage range] keyword is not present. |*Description: Used to define a power supply rail other than 0v as the |* reference voltage for the GND_clamp V/I data. If this keyword |* is not present the voltage data points in the GND_clamp V/I table |* are referenced to 0v. |*Usage Rules: Actual voltages (not percentages) are to be presented in the |* usual typ, min, max format. "NA" is allowed for the min and |* max values only. |*Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |*--------------------------------------------------------------------------- |* variable typ min max [GND_clamp reference] 0V 0V 0V |*============================================================================ |* NOTES ON SPECIFYING POWER SUPPLIES |* It is the intention that standard TTL and CMOS devices be specified |* using only the [Voltage range] keyword. However, in cases where |* the output characteristics of a device depend on more than a single |* supply and ground, or a pullup, pulldown or clamp structure is referenced |* to something other than the default supplys, the additional 'reference' |* keywords are to be used. |* If the [Voltage range] keyword is not present then all four of the |* other keywords must be present. If the [Voltage range] keyword is |* present the other keywords are optional and may or may not be used as |* required. It is legal (although redundant) for an optional keyword to |* specify the same voltage as specified by the [Voltage range] keyword. |****************************************************************************** |==============================================================================| | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | | Required: Yes, if they exist in the device | | Description: The data points under these keywords define the V/I curves of | | the pulldown and pullup structures of an output buffer and the | | V/I curves of the clamping diodes connected to the GND and the | | POWER pins, respectively. | |* |* BIRD11.2 Continuation of Previous Paragraph: |* Currents are considered positive |* when their direction is into the component. |* | Usage Rules: In each of these sections the first column contains the | | voltage value, and the three remaining columns hold the | | typical, minimum, and maximum current values. The four | | entries, Voltage, I(typ), I(min), and I(max) must be placed on | | a single line and must be separated by at least one white | | space or tab character. | | All four columns are required under these keywords, however | | data is only required in the typical column. If minimum | | and/or maximum current values are not available, the reserved | | word "NA" must be used. "NA" can be used for currents in the | | typical column, but numeric values MUST be specified for the | | first and last voltage points on any V/I curve. Each V/I | | curve must have at least 2, but not more than 100, voltage | | points. | | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | | [POWER_clamp] structures are 'Vcc relative', meaning that the | | voltage values are referenced to the Vcc pin. The voltages in | | the data tables are derived from the equation: | | Vtable = Vcc - Voutput | | Therefore, for a 5V component, -5 V in the table actually | | means 5 V above Vcc, which is +10 V with respect to ground; | | and 10 V means 10 V below Vcc, which is -5 V with respect to | | ground. Vcc-relative data is necessary to model a pullup | | structure properly, since the output current of a pullup | | structure depends on the voltage between the output and Vcc | | pins and not the voltage between the output and ground pins. | | Note that the [GND_clamp] V/I curve can include quiescent | | input currents, or the currents of a 3-stated output if so | | desired. | |****************************************************************************** |* BIRD4 ADDITION FOR VERSION 1.1X |* When tabulating data for ECL devices, the data in the pulldown table |* is measured with the output in the 'logic low' state. In other words, |* the data in the table represents the V-I characteristics of the |* output when the output is at the most negative of its two logic |* levels. Likewise, the data in the pullup table is measured with the |* output in the 'logic one' state and represents the V-I characteristics |* when the output is at the most positive logic level. Note that in BOTH |* these cases the data is referenced to the VCC supply voltage, using |* the equation Vtable = Vcc - Voutput. |****************************************************************************** |* BIRD8.2 ADDITION FOR VERSION 1.1Z |* The V/I table DATA SHOULD BE MONOTONIC to insure that most |* simulators provide stable simulations. Monotonic data is |* needed to insure that all data is single valued. MONOTONIC |* DATA IS NOT REQUIRED to provide a valid IBIS model. |* It is recognized that automated measurement equipment may |* be used to acquire this data and as such may include "noise" |* which causes the data to be non-monotonic. It is also |* recognized |* that some device may be non-monotonic in certain regions. |* Therefore the IBIS specification allows non-monotonic data. |* Simulation tools should filter out non-monotonic data if |* such data causes instabilities in the simulation results. |* To be monotonic the V/I table data must meet any one of the |* following 8 criteria: |* 1- The CURRENT axis either increases or remains constant as |* the voltage axis is increased. |* 2- The CURRENT axis either increases or remains constant as |* the voltage axis is decreased. |* 3- The CURRENT axis either decreases or remains constant as |* the voltage axis is increased. |* 4- The CURRENT axis either decreases or remains constant as |* the voltage axis is decreased. |* |* 5- The VOLTAGE axis either increases or remains constant as |* the current axis is increased. |* 6- The VOLTAGE axis either increases or remains constant as |* the current axis is decreased. |* 7- The VOLTAGE axis either decreases or remains constant as |* the current axis is increased. |* 8- The VOLTAGE axis either decreases or remains constant as |* the current axis is decreased. |* |* The IBIS_CHK program will test for non-monotonic data and |* provide a maximum of one note per V/I table if non-montonic |* data is found. |* "NOTE: Line xxx of V/I table yyy for model zzz is |* non-monotonic! Most simulators will filter this data |* to remove the non-monotonic data." |* Where xxx is the line number in the IBIS file. |* Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. |* Where zzz is the name of the model. |* |* It is also recognized that the some data may be monotonic if |* currents from both the output stage and the clamp diode are |* added together as most simulators do. To limit the complexity |* of the version 2.0 IBIS_CHK program, it will consider only one |* V/I table at a time monotonicity testing. |* |############################################################################### |# PENDING BIRD15 addition |# Assumptions: It is assumed that the simulator sums the clamp |# curves together with the appropriate pullup or |# pulldown curve when a buffer is driving high or low, |# respectively. From this assumption and the nature |# of 3-statable buffers it follows that the data in |# the clamping curve sections are handled as |# constantly present curves and the pullup and |# pulldown curves are used only when needed in the |# simulation. |# |# The clamp curves of an input or I/O buffer can be |# measured directly with a curve tracer, the I/O |# buffer being 3-stated. However, sweeping enabled |# buffers results in curves that are the sum of the |# clamping curves and the output structures. Based on |# the assumption outlined above, the pullup and |# pulldown curves of an IBIS model must represent the |# difference of the 3-stated and the enabled buffer's |# curves. (Note that the resulting difference curve |# may demonstrate a non-monotonic shape). This allows |# the simulator to sum the curves, without the danger |# of double counting, and arrive at an accurate model |# in both the 3-stated and enabled conditions. |# |# Since in the case of a non 3-statable buffer this |# difference curve cannot be generated through lab |# measurements (because the clamping curves can not be |# measured alone), the pullup and pulldown curves of |# an IBIS model may contain the sum of the clamping |# characteristics and the output structure. In this |# case the clamping curves must contain all zeroes, or |# the keywords must be omitted. |# |############################################################################### |****************************************************************************** |------------------------------------------------------------------------------| [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND_clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER_clamp] | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA |******************************************************************************* |* BIRD9.3 ADDITION FOR VERSION 1.1Y |*========================================================================== |* Keywords: [Rgnd], [Rpower], [Rac], [Cac] |* Required: Yes, if they exist in the device |* Description: The data for these keywords define the resistance values of |* Rgnd and Rpower connected to GND and the POWER pins, |* respectively. |* Usage Rules: For each of these sections the three columns hold the |* typical, minimum, and maximum resistance values. The three |* entries for R(typ), R(min), and R(max) or C(typ), C(min), |* and C(max) must be placed on a single line and must be |* separated by at least one white space or tab character. |* All three columns are required under these keywords, however |* data is only required in the typical column. If minimum |* and/or maximum values are not available, the reserved word |* "NA" must be used indicating the R(typ) or C(typ) value by |* default. |* Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and |* [Rgnd] is connected to 'GND'. However, [GND_clamp reference] |* voltages, if defined, apply to [Rgnd]. [POWER_clamp reference] |* voltages, if defined, apply to [Rpower]. |* Either or both [Rgnd] and [Rpower] may be defined and may |* co-exist with [GND_clamp] and [POWER_clamp] structures. |* If an AC terminator is specified, then both [Rac] and [Cac] |* are required. |* When [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the |* Model_type must be Terminator. |*------------------------------------------------------------------------------ |* variable R(typ) R(min) R(max) |* [Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator [Rpower] 220Ohm 200Ohm NA | |* [Rac] 30Ohm NA NA | |* |* variable C(typ) C(min) C(max) | AC terminator |* [Cac] 50pF NA NA | |******************************************************************************* |==============================================================================| | Keyword: [Ramp] | | Required: Yes, except for inputs | | Description: Used to define the rise and fall times of a buffer. | | Sub-Params: dV/dt_r, dV/dt_f | | Usage Rules: These parameters describe an ideal slope and can be expressed | | as a ratio of any reasonable voltage and time values as shown | | in the examples. The [Ramp] values are allowed to use "NA" | | for the min and max values only. | |------------------------------------------------------------------------------| [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n |############################################################################### |# PENDING BIRD13.2 REPLACEMENT OF [Ramp] FOR VERSION 2.0 |#============================================================================== |# Keyword: [Ramp] |# Required: Yes, except for inputs |# Description: Used to define the rise and fall times of a buffer. |# Sub-Params: dV/dt_r, dV/dt_f, ramp |# Usage Rules: These parameters describe an ideal slope and can be expressed |# as a ratio of any reasonable voltage and time values as shown |# in the examples. The [Ramp] values are allowed to use "NA" |# for the min and max values only. |# The load sub-parameter is optional if the preferred 50 ohm load is used. |# It is required if a non-standard load is used. |#------------------------------------------------------------------------------ [Ramp] |# variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n load 300ohms |############################################################################### |******************************************************************************* |* BIRD12.2 ADDITION FOR VERSION 1.1Z |*========================================================================== |* Keywords: [Rising waveform], [Falling waveform] |* Required: No |* Description: Used to describe the shape of the rising and falling edge |* waveforms of a driver. |* Sub-params: R_fixture, V_fixture, C_fixture, L_fixture, |* R_dut, L_dut, C_dut |* Usage Rules: Each [Rising waveform] and [Falling waveform] keyword |* introduces a table of time vs. voltage points that |* describe the shape of an output waveform. These |* time/voltage points are taken under the conditions |* specified in the R/L/C/V_fixture and R/L/C_dut |* sub-parameters. The table itself consists of |* one column of time points, then three columns of |* voltage points in the standard typ, min and max format. |* The four entries must be placed on a single line and |* must be separated by at least one white space or tab |* character. All four columns are required, however, data |* is only required in the typical column. If minimum |* or maximum data is not available the reserved word "NA" |* is used. The first value in the time column does not |* have to be '0'. Time values must increase as |* one parses down the table. The waveform table may |* contain a maximum of 100 data points. There is a |* maximum of 100 waveform tables allowed per model. |* Note that for backwards compatibility the existing |* [Ramp] keyword is still required. |* |* A waveform table must include the entire waveform; |* i.e., the first entry (or entries) in a voltage column |* must be the DC voltage of the output before switching |* and the last entry (or entries) of the column must be |* the final DC value of the output after switching. |* |* A [Model] specification can contain more than one |* rising edge or falling edge waveform table; |* however, each new table must begin with the appropriate |* keyword and sub-parameter list as shown below. If more |* than one rising or falling edge waveform table is |* present, then the data in each of the respective tables |* must be time correlated. In other words, the rising |* (falling) edge data in each of the rising (falling) edge |* waveform tables must be entered with respect to a |* common reference point on the input stimulus waveform. |* |* The 'fixture' sub-parameters specifies the loading |* conditions under which the waveform is taken. |* The R_dut, C_dut, and L_dut are analogous to the the |* package parameters R_pkg, C_pkg and L_pkg and are used |* if the waveform includes the effects of pin |* inductance/capacitance. The diagram below shows the |* interconnection of these elements. |* |* | |* | |* PACKAGE | TEST FIXTURE |* _________ | |* | DUT | L_dut R_dut | L_fixture R_fixture |* | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture |* | | \/ | | | \/ |* |_________| | | | |* | | | |* C_dut === | === C_fixture |* | | | |* | | | |* gnd | gnd |* |* Only the R_fixture and V_fixture sub-parameters are |* required, the rest of the sub-parameters are optional. |* If a sub-parameter is not used its value defaults to |* zero. The sub-parameters must appear in the text after |* the keyword and before the first row of the waveform |* table. |* |*------------------------------------------------------------------------------ [Rising waveform] R_fixture = 500 V_fixture = 5.0 C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |*Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA |* [Falling waveform] R_fixture = 50 V_fixture = 0 |*Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA |******************************************************************************* |############################################################################### |# PENDING BIRD13.2 ADDITION FOR VERSION 2.0 |#============================================================================== |# Keyword: [Temperature range] |# Required: Yes, if other than the preferred 0, 50, 100 degree C range |# Description: Used to define the temperature range over which the model is |# to operate. |# Usage Rules: Actual temperatures (not percentages) are to be presented in |# the usual typ, min, max format. "NA" is not allowed. |# Other Notes: [Temperature range] also describes the temperature range over |# which the various V/I curves and ramp rates were derived. Note |# that these are die temperatures, not ambient temperatures. |#------------------------------------------------------------------------------ |# variable typ min max [Temperature range] 27.0C -50C 130.0C |############################################################################### |==============================================================================| | Keyword: [End] | | Required: Yes | | Description: Used to define the end of the .ibs file. | |------------------------------------------------------------------------------| [End] |==============================================================================| | | | NOTES ON DATA DERIVATION METHOD | | | | This section explains how data values are derived. The intention here is to | | avoid over-guardbanding, enabling simulation results that are meaningful and | | useful. This is accomplished by having each silicon vendor base their data | | on typical process data, and then derate by voltage and temperature, and a | | proprietary "X%" factor. This methodology also has the nice feature that | | the data can be derived either from vendor-proprietary silicon models, or | | typical device measurement over temperature/voltage. | | | | 1) V/I curves for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "X%" | | max = hi voltage tol, 0 degrees C, typical process, plus "X%" | | | | V/I curves for bipolar devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 0 degrees C, typical process, minus "X%" | | max = hi voltage tol, 100 degrees C, typical process, plus "X%" | | | | where X% should be statistically determined by the silicon vendor | | based on numerous fab lots, test chips, process controls, ... The | | value of X need not be published in the IBIS file, and may decrease | | over time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | | |############################################################################### |# PENDING BIRD13.2 REPLACEMENT OF 1) FOR VERSION 2.0 |# |# 1) V/I curves for CMOS devices: |# typ = nominal voltage, nominal temperature deg C, typical process |# min = low voltage tol, max temperature deg C, typical process, minus"X%" |# max = hi voltage tol, min teperature deg C, typical process, plus "X%" |# |# V/I curves for bipolar devices: |# typ = nominal voltage, nominal temperature deg C, typical process |# min = low voltage tol, min temperature deg C, typical process, minus "X%" |# max = hi voltage tol, max teperature deg C, typical process, plus "X%" |# |# where nominal, min, and max temperature are specified by the manufacturer of |# the part. The preferred range is 50C nom, 0C min and 100C max temperatures. |# |# X% should be statistically determined by the silicon vendor |# based on numerous fab lots, test chips, process controls, ... The |# value of X need not be published in the IBIS file, and may decrease |# over time as data on the I/O buffers and silicon process increases. |# Temperatures are junction temperatures. |# |############################################################################### | 2) Voltage Ranges: | | Points for each curve must span the voltages listed below: | | | | Curve Low Voltage High Voltage | | ----------- ----------- ------------ | | [Pulldown] GND - POWER POWER + POWER | | [Pullup] GND - POWER POWER + POWER | | [GND_clamp] GND - POWER GND + POWER | | [POWER_clamp] POWER POWER + POWER | | | | For example, a device with a 5 V power supply voltage should be | | characterized between (0 - 5) = -5 V and (5 + 5) = 10 V; | | and a device with a 3.3 V power supply should be characterized | | between (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the | | pulldown curve. | | |****************************************************************************** |* BIRD4 ADDITION FOR VERSION 1.1X |* When tabulating output data for ECL type devices, the voltage points |* must span the range of VCC to VCC - 2.2V. This range applies to both the |* pullup and pulldown tables. Note that this range applies ONLY when |* characterizing an ECL output. |****************************************************************************** |############################################################################### |# PENDING BIRD13.2 ADDITION FOR VERSION 2.0 |# These voltage ranges must be spanned by the ibis data. Data derived from lab |# measurements may not be able to span these ranges as such and so may need to |# be extrapolated to cover the fullrange. This must not be left for the |# simulator. |############################################################################### | | | 3) Ramp Rates: | | The ramp rates (listed in AC characteristics below) should be | | derived by: | | 1. Start with silicon model, remove all packaging. | | 2. Attach 50 Ohm resistor to GND to derive rising edge ramp. | | 3. Attach 50 Ohm resistor to POWER to derive falling edge ramp. | | 4. Due to the resistor, output swings will not make a full | | transition as expected. However the pertinent data can still | | be collected as follows: | | a) determine the 20% to 80% voltages of the 50 Ohm swing | | b) measure this voltage change as "dv" | | c) measure the amount of time required to make this swing "dt" | | 5. Post the value as a ratio "dv/dt", the simulation tool vendor | | will extrapolate this value to span the required voltage swing | | range in the final model. | | 6. Typ, Min, and Max must all be posted, and are derived at the | | same extremes as the V/I curves, which are: | | | | Ramp times for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "Y%" | | max = hi voltage tol, 0 degrees C, typical process, plus "Y%" | | | | Ramp times for bipolar devices: | | To be determined by manufacturer. | | | | Note that the derate factor, "Y%", may be different than that used | | for the V/I curve data. This factor is similar to the X% factor | | described above. As in the case of V/I curves, temperatures are | | junction temperatures here also. | | | | 7. The rise time of an open-drain device must be measured into | | a 50 Ohm pullup resistor tied to the power pin. | | | |****************************************************************************** |* BIRD7.2 REPLACEMENT OF 3) FOR VERSION 1.1X |* NOTE, Items 3. and 7. above deleted, Items 4. thru 6. renumbered 3. thru 5. |* |* 3) Ramp Rates: |############################################################################### |# PENDING BIRD13.2 ADDITION FOR VERSION 2.0 |# The following steps assume that the preferred load resistance of 50 ohms is |# used. |# There may be devices which will not drive a load of only 50 ohms into any |# useful level of dynamics. In these cases use the manufacturers |# suggested ( non-reactive ) load and add the load sub parameter to the |# [Ramp] specification. |# |############################################################################### |* The ramp rates (listed in AC characteristics below) should be derived |* as follows: |* |* 1. Start with the silicon model, remove all packaging. |* |* 2. If: The Model_type is one of the following: Output, I/O, or |* 3-state (not open or ECL types); |* Then: Attach a 50 ohm resistor to GND to derive the rising edge |* ramp. Attach a 50 ohm resistor to POWER to derive the |* falling edge ramp. |* |* If: the Model_type is Output_ECL or I/O_ECL; |* Then: Attach a 50 ohm resistor to the termination voltage |* (Vterm = VCC - 2v). Use this load to derive both the |* rising and falling edges. |* |* If: The Model_type is either an open_sink type or open_drain type; |* Then: Attach either a 50 ohm resistor or the vendor suggested |* termination resistance to either POWER or the vendor suggested |* termination voltage. Use this load to derive both the rising |* and falling edges. |* |* If: The Model_type is an open_source type; |* Then: Attach either a 50 ohm resistor or the vendor suggested |* termination resistance to either GND or the vendor suggested |* termination voltage. Use this load to derive both the rising |* and falling edges. |* |* 3. Due to the resistor, output swings will not make a full |* transition as expected. However the pertinent data can still |* be collected as follows: |* a) determine the 20% to 80% voltages of the 50 Ohm swing |* b) measure this voltage change as "dv" |* c) measure the amount of time required to make this swing "dt" |* 4. Post the value as a ratio "dv/dt", the simulation tool vendor |* will extrapolate this value to span the required voltage swing |* range in the final model. |* 5. Typ, Min, and Max must all be posted, and are derived at the |* same extremes as the V/I curves, which are: |* |* Ramp times for CMOS devices: |* typ = nominal voltage, 50 degrees C, typical process |* min = low voltage tol, 100 degrees C, typical process, minus "Y%" |* max = hi voltage tol, 0 degrees C, typical process, plus "Y%" |* |* Ramp times for bipolar devices: |* To be determined by manufacturer. |* |* Note that the derate factor, "Y%", may be different than that used |* for the V/I curve data. This factor is similar to the X% factor |* described above. As in the case of V/I curves, temperatures are |* junction temperatures here also. |############################################################################### |# PENDING BIRD13.2 REPLACEMENT OF 5. FOR VERSION 2.0 |# 5. Typ, Min, and Max must all be posted, and are derived at the |# same extremes as the V/I curves, which are: |# |# Ramp times for CMOS devices: |# typ = nominal voltage, nominal temperature deg C, typical process |# min = low voltage tol, max temperature deg C, typical process, minus"X%" |# max = hi voltage tol, min teperature deg C, typical process, plus "X%" |# |# Ramp times for bipolar devices: |# typ = nominal voltage, nominal temperature deg C, typical process |# min = low voltage tol, min temperature deg C, typical process, minus "X%" |# max = hi voltage tol, max teperature deg C, typical process, plus "X%" |# |# where nominal, min, and max temperature are specified by the manufacturer of |# the part. The preferred range is 50C nom, 0C min and 100C max temperatures. |# |# Note that the derate factor, "Y%", may be different than that used |# for the V/I curve data. This factor is similar to the X% factor |# described above. As in the case of V/I curves, temperatures are |# junction temperatures here also. |############################################################################### |############################################################################### |# PENDING BIRD13.2 ADDITION FOR VERSION 2.0 |# |# 6. During the IV measurements |# the driving waveform should be of a rise/fall time fast enough to avoid |# thermal feedback which is probably not realistic but slow enough that package |# parasitics do not distort the data. The specific choice of sweep time is |# left to the modelling engineer. |############################################################################### |****************************************************************************** | | It is expected that this data will be created from silicon vendor | | proprietary silicon-level models, and later correlated with actual device | | measurement. | |==============================================================================| |******************************************************************************| | ADDITIONAL NOTES FOR IBIS EXTENSIONS (BIRDS) | |******************************************************************************| ******************************************************************************* NOTES ON BIRD2.2 3) Add the following requirements to [Model]: The model types Input, I/O, I/O_open_drain, I/O_open_sink, I/O_open_source must have Vinl and Vinh defined. If they are not defined, the parser will issue a warning and the default values of Vinl=.8V and Vinh=2.0V will be assumed. The model types Input_ECL and I/O_ECL must have Vinl and Vinh defined. If they are not defined, the parser will issue a warning and the default values of Vinl=-1.475V and Vinh=-1.165V will be assumed. ECL defaults derived from FAIRCHILD F100K ECL data book specification of Guaranteed input HIGH and LOW. 4) The following is added to the differential specification to clarify Differential input threshold: If a pin is a differential input pin the differential input threshold (vdiff) overrides and supercedes the need for Vinh and Vinl. If vdiff is not defined for a pin that is defined as requiring a Vinh by its [Model] type, the parser will issue a warning and vdiff will be set to the default value of 200mV. 5) The golden parser must be modified to allow "Terminators" and (4) and check for (3) and (4). ******************************************************************************* NOTES ON BIRD3 Most of the above is fairly self-explanatory. The key here is to realize that the four 'reference' keywords, in effect, create separate power supply rails that override the default [Voltage range] supply. The intention was to create a very general and flexible way to handle multiple supply devices and ECL. To illustrate with some examples: 1. An RS223 line driver has a +/- 12V output swing. One way to specify this device is shown below typ min max [Voltage range] 12.0V 11.5V 12.5V | fixes pullup and | POWER_clamp ref [Pulldown reference] -12.0V -11.5V -12.5V | fixes pulldown ref [GND_clamp reference] -12.0V -11.5v -12.5V | fixes GND_clamp ref Optionally, the [Voltage range] keyword could be replaced with the [Pullup reference] and [POWER_clamp] reference. 2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for it's internal logic. The power clamp diodes are referenced to the 5V supply. Their are two equally valid ways this device can be specified. typ min max [Voltage range] 3.3V 3.0V 3.6V | fixes pullup reference [POWER_clamp reference 5.0V 4.5V 5.5V | fixes POWER_clamp | reference typ min max [Voltage range] 5.0V 4.5V 5.5V | fixes both pullup and | POWER_clamp reference [Pullup reference] 3.3V 3.0V 3.6V | overrides [Voltage | range] specification | on the pullup 3. When specifying a device with an ECL type output structure, the pulldown curves must be referenced to the most positive supply (the same one that the pullup curves are referenced to). The easiest way to do this is define the value of the [Voltage range] as 0v. Both the pullup AND pulldown V/I curves will be referenced to 0v (remember, the pulldown defaults to 0v). typ min max [Voltage range] 0V 0V 0V | VCC supply [Pulldown reference] 0V 0V 0V | not really | required, its | specified for | completeness [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Alternately, one could specify the VEE supply and then override the default values of the pullup and pulldown references typ min max [Voltage range] -4.5V -4.0V -5.5v | VEE supply [Pullup reference] 0v 0v 0V [Pulldown reference] 0v 0v 0v [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Finally, to specify ECL logic that is used with a +5V supply (positive ECL) one can do the following: typ min max [Voltage range] 5.0V 4.5V 5.5V | VCC supply [Pulldown reference] 5.0V 4.5V 5.5V | override default The default references are used for the pullup and GND_clamp V/I curves. ******************************************************************************* NOTES ON BIRD4 (1) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. (2) The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. (3) The second proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ****************************************************************************** NOTES ON BIRD5.2 To be better able to simulate the ground bounce effect, it is necessary to know which pins of a part are connected to a common ground or power bus. This BIRD provides a simple mechanism for identifying these common buses. This improves the simulation of ground bounce by limiting the noise effects of switching drivers to other drivers and receivers on the same bus. STATEMENT OF THE RESOLVED SPECIFICATIONS: Each power and ground bus is given a unique name which must not exceed 20 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] gnd pwr 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ..... .... .... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ..... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ..... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ..... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "gnd", designates the ground bus connection for that pin; similarly, the third column, "pwr", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd" column indicates the ground bus to which it is attached. The entry in the "pwr" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "gnd" and "pwr" columns designate the power and ground buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pwr" and "gnd" entries for it may be NC. ****************************************************************************** ############################################################################### NOTES ON PENDING BIRD5.4 General Explaination: Each power and ground bus is given a unique name which must not exceed 15 characters. An additional OPTIONAL keyword, [Pin_Mapping], is added to the specification. Following this keyword is information indicating to which power and ground buses a given driver or receiver is connected. As an example of the new format, say that we have two ground buses (named GNDBUS1 and GNDBUS2) which each bus together 3 pins: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more and two similarly structured power buses (PWRBUS1 and PWRBUS2): Pins: 31 32 33 41 42 43 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few PWRBUS1 drivers PWRBUS2 more We assume that the "signal name" for pins 11-13 and 21-23 are all "GND", and that the names for pins 31-33 and 41-43 are all "VDD". The new [Pin_Mapping] specification would be as follows: [Pin_Mapping] pulldown_ref pullup_ref 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 ....... ...... ...... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ....... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ....... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ....... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 Explanation: In the above example, the first column contains a pin number; each pin number must match one of the pin numbers declared previously in the [Pin] section of the IBIS file. The second column, "pulldown_ref", designates the ground bus connection for that pin; similarly, the third column, "pullup_ref", designates the power bus connection. For a GND pin, such as pins 11-13 and 21-23, the entry in the "pulldown_ref" column indicates the ground bus to which it is attached. The entry in the "pullup_ref" column is NC because there is, of course, no connection to any power bus. The situation for a POWER pin (e.g. pins 31-33 and 41-43) is analogous. The above example also contains two ordinary signal pins (pins 1 and 2). For these pins, the entries in the "pulldown_ref" and "pullup_ref" columns +designate the ground and power buses to which their buffer models are connected. Thus, for pin 1 there is an instance of the associated I-V model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an instance of an I-V model which connects to PWRBUS2 and GNDBUS2. If the [Pin_Mapping] keyword is present, then the bus connections for EVERY pin listed in the [Pin] section must be given. If a pin has no connection, then both the "pullup_ref" and "pulldown_ref" entries for it may be NC. Optional Extension: [Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref 1 GNDBUS1 PWRBUS1 2 GNDBUS2 PWRBUS2 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP ....... ...... ...... 11 GNDBUS1 NC 12 GNDBUS1 NC 13 GNDBUS1 NC ....... 21 GNDBUS2 NC 22 GNDBUS2 NC 23 GNDBUS2 NC ....... 31 NC PWRBUS1 32 NC PWRBUS1 33 NC PWRBUS1 ....... 41 NC PWRBUS2 42 NC PWRBUS2 43 NC PWRBUS2 ....... 51 GNDCLMP NC 52 NC PWRCLMP Explanation of Optional Extension: This extension illustrates a hypothetical situation where the clamping circuitry is connected to different rails than those of the pullup and pulldown tables. Pins 51 and 52 are hypothetical clamping supplies, and their attachments are shown at pins 3 and 4. While the nomenclature can lead to some potential confusion, the intended operation is according to this interpretation: The "pulldown_ref" column contains the power connection for the [Pulldown] table for non-ECL type [Models]. This is also the power connection for the [GND_clamp] table unless overriden by a specification in the gnd_clamp_ref column. The "pullup_ref" column contains the power connection for the [Pullup] table and for ECL type models, the [Pulldown] table. This is also the power connection for the [POWER_clamp] table unless overriden by a specification in the power_clamp_ref column. ############################################################################### ****************************************************************************** NOTES ON BIRD6.2 Since only a small percentage of components contain differential pins, [Diff_Pin] is optional. The component itself may be required to convey the associations between pins for differential inputs and/or outputs. Such cases may occur in practice when pairs of pins are connected using closely-spaced, coupled nets or twisted-pair cabling. Pins which provide complimentary outputs should not be associated with each other when the analysis is normally done using only one pin at a time. However, there may be cases related to other pending extensions (package models, power association, etc.) where association of complimentary pins may be appropriate. [Diff_pin] should be used for pins designed for differential operation. Inputs of such components have differential input sensitivity specifications such as "Vpp" or "VT+" and "VT-" which define the differential threshold voltages between two input pins. The vdiff column is introduced for such specification limits (the magnitudes used for both polarities) which would trigger an output change. Two switching cycles show that the actual switching can occur at either polarity vdiff relative to one pin (A0_bar). If the actual switching completes near tmax (the threshold past the cross-over), then the first switching completes when (A0 - A0_bar) is negative and the second when (A0 - A0_bar) is positive. One application of vdiff is for timing analysis bounds. |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT | __ | Polarities of vdiff relative to A0 signal show both |<-- tmax -->| polarities used to bound the transition region | | |<-- tmin ->|| (output = 0) (output = 1) __________ || ____________ _____________ \ || / \ / A0 __\||/__ __\ /__ + \/ - vdiff - \/ + DIFFERENTIAL INPUT __ /\ __ __ /\ __ / \ / \ __ __________/ \____________/ \_____________ A0 For timing purposes, an output is referenced to an equal voltage cross-over of output pins. Setting the vdiff entry to 0V is thus chosen when the pins are for differential outputs only. Note, the cross-over does NOT mean that the outputs are at 0V. The Tskew value is the time difference between the mid-point of the two output transitions. It is equivalent to the time-delay of one pin relative to the other pin. Although an absolute value is specified, either pin can delayed relative to the other pin. This specification assumes the outputs are reasonably identical and the rise and fall transitions are reasonably similar. tdelay may relate to Tskew values of unloaded outputs, but are considered separate in IBIS as a launch delay of the non-inverting output relative to the inverting output. tdelay can be either polarity. Tskew can be shown per National Interface Databook, diagram on pg 1-121 along with tdelay: 3V _______________ / \ INPUT TO SAME COMPONENT 1.5V__ / \ /| |\ 0V ___/ | | \______________ | tPLH | |tPHL| ___________ __________ _________ __ ^ ^ |\ Tskew/ \ / ^ D0 | Vo/2 | \|<>|/ \/ Vo/2 Vo v__ | _\ /__ __|/\|_____v DIFFERENTIAL OUTPUT | \/ / \ | | /\ /| |\ v_________|__/ \__________/ | | \_______ D0 | | | | | | >| |< Tskew Tskew = |tPLH - tPHL| | | >| |< tdelay (positive value) Conventions similar to those in [Pin] are followed with respect to required and optional column entries and to column lengths. ****************************************************************************** NOTES ON BIRD7.2 Open-drain is corrected to Open_drain as a Model_type selection and is kept for backward compatibility. I/O_open_drain is added. The new types with "open_sink" and "open_source" are added to generically describe an output with either an open [Pullup] or [Pulldown] and an output that sinks or sources current. Without requiring an explicit test, these new Model_types signal that the [Pullup] or [Pulldown] tables are not defined or are not to be used if defined. Model_types for ECL are defined to fill the functionality table below. Conditions: | Model_type: | pullup&down: | Output 3-state I/O no pullup: | Open_sink I/O_open_sink | Open_drain I/O_open_drain no pulldown: | Open_source I/O_Open_source no pullup/dn:| Input ECL up&down: | Output_ECL I/O_ECL ECL no up/dn:| Input_ECL Note, "ECL" is intended to be generic. It can be used to model "PECL" logic spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the simulator to use different default Vinl and Vinh values if these OPTIONAL (a BIRD2.1 issue) input parameters are not specified. Currently, the user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could be interpreted as an "open_sink" device. Omission of [Pulldown] could be interpreted as an "open_source" device. However, this method was never specified in IBIS Version 1.1 as the correct method and therefore was not the only method to specify "Open" devices. The user may choose to model the "Open" side directly through control of the [Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA entries (a minimum of two entries are required), then that [Model] could be interpreted as "open". Zero valued [Pullup] data corresponds to "open_sink" or "open_drain" types. Zero valued [Pulldown] data corresponds to "open_source" types. Without the additional Model_types, the above two approaches plus the existance of "Open_drain" provide a confusing and inconsistent specification and require the simulator to perform a variety of tests before being able to process the data. The "ECL" model types are added to avoid similar confusion. ****************************************************************************** NOTES ON BIRD8.2 NO ADDITIONAL NOTES NEEDED ****************************************************************************** NOTES ON BIRD9.3 A set of terminator components is useful to be formatted using IBIS because they are found as packaged components. All of the options can support (typ), (min) and (max) specifications. (1) Parallel Resistor Termination: The additonal elements [Rpower] and [Rgnd] provide terminations to Vcc, Gnd or both. Devices such as the Motorola MCC142233 to MCC142236 Switchable SCSI Passive Bus Terminator series would be modeled with these elements. At least two other techniques could be used in IBIS Version 1.1. The [POWER_clamp] or [GND_clamp] tables could be used (with as few as two data points each) to represent resistors. Another method could be to use R_pkg (or R_pin) with [POWER_clamp] or [GND_clamp] structures configured as a very low impedance. Processing tabular data for these purposes would be less efficient and less obvious than working with resistive elements directly. (2) RC (or AC) Termination: R_pkg (or R_pin) and C_comp can provide RC terminations. This proposal specifies [Rac] connected to [Cac] elements. This will allow packaged RC terminations which include built in clamping diodes to be modeled directly. Diode terminators already can be modeled using IBIS Version 1.1: (3) Diode Termination: Devices such as the TI SN74S1050 thru SN74S1056 Schottky Barrier Diode Bus-Termination Arrays can be modeled using existing [POWER_clamp] and [GND_clamp] structures. The total context model is attached showing the proposed additions. |<-------------TERMINATOR Model--------------->| VOLTAGE RANGE or POWER_CLAMP REF o | POWER_ |---o---| CLAMP | | |--o--| \ | | / | VI | \ RPOWER PACKAGE Keyword | | / Parameters |--o--| | |<----------------->| | | | | PIN o-----o-------o-----o-----/\/\/\--UUUUUU---o--o | |GND_ | | R_PKG L_PKG | | |CLAMP | | | | |--o--| | | | | | | \ | | | | VI | /RGND | | | | | \ \ | | |--o--| / / RAC | | | | \ | | |---o---| / | | | | | C_COMP --- o --- CAC C_PKG --- --- GND or --- --- | GND_CLAMP REF | | | | | |-------------------o----------------------| | o GND |<-------->| Proposed Terminator Keywords ****************************************************************************** NOTES ON BIRD10.1 Refer to BIRD10.1 for the complete specification and description STATEMENT OF THE RESOLVED SPECIFICATIONS: Summary: ------- A new keyword, [Package Model], is added to the .ibs file. This keyword is used within a [Component] to indicate (by name) the package model that should be used for a part. Package models can be found either in separate package model files, which bear the .pkg extension, or within the same .ibs file as the [Component]. An additional new keyword, [Define Package Model], is also added to the specification; this is used to mark the beginning of the actual package model data. The purpose of breaking up the package model and the component model is to make associations between the two more flexible: several components may share a single package model, or one component may have several different incarnations which use different packages (and thus, different package models). Use of [Package Model] is OPTIONAL. If it is not provided, then the table of RLC values listed in the [Pin] section of the [Component] is used as the "package model" for the part. On the other hand, if the [Package Model] IS given, then the R_pin, L_pin and C_pin values in the [Pin] section may either be ignored, or may be used for less detailed simulations without coupling. Probably this data will simply be left out of the [Pin] section when a [Package Model] is used; this practice is permitted by the IBIS Ver. 1.1 specification since [Pin] data may contain either 3 or 6 columns. A .pkg file is just an ordinary IBIS file, with the restriction that it cannot contain [Component]'s or [Model]'s. Only package models declared by the [Define Package Model] keyword may be contained within these files. Of course, all of the necessary components of an IBIS file ([IBIS Ver], [File Name], [File Rev], etc. through [End]) must still be included within a .pkg file. The package model to be used treats every package as a collection of current carrying "paths," which lead from the board, through the packages pins, leadframe traces and bonding wires to a bonding pad on the die itself. Each path has a self-resistance, self-inductance and self-capacitance associated with it. In addition, there is the flexibility to describe mutual inductance, mutual resistance and coupling capacitance drops between every path. This data can be listed concisely as three RLC parameter matrices. This BIRD describes how these matrices are to be formatted. ****************************************************************************** NOTES ON BIRD11.2 ... THESE NOTES REFER TO CHANGES IN THE IBIS_CHK PROGRAM *************************************************************************** Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. *************************************************************************** For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, GND_clamp 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The current in the TYPICAL column corresponding to Vmax is less than the current in the TYPICAL column corresponding to Vmin than the table is assumed to have decreasing current. ELSE IF:The current in the TYPICAL column corresponding to Vmax is greater than the current in the TYPICAL column corresponding to Vmin than the table is assumed to have increasing current. ELSE: The table is assumed to have equal current." Note: This works for all cases of discontinuities unless the magnitude of discontinuity is such that this model is in all probability competely unrealistic. Examples: *** example with non-monotonic data at the end point V: I: 0.00 0.0 4.90 50.0ma 4.91 49.9ma 4.93 56.7ma 5.00 3.0ma -> V/I table has increasing current (3.0 > 0) Vmax = 5.0, I =3.0mA Vmin = 0.0, I =0.0 *** example with negative to positve voltages with negative first V: I: -5.00 -0.1ma 0.00 0.0 5.00 100.0ma -> V/I table has increasing current (100 > -0.1) Vmax = 5.0, I=100mA Vmin = -5.0, I=-0.1mA *** example with table data entered postive voltages first V: I: 5.00 10.1ma 0.00 0.0 -5.00 -10.1ma -> V/I table has increasing current (10.1 > -10.1) Vmax = 5.0, I=10.1mA Vmin = -5.0, I=-10.1mA *** example with only two entrys V: I: 0.00 0.0 -5.00 10.1ma -> V/I table has decreasing current (0 < 10.1) Vmax = 0.0, I=0 Vmin = -5.0, I=10.1mA *** ECL example [Pullup] Voltage I(typ) I(min) I(max) 0.0 0 0 0 0.7 -0.2m -0.2m -0.2m 0.73 -0.4m -0.4m -0.4m 0.75 -0.8m -0.8m -0.8m 0.76 -1.2m -1.2m -1.2m 0.77 -1.6m -1.6m -1.6m 0.8 -4.4m -4.4m -4.4m 0.82 -7.6m -7.6m -7.6m 0.85 -14.2m -14.2m -14.2m 0.9 -30.0m -30.0m -30.0m 1.0 -58.0m -50.0m -68.0m -> V/I table has decreasing current ( -58 < 0) Vmax = 1.0, Ityp=-58mA Vmin = 0, Ityp=0 [Pulldown] Voltage I(typ) I(min) I(max) 0.0 0 0 0 1.6 -0.2m -0.2m -0.2m 1.62 -0.4m -0.4m -0.4m 1.64 -0.6m -0.6m -0.6m 1.65 -0.8m -0.8m -0.8m 1.66 -1.2m -1.2m -1.2m 1.67 -1.6m -1.6m -1.6m 1.68 -2.4m -2.4m -2.4m 1.69 -3.2m -3.2m -3.2m 1.70 -4.4m -4.4m -4.4m 1.72 -7.4m -7.4m -7.4m 1.75 -14.2m -14.2m -14.2m 1.8 -30.5m -30.5m -30.5m 1.9 -65.0m -60.0m -75.0m -> V/I table has decreasing current ( -65 < 0) Vmax = 1.9, Ityp=-65mA Vmin = 0.0, Ityp= 0 *** An abreviated INTEL model for a CMOS output |**************************************************************************** [Pulldown] | Voltage I(typ) I(min) I(max) -5.00V -38.70mA -29.47mA -51.22mA -1.00V -24.88mA -19.18mA -32.90mA -0.50V -14.35mA -11.06mA -19.05mA 0.00V -11.84pA -554.66pA -11.03pA 100.00mV 3.20mA 2.47mA 4.27mA 200.00mV 6.24mA 4.80mA 8.30mA 4.90V 38.68mA 29.45mA 51.18mA 5.00V 38.70mA 29.47mA 51.22mA 10.00V 39.96mA 30.37mA 53.06mA -> V/I table increasing [GND_clamp] | Voltage I(typ) I(min) I(max) -5.00V -680.00mA NA NA -1.10V -75.50mA NA NA -600.00mV -950.00uA NA NA -500.00mV -78.00uA NA NA -200.00mV 0.00pA NA NA -100.00mV 0.00pA NA NA 0.00V 0.00pA NA NA 5.00V 0.00pA NA NA -> V/I table increasing (0 > -680) [Pullup] | Voltage I(typ) I(min) I(max) -5.00V 38.14mA 27.33mA 54.76mA -4.50V 37.49mA 26.87mA 53.79mA -1.00V 17.13mA 12.81mA 23.55mA -0.50V 9.26mA 6.96mA 12.66mA 0.00V 13.57pA 613.51pA 11.04pA 100.00mV -1.96mA -1.48mA -2.67mA 200.00mV -3.87mA -2.92mA -5.27mA 500.00mV -9.26mA -6.96mA -12.66mA 1.80V -26.79mA -19.79mA -37.25mA 1.90V -27.74mA -20.46mA -38.64mA 4.60V -37.62mA -26.97mA -54.00mA 4.70V -37.76mA -27.06mA -54.20mA 5.00V -38.14mA -27.33mA -54.76mA 10.00V -44.52mA -33.72mA -61.15mA -> V/I table decreasing [POWER_clamp] | Voltage I(typ) I(min) I(max) -5.00V 1.05A NA NA -1.10V 79.00mA NA NA -1.00V 54.00mA NA NA -900.00mV 29.00mA NA NA -800.00mV 10.40mA NA NA -200.00mV 0.00uA NA NA -100.00mV 0.00uA NA NA 0.00V 0.00pA NA NA -> V/I table decreasing 3) IF the model is any of the following types:(Input_ECL, Output_ECL, I/O_ECL) { Verify that: - Pullup V/I table has equal or decreasing current - POWER_clamp V/I table has equal or decreasing current - Pulldown V/I table has equal or decreasing current - GND_clamp V/I table has equal or increasing current } ELSE { Verify that: - Pullup V/I table has equal or decreasing current - POWER_clamp V/I table has equal or decreasing current - Pulldown V/I table has equal or increasing current - GND_clamp V/I table has equal or increasing current } Note: This specifically allows constant current generators and 0 current tables. 0 current tables may be used to indicate table is unused. 4) If any table verification fails report the following error message: 'Error found in xxx V/I table at line number nnn!'. Where xxx is one of the following Pullup, Pulldown, POWER_clamp, GND_clamp. Where nnn is the line number. *************************************************************************** Change 3- Add a header comment statement at the TOP of the IBIS_CHK program to insure that new changes to the IBIS_CHK program donot break tests that worked in old MAJOR versions. This approach makes the program larger however it insures the parser always works the same on older versions of IBIS. This apporach uses more memory, but has the reward of low maintaining costs. The IBIS_CHK program is very small and would not be effected by this until many revisions have occured. *************************************************************************** NOTICE TO ANY PERSON MODIFING THIS PROGRAM! ------------------------------------------- This program SHALL NOT BE MODIFIED unless there is an associated IBIS BIRD. Said BIRD shall be agreed upon by IBIS committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is allowed to modify the source code. The present CZAR is Jon Powell (April 1994). The IBIS committee may also hire programmers from time to time to make major changes to the source code. Note: Source licensees are free to modify their own copies of this source code in any way they choose. Source licensees shall not redistribute the source code modified or otherwise. Source licensing is available from the IBIS open forum. The IBIS open forum is non-profit. The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED when adding code for the next version of the IBIS specification. Instead completely new code for all functions and features shall be created. This may require duplication of numerous functions. Each function shall be preceded by VXX_ where XX is the MAJOR version of the IBIS specification which is being parsed and tested. A MAJOR version would for example be 1.x going to 2.x. A MINOR version would for example be 1.1 to 1.2. Functions using the above syntax would look as follows: V01_GetValue MINOR revisions DO NOT required new code. Startup code shall be provided at the top of the program which reads the version number from the IBIS file and runs the portion of the program corresponding to that MAJOR version. Code which is used only by the program startup function is not duplicated. ****************************************************************************** NOTES ON BIRD12.2 ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Currently, the IBIS specification assumes that all devices can be described accurately using a single risetime and falltime parameter. In other words, the switching waveform of the device is a relatively linear ramp. However, devices that shape the output waveform (risetime controlled devices) do not have a linear switching ramp. Trying to model devices of this type using a linear ramp model results in mis-predicting both the time to logic threshold and maximum edge rate. As IBIS is a specification that focuses on the behavior of a device rather than it structure or implementation, it would be ideal if there were a simple set of measurements one could take in order to describe the non-linearity. Obviously, the waveform shape itself is a good place to start. The fundamental assumption here is that the shape of the waveform, combined with the loading conditions, give simulator vendors enough additional information to construct accurate models of non-linear waveform drivers. Ideally, an IBIS model will include waveforms taken under several different loading conditions (R_fixture and V_fixture). By choosing the appropriate loading conditions a modeler can give the simulator vendors enough information to accurately simulate a device. The most straight forward way to describe a waveform shape is with a table of time vs. voltage points. (Note that one could take this table and enter it into a spreadsheet or graphing program and produce a picture of the waveform -- and that is one of the intents of the format.) One remaining issue is the ability to align the starting points of waveforms taken under different loading conditions (i.e. waveforms in two different tables). Jon Powell (Quad Design) has an action item to produce various waveforms and show this is possible. (PLEASE SEE THE NOTE BELOW ON VERSION 12.0 TO 12.1 CHANGES) In addition to providing more complete information to simulator vendors, explicitly describing the waveform allows one to validate a particular simulator's results. By performing a simulation into the specified load(s) and then comparing the results with the waveform(s) as listed in the IBIS file, one can perform anything from a quick sanity check of the data to a detailed analysis between simulators. A 'self-validating' model is a very powerful tool for checking and maintaining model quality. 3. A statement was added that requires that all rising/falling edge data be time correlated. To make this perfectly clear: the data in one rising edge table must be time correlated to the data in any other RISING edge waveform table. Likewise for falling edge data. There is no requirement for time correlation between the data in rising and falling waveform tables. Note also the requirement that the correlation be to a reference point on the input stimulus waveform. This is to prevent a user from time correlating the waveforms to a point on an output waveform -- this defeats the purpose of time correlation. ******************************************************************************* ############################################################################### NOTES ON PENDING BIRD13.2 The spec should have flexibility enough to handle models of parts manufactured to MIL spec and automotive spec as well as parts for special purposes which are perhaps more sensitive than even consumer or commercial spec allows. Thus the relaxation , or tightening as the case may be, of the temperature and voltage range mandates. The added keyword and sub-parameter are to allow the simulator useable specification of the relaxed or tightened ranges for the relevant measurements. The ramp rate is still mandated to be determined between 20 and 80 % of actual swing to promote the linearity of the measured portion of the edge. The load is mandated to be non-reactive so as to preserve the inherent dynamics of the driver, and not introduce false dynamics due to the load. Backward compatibility is addressed by making the new specifications optional if the preferred votage and temperature ranges and load resistance are used. ############################################################################### NOTES ON PENDING BIRD14 Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Cref and Vt and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overriden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Cref, and Vt is standard data available in data books. Allowing the specification of Cref and Vt enhances the usability of an IBIS model by providing key parameters for simulation. ############################################################################### NOTES ON PENDING BIRD15 NONE ARE NEEDED ############################################################################### From Derrick_Duehren@ccm2.jf.intel.com Wed May 18 13:06:58 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19572; Wed, 18 May 94 13:06:58 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q3rqU-000MNpC; Wed, 18 May 94 13:04 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 18 May 94 13:04:01 PST Date: Wed, 18 May 94 13:04:01 PST From: Derrick Duehren Message-Id: <940518130401_6@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 5/20 Teleconference Meeting Text item: Text_1 IBIS Meeting 5/20/94, 1:00 pm PDT Bridge: Res: (916) 356-9999 315842 Agenda ------ 1:00 Role call 1:10 BIRD 13 discuss and vote 1:20 BIRD 14 discuss and vote 1:30 BIRD 15 discuss and vote 1:40 Discuss and vote on any editing committee issues 1:50 Wrap up Editing Committee ----------------- Kumar, Cadence Kellee Crisafulli, HyperLynx Will Hobbs, Stephen Peters, and Derrick Duehren (admin.), Intel Bob Ross, Interconnectix Ravender Goyal, Mentor Graphics Syed Huq, National Semiconductor Jon Powell, Quad Design From John_M_Keifer@ccm.fm.intel.com Wed May 18 16:05:52 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20749; Wed, 18 May 94 16:05:52 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q3udc-000MNdC; Wed, 18 May 94 16:02 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 18 May 94 16:02:56 PST Date: Wed, 18 May 94 16:02:56 PST From: John M Keifer Message-Id: <940518160256_5@ccm.hf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS14.1 Text item: Text_1 To: IBIS Committee Here is the updated BIRD14 with the suggested fixes. This includes Model_type, Rref, and Vref being added to the [SPECS] section, Rref and Vref being optionally added to all model files, and Vt being changed to Vtest to be clearer on the meaning. I have asked around and to my knowledge everyone agrees with these changes and with this updated BIRD. If anyone has any further problems with this BIRD, please put them on the reflector and let me know. Note: No defaults were added for backcompatability. This means that with this BIRD, if an old IBIS Model is used that doesn't have the parameters of this BIRD, the parameter is ignored (i.e. there is no official default configuration for the simulator, and the Model is treated just like it is presently with IBIS Version 1.1). The user has the choice to either use an old Model as it is, obtain a new Model from their vendor, or obtain the needed data book and edit(upgrade) the Model themselves. John Keifer ************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.1 ISSUE TITLE: Adding a new section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: May 18, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. It is also desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [SPECS], is added to the .IBS file. The keyword [SPECS] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [SPECS] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vtest (a test voltage), are added to a [Model]. These sub-parameters are also optional. |************************************************************************* | | Keyword: [SPECS] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vtest, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [SPECS] section consists of five characters for a | pin number, ten for Model_type, six for Vinl, six for | Vinh, five for Vtest, five for Rref, five for Vref, five | for Cref, and six for each of the three sub-parameters | in C_comp. These three sub-parameters represent the | following: typ, min, and max. All sub-parameters must | be separated by at least one blank space. This comes | to a total of seventy-five characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [SPECS] | C_comp Pin Model_type Vinl Vinh Vtest Rref Vref Cref typ min max 1 NA 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA NA 2.5V NA NA 30pF NA NA NA 9 NA 1.5V 3.5V NA NA NA NA NA NA NA 12 I/O NA NA NA NA NA NA NA NA NA 13 NA NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vtest, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vtest is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vtest=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vtest, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Vtest, Rref, Vref, and Cref and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overridden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Vtest, Rref, Vref, and Cref is standard data available in data books. Allowing the specification of Vtest, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* From Don_A_Telian@ccm.fm.intel.com Thu May 19 10:03:06 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00184; Thu, 19 May 94 10:03:06 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q4BRz-000MNpC; Thu, 19 May 94 10:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 19 May 94 10:00:03 PST Date: Thu, 19 May 94 10:00:03 PST From: Don A Telian Message-Id: <940519100003_1@ccm.hf.intel.com> To: John_M_Keifer@ccm.fm.intel.com, Arpad_Muranyi@ccm.fm.intel.com, Will_Hobbs@ccm2.jf.intel.com, ibis@vhdl.org Subject: BIRD 14.1, Updated from John Keifer Text item: Text_1 To: IBIS Committee Here is the updated BIRD14 with the suggested fixes. This includes Model_type, Rref, and Vref being added to the [SPECS] section, Rref and Vref being optionally added to all model files, and Vt being changed to Vtest to be clearer on the meaning. I have asked around and to my knowledge everyone agrees with these changes and with this updated BIRD. If anyone has any further problems with this BIRD, please put them on the reflector and let me know. Note: No defaults were added for backcompatability. This means that with this BIRD, if an old IBIS Model is used that doesn't have the parameters of this BIRD, the parameter is ignored (i.e. there is no official default configuration for the simulator, and the Model is treated just like it is presently with IBIS Version 1.1). The user has the choice to either use an old Model as it is, obtain a new Model from their vendor, or obtain the needed data book and edit(upgrade) the Model themselves. John Keifer ************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.1 ISSUE TITLE: Adding a new section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: May 18, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. It is also desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [SPECS], is added to the .IBS file. The keyword [SPECS] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [SPECS] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vtest (a test voltage), are added to a [Model]. These sub-parameters are also optional. |************************************************************************* | | Keyword: [SPECS] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vtest, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [SPECS] section consists of five characters for a | pin number, ten for Model_type, six for Vinl, six for | Vinh, five for Vtest, five for Rref, five for Vref, five | for Cref, and six for each of the three sub-parameters | in C_comp. These three sub-parameters represent the | following: typ, min, and max. All sub-parameters must | be separated by at least one blank space. This comes | to a total of seventy-five characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [SPECS] | C_comp Pin Model_type Vinl Vinh Vtest Rref Vref Cref typ min max 1 NA 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA NA 2.5V NA NA 30pF NA NA NA 9 NA 1.5V 3.5V NA NA NA NA NA NA NA 12 I/O NA NA NA NA NA NA NA NA NA 13 NA NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vtest, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vtest is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vtest=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vtest, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Vtest, Rref, Vref, and Cref and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overridden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Vtest, Rref, Vref, and Cref is standard data available in data books. Allowing the specification of Vtest, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* From Derrick_Duehren@ccm2.jf.intel.com Thu May 19 20:43:01 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05118; Thu, 19 May 94 20:43:01 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q4LRJ-000MNOC; Thu, 19 May 94 20:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 19 May 94 20:40:01 PST Date: Thu, 19 May 94 20:40:01 PST From: Derrick Duehren Message-Id: <940519204001_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: BIRD 14.1 Text item: Text Item To: IBIS Committee Here is the updated BIRD14 with the suggested fixes. This includes Model_type, Rref, and Vref being added to the [SPECS] section, Rref and Vref being optionally added to all model files, and Vt being changed to Vtest to be clearer on the meaning. I have asked around and to my knowledge everyone agrees with these changes and with this updated BIRD. If anyone has any further problems with this BIRD, please put them on the reflector and let me know. Note: No defaults were added for backcompatability. This means that with this BIRD, if an old IBIS Model is used that doesn't have the parameters of this BIRD, the parameter is ignored (i.e. there is no official default configuration for the simulator, and the Model is treated just like it is presently with IBIS Version 1.1). The user has the choice to either use an old Model as it is, obtain a new Model from their vendor, or obtain the needed data book and edit(upgrade) the Model themselves. John Keifer ************************************************************************* ************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.1 ISSUE TITLE: Adding a new section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: April 26, 1994 DATE REVISED: May 18, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. It is also desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [SPECS], is added to the .IBS file. The keyword [SPECS] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [SPECS] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vtest (a test voltage), are added to a [Model]. These sub-parameters are also optional. |************************************************************************* | | Keyword: [SPECS] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vtest, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [SPECS] section consists of five characters for a | pin number, ten for Model_type, six for Vinl, six for | Vinh, five for Vtest, five for Rref, five for Vref, five | for Cref, and six for each of the three sub-parameters | in C_comp. These three sub-parameters represent the | following: typ, min, and max. All sub-parameters must | be separated by at least one blank space. This comes | to a total of seventy-five characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [SPECS] | C_comp Pin Model_type Vinl Vinh Vtest Rref Vref Cref typ min max 1 NA 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA NA 2.5V NA NA 30pF NA NA NA 9 NA 1.5V 3.5V NA NA NA NA NA NA NA 12 I/O NA NA NA NA NA NA NA NA NA 13 NA NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vtest, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vtest is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vtest=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vtest, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Vtest, Rref, Vref, and Cref and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overridden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Vtest, Rref, Vref, and Cref is standard data available in data books. Allowing the specification of Vtest, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:03:35 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06918; Wed, 25 May 94 00:03:35 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6Cwu-000MOBC; Wed, 25 May 94 00:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:00:20 PST Date: Wed, 25 May 94 00:00:20 PST From: Derrick Duehren Message-Id: <940525000020_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, Part 1 Text item: Text_1 Key to right-most column revision marks: ## = Editor Comments $ = Change from Version 1.1 Post comments to the IBIS reflector. We will discuss this draft at the 5/27/94 IBIS teleconference. The bridge number is (415) 904-8800 #744468, 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). - Derrick Duehren (Derrick_Duehren@ccm.jf.intel.com) ----------------------------------- Cut Here ---------------------------------- |============================================================================== | I/O Buffer Information Specification (IBIS) Version 2.x1 [DRAFT 5/24/94] |============================================================================== | | Statement of Intent: | | In order to enable an industry standard method to electronically transport | IBIS Modeling Data between silicon vendors, simulation software vendors, and | end customers, this template is proposed. The intention of this template is | to specify a consistent format that can be parsed by software, allowing each | simulation vendor to derive models compatible with their own product. | | One goal of this template is to represent the current state of IBIS data, | while allowing a growth path to more complex models / methods (when deemed | appropriate). This would be accomplished by a revision of the base | template, and possibly the addition of new keywords or categories. | | Another goal of this template is to ensure that it is simple enough for | silicon vendors and customers to use and modify, while ensuring that it is | rigid enough for software simulation vendors to write reliable parsers. | | Finally, this template is meant to contain a complete description of the I/O | elements on an entire component. Consequently, several models will need to | be defined in each file, as well as a table that equates the appropriate | buffer to the correct pin and signal name. | | Version 1.1 of this electronic template was finalized by an industry-wide | group of simulation experts representing various companies and interests. | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | ASCII file format. It represents the minimum amount of I/O buffer | information required to create an accurate IBIS model of common CMOS and | bipolar I/O structures. Future revisions of the ASCII file will add items | considered to be "enhancements" to Version 1.0 to allow accurate modeling | of new, or other, I/O buffer structures. Consequently, all future | revisions will be considered super sets of Version 1.0, allowing backward | compatibility. In addition, as modeling platforms develop support for | revisions of the IBIS ASCII template, all previous revisions of the | template must also be supported. | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | comments have been added for further clarification. | $| Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility $| with Versions 1.0 and 1.1. A complete list of changes to the specification $| is in the IBIS Version 2.0 Release Notes document ("ver2_0.rn"). $| |============================================================================== | $| General syntax rules and guidelines for ASCII IBIS files: | $| 1) The content of the files is case sensitive, except for reserved $| words, parameters, sub-parameters, and keywords. Reserved words and $| keywords are not case sensitive, and file names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no connect pins, | NA - used where data not available. | $| 3) File names used in the file must only have lower case characters to | enhance UNIX compatibility and must conform to DOS rules. (The length of | a file name should not exceed eight plus three characters and it must | not contain special characters which are illegal in DOS). | | 4) The file must have no more than 80 characters per line. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment char] to any other character. The [Comment char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | $| 7) Underscores and spaces are equivalent in keywords. Spaces are not $| allowed in sub-parameter names. | | 8) Valid scaling factors are: $| T = tera k = kilo n = nano $| G = giga m = milli p = pico $| M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, and Henries.) The | parser looks at only one alphabetic character after a numerical entry, | therefore it is enough to use only the prefixes to scale the parameters. | However, for clarity, it is allowed to use full abbreviations for the | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | allowed (e.g., 1.2345e-12). | | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) Currents are considered positive when their direction is into the | component. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |------------------------------------------------------------------------------ $[IBIS Ver] 2.0 | Used for template variations |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment char] keyword. The following | characters can NOT be used: A B C D E F G H I J K L M N O P | Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u $| v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + - | Other Notes: The [Comment char] keyword can be used throughout the file, as | desired. |------------------------------------------------------------------------------ [Comment char] |_char |============================================================================== | Keyword: [File name] | Required: Yes | Description: Specifies the name of the IBIS file, "filename.ibs". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ibs". |------------------------------------------------------------------------------ $[File name] ver2_0.ibs |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely |------------------------------------------------------------------------------ [File Rev] 1.0 | Used for .ibs file variations |============================================================================== $| Keywords: [Date] [Source] [Notes] [Disclaimer] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: The [Date] information is allowed to contain blanks, and be of $| any format up to 40 characters. $| $| Because IBIS model writers may consider the information in $| these keywords essential to users, and sometimes legally $| required, design automation tools should make this information $| available. Derivative models should include this text $| verbatim. Any text following the [Copyright] keyword must be $| included in any derivative models verbatim. |------------------------------------------------------------------------------ $[Date] 06/09/94 | The latest file revision date | [Source] Put originator and the source of information here. For example: From silicon level SPICE model at Intel. From lab measurement at IEI. Compiled from manufacturer's data book at Quad Design, etc... | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | $[Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the Component Name must not exceed 40 characters, | and blank characters are allowed. |------------------------------------------------------------------------------ $[Component] Component Name | e.g., 7403398 MC452 $| |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies the component's manufacturer. | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Manufacturer's Name | e.g., Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines a range of values for the default packaging resistance, | inductance, and capacitance of the component pins. | Sub-Params: R_pkg, L_pkg, C_pkg | Usage Rules: The typical (typ) column must be specified. If data for the | other columns are not available, they must be noted with "NA". | Other Notes: If RLC parameters are available for individual pins, they can | be listed in columns 4-6 under keyword [Pin]. The values | listed in the [Pin] description section override the default $| values defined here. Use the [Package Model] keyword for more $| complex package descriptions. If defined, the [Package Model] $| data overrides the values in the [Package] keyword. $| Regardless, the data listed under the [Package] keyword must $| still be valid. |------------------------------------------------------------------------------ [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF |============================================================================== | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pins and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, associates the I/O model for that | pin. Each model_name must have a [Model] keyword below, | unless it is a reserved model name (POWER, GND, or NC). | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |------------------------------------------------------------------------------ [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF |============================================================================== ################################################################################ ## PENDING BIRD14.1 ADDITION FOR VERSION 2.0 ## $|============================================================================== $| Keyword: [Pin Extension 1] $| Required: Optional $|Description: These data are an extension to the [Pin] keyword. $| Associates additional component specifications for the $| various external pins. $| Sub-Params: Vinl, Vinh, Vmeas, Rref, Vref, Cref, C_comp $|Usage Rules: Only pins that have values different from the default $| values specified in the [Model] sub-parameters should be $| listed. Sub-parameters not used on a line must be $| filled in with NA. All sub-parameters must be separated $| by at least one blank space. Use this keyword to avoid $| duplicating models due to minor differences in pin $| specifications. The definitions of Rref, Vref, Cref and $| C_comp are found under the [Model] keyword. $| Column length limits are: $| Pin 5 characters max $| Vinl 6 characters max $| Vinh 6 characters max $| Vmeas 5 characters max $| Rref 5 characters max $| Vref 5 characters max $| Cref 5 characters max $| C_comp 6 characters max each for "typ", "min", and "max" $|------------------------------------------------------------------------------ $[Pin Extension 1] $| C_comp $| ------------------- $Pin Vinl Vinh Vmeas Rref Vref Cref typ min max $1 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF $4 NA NA 2.5V NA NA 30pF NA NA NA $9 1.5V 3.5V NA NA NA NA NA NA NA $12 NA NA NA NA NA NA NA NA NA $13 NA NA NA 50 5V NA NA NA NA $| $|##################### END OF PENDING BIRD 14.2 ############################### $|============================================================================== $| Keyword: [Package Model] Package_Model_Name $| Required: No $| Description: Indicates the name of the package model $| Usage Rules: The Package_Model_Name is limited to 40 characters. $| Spaces are allowed in the name. The name should include the $| company name or initials to help ensure uniqueness. If the $| package model is in a separate .pkg file, it must be kept in $| the same directory as the .ibs file. $| Other Notes: Use the [Package_Model] keyword within a [Component] to $| indicate which package model should be used for that part. $| The specification permits .ibs files to contain [Define $| Package Model] keywords as well. These are described $| in the "package modeling" section below. When package model $| definitions occur within an .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. $| $| NOTES ON PACKAGE MODELS AND SEPERATE FILES $| $| Keywords for [Define Package Model] through [End Model Data] are $| defined in the "package modeling" section of this specification. Note that $| the actual package models can be in a separate file .pkg. $| or may also exist in the IBIS files between the [Define Package Model]...[End $| Model Data] keywords for each package model that is defined. For reference, $| these keywords are shown below. Refer to the "package modeling" section $| of this specification for full descriptions, syntax and usage. Simulators $| that do not support these keywords will ignore all entries between the $| [Define Package Model] and [End Model Data] keywords. $| $| [Define Package Model] $| [Manufacturer] $| [OEM] $| [Description] $| [Number of Pins] $| [Pin Names] $| [Model Data] $| [Resistance Matrix] $| [Inductance Matrix] $| [Capacitance Matrix] $| [Row] $| [Bandwidth] $| [End Model Data] $| ---------------------------------- end of part one ---------------------------- From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:03:49 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06923; Wed, 25 May 94 00:03:49 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6Cx9-000MOBC; Wed, 25 May 94 00:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:00:35 PST Date: Wed, 25 May 94 00:00:35 PST From: Derrick Duehren Message-Id: <940525000035_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 2 Text item: Text_1 ## DOES THIS BELONG HERE (FROM BOB'S BIRD 10.1x)? ############################ ## When measuring the entries of the RLC matrices, either with laboratory ## equipment or field-solver software, currents are defined as ENTERING the pins ## of the package from the board (General Syntax Rule #10). The corresponding ## voltage drops are to be measured with the current pointing "in" to the "+" ## sign and "out" of the "-" sign. ## ## I1 +-----+ I2 ## -----> | | <------ ## board 0--------| Pkg |---------0 board ## + V1 - | | - V2 + ## +-----+ ## ## It is important to observe this convention in order to get the correct signs ## for the mutual inductances and resistances. ################################################################################ $|------------------------------------------------------------------------------ $[Package Model] Package_Model_Name $| $|============================================================================== $| Keyword: [Pin Mapping] $| Required: No $|Description: Used to indicate which power and ground buses a given driver, $| receiver, or terminator is connected. $| Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref $|Usage Rules: Each power and ground bus is given a unique name which must $| not exceed 15 characters. The first column contains a pin $| number. Each pin number must match one of the pin numbers $| declared previously in the [Pin] section of the IBIS file. $| The second column, "pulldown_ref", designates the ground bus $| connections for that pin. Here the term "ground bus" can $| also mean another "power bus". The third column "pullup_ref" $| designates the power bus connection. The forth and fifth $| columns "gnd_clamp_ref" and "power_clamp_ref" contain $| entries, if needed, to specify different ground bus $| and power bus connections than those previously specified. $| $| If the [Pin Mapping] keyword is present, then the bus $| connections for EVERY pin listed in the [Pin] section must $| be given. $| $| Each line must contain either three or five columns. "NC" $| is used for entries which are not needed or which follow $| the conditions below: $| $| If a pin has no connection, then both the "pulldown_ref" $| and "pullup_ref" entries for it will be NC. $| $| GND and POWER pin entries and buses are designated by $| entries in either the "pulldown_ref" or "pullup_ref" columns. $| There is no implied association to any column other than $| through explicit designations in other pins. $| $| For any other type of pin, the "pulldown_ref" column contains $| the power connection for the [Pulldown] table for non-ECL type $| [Models]. This is also the power connection for the [GND Clamp] $| table and the [Rgnd] model unless overridden by a specification $| in the "gnd_clamp_ref" column. $| $| Also, the "pullup_ref" column contains the power connection $| for the [Pullup] table and, for ECL type models, the [Pulldown] $| table. This is also the power connection for the [POWER Clamp] $| table and the [Rpower] model unless overridden by a specification $| in the "power_clamp_ref" column. $| $| Column length limits are: $| [Pin Mapping] 5 characters max $| pulldown_ref 15 characters max $| pullup_ref 15 characters max $| gnd_clamp_ref 15 characters max $| power_clamp_ref 15 characters max $| $$| When 5 columns are used the headings "gnd_clamp_ref" and $| "power_clamp_ref" must be used. Otherwise, these headings can $| be omitted. $|--------------------------------------------------------------------------- $[Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref $| $1 GNDBUS1 PWRBUS1 | Signal pins and their associated $2 GNDBUS2 PWRBUS2 | ground and power connections $3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP $4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP $5 GNDBUS2 PWRBUS2 NC PWRCLAMP $6 GNDBUS2 PWRBUS2 GNDCLMP NC $ | Some possible clamping connections $| . | are shown above for illustration $| . | purposes $| . $11 GNDBUS1 NC | One set of ground connections. $12 GNDBUS1 NC | NC indicates no connection to $13 GNDBUS1 NC | power bus. $| . $21 GNDBUS2 NC | Second set of ground connections $22 GNDBUS2 NC $23 GNDBUS2 NC $| . $31 NC PWRBUS1 | One set of power connections. $32 NC PWRBUS1 | NC indicates no connection to $33 NC PWRBUS1 | ground bus. $| . $41 NC PWRBUS2 | Second set of power connections $42 NC PWRBUS2 $43 NC PWRBUS2 $| . $51 GNDCLMP NC | Additional power connections $52 NC PWRCLMP | for clamps $| $|============================================================================== $| Keyword: [Diff Pin] $| Required: No $|Description: Associates differential pins, their differential $| threshold voltages, and differential timing delays. $| Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max $|Usage Rules: Enter only differential pin pairs. The [Diff Pin] column $| contains a non-inverting pin number and the inv_pin column $| always contains the corresponding inverting pin number for $| I/O output. The vdiff column contains the specified $| output and differential threshold voltage between pins if $| the pins are Input or I/O Model_types. For output only $| differential pins, the vdiff entry is 0V. The tdelay columns $| contain launch delays of the non-inverting pins relative to $| the inverting pins. The values can be either polarity. $| $| If a pin is a differential input pin, the differential input $| threshold (vdiff) overrides and supersedes the need for Vinh and $| Vinl. $| $| If vdiff is not defined for a pin that is defined as requiring a $| Vinh by its [Model] type. The parser issues a warning and $| vdiff is set to the default value of 200mV. $| $|Other Notes: The output pin polarity specification in the table overrides $| the [Model] Polarity specification such that the pin in the $| [Diff Pin] column is Non-Inverting and the pin in the $| inv_pin column is Inverting. This convention enables $| one [Model] to be used for both pins. $| $| Column length limits are: $| [Diff Pin] 5 characters max $| inv_pin 5 characters max $| vdiff 9 characters max $| tdelay_typ 9 characters max $| tdelay_min 9 characters max $| tdelay_max 9 characters max $| $| Each line must contain either four or six columns. If "NA" is $| entered in the vdiff, tdelay_typ, or tdelay_min columns, its $| entry is interpreted as 0V or 0ns. If "NA" appears in $| the tdelay_max column, its value is interpreted as the $| tdelay_typ value. When using six columns, the headers $| tdelay_min and tdelay_max must be listed. Entries for the $| tdelay_min column are based on minimum magnitudes; and $| tdelay_max column, maximum magnitudes. One entry of vdiff, $| regardless of its polarity, is used for difference magnitudes. $|--------------------------------------------------------------------------- $[Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max $| $ 3 4 150mV -1ns 0ns -2ns | Input or I/O pair $ 7 8 0V 1ns NA NA | Output* pin pair $ 9 10 NA NA NA NA | Output* pin pair $16 15 200mV 1ns | Input or I/O pin pair $20 19 0V NA | Output* pin pair, tdelay = 0ns $22 21 NA NA | Output*, tdelay = 0ns $ | * Could be Input or I/O with vdiff = 0V |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes. $| Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref $| Rref, Vref $| Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, $| Open_sink, I/O_open_sink, Open_source, I/O_open_source, $| Input_ECL, Output_ECL, I/O_ECL, and Terminator model must | begin with the keyword [Model]. The model_name must match | the one that is listed under the [Pin] keyword and must not | contain more than 20 characters. An .ibs file must contain | enough [Model] keywords to cover all of the model_names | specified under the [Pin] keyword, except for those | model_names that use reserved words (POWER, GND and NC). | Model_names with reserved words are an exception and | they do not have to have a corresponding [Model] keyword. | C_comp is allowed to use "NA" for the min and max values only. | The Model_type and C_comp sub-parameters are required. | $| The model types Input, I/O, I/O_open_drain, I/O_open_sink, and $| I/O_open_soure must have Vinl and Vinh defined. If they are not $| defined, the parser issues a warning and the default $| values of Vinl=.8V and Vinh=2.0V are assumed. $| $| The model types Input_ECL and I/O_ECL must have Vinl and Vinh $| defined. If they are not defined, the parser issues a $| warning and the default values of Vinl=-1.475V and Vinh=-1.165V $| are assumed. $| $| Cref, Rref and Rref are optional. These parameters correspond $| to the test load that the manufacturer uses when specifying the $| propagation delay and/or output switching time of the device. $| Vmeas is the reference voltage level the manufacture uses $| for the above. This information is included in the IBIS $| specification to facilitate board-level timing simulation. $| The assumed connections for Cref, Rref, and Rref are shown $| below. $| ## AR John Keifer: Please supply a connection diagram $| $| Other Notes: A complete [Model] description normally contains the following $| keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], $| [POWER Clamp], and [Ramp]. A Model_type of Terminator uses one $| or more of the [Rgnd], [Rpower], [Rac], and [Cac] keywords. $| However, some models may have only a subset of these keywords. $| For example, an input structure normally only needs the $| [Voltage Range], [GND Clamp], and possibly the [POWER Clamp] $| keywords. If one or more of [Rgnd], [Rpower], [Rac], and [Cac] $| keywords are used, then the Model_type must be Terminator. $| $| A "Terminator" is an input-only device that can have analog $| loading effects on the circuit being simulated but has no $| digital logic thresholds. Examples of Terminators are: $| capacitors, termination diodes, pullup resistors etc. $| ## The following paragraph seems confusing to me, particularly the ## parenthetical phrases. - Derrick $| $| Model_types with Open_sink specify that the output has $| an OPEN side (the [Pullup] keyword is not used, or I = 0mA $| for all voltages specified) AND the output SINKS current. $| Model_types with "open_drain" have the identical meaning and $| are retained for backward compatibility. Model_types with $| Open_source specify that the output has an OPEN side (the $| [Pulldown keyword is not used, or I = 0mA for all voltages $| specified) AND the output SOURCES current. Model_types with $| Input_ECL, Output_ECL, or I/O_ECL specify that the model $| represents and ECL type logic that follows different $| conventions for the [Pulldown] keyword. $| | C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, $ I/O_open_drain, Open_sink, I/O_open_sink, $ Open_source, I/O_open_source, Input_ECL, $ Output_ECL, I/O_ECL, Terminator | List one only, if any Polarity Non-Inverting, Inverting | List one only, if any Enable Active-High, Active-Low | List one only, if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, if desired Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any $Vmeas = 1.5V |Test voltage timings are specified to $Cref = 50pF |Timing specification test load capacitance value $Rref = NA |Timing specification test load resistance value $Vref = NA |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== $| Keyword: [Temperature range] $| Required: Yes, if other than the preferred 0, 50, 100 degree C range $| Description: Defines the temperature range over which the model is $| to operate. $| Usage Rules: List the actual die temperatures (not percentages) in the $| usual typ, min, max format. "NA" is not allowed. $| Other Notes: [Temperature range] also describes the temperature range over $| which the various V/I curves and ramp rates were derived. $|------------------------------------------------------------------------------ $| variable typ min max $[Temperature range] 27.0C -50C 130.0C | |============================================================================== | Keyword: [Voltage Range] $| Required: Yes, if [Pullup Reference], [Pulldown Reference], $| [POWER Clamp Reference], and [GND Clamp Reference] are not $| present $|Description: Defines the power supply voltage tolerance over which the $| model is intended to operate. It also specifies the default $| voltage rail to which the pullup and POWER_clamp V/I data is $| referenced. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|--------------------------------------------------------------------------- $| variable typ min max $[Voltage Range] 5.0v 4.5v 5.5v $| $|============================================================================== $| Keyword: [Pullup Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a voltage rail other than that defined by the $| [Voltage Range] keyword as the reference voltage for the $| pullup V/I data. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: This keyword, if present, also defines the voltage range over $| which the min and max dV/dt_r values are derived. $|--------------------------------------------------------------------------- $| variable typ min max $[Pullup Reference] 5.0V 4.5V 5.5V $| $|============================================================================== $| Keyword: [Pulldown Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a power supply rail other than 0v as the reference $| voltage for the pulldown V/I data. If this keyword is not $| present, the voltage data points in the pulldown V/I table $| are referenced to 0v. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: This keyword, if present, also defines the voltage range over $| which the min and max dV/dt_f values are derived. $|--------------------------------------------------------------------------- $| variable typ min max $[Pulldown Reference] 0V 0V 0V $| $|============================================================================== $| Keyword: [POWER Clamp Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a voltage rail other than that defined by the $| [Voltage Range] keyword as the reference voltage for the $| [POWER Clamp] V/I data. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. $|--------------------------------------------------------------------------- $| variable typ min max $[POWER Clamp Reference] 5.0V 4.5V 5.5V $| ---------------------------------- end of part 2 ------------------------------ From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:33:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07385; Wed, 25 May 94 00:33:18 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DPf-000MO3C; Wed, 25 May 94 00:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:30:03 PST Date: Wed, 25 May 94 00:30:03 PST From: Derrick Duehren Message-Id: <940525003003_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 3 Text item: Text_1 $|============================================================================== $| Keyword: [GND Clamp Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a power supply rail other than 0v as the reference $| voltage for the [GND Clamp] V/I data. If this keyword is not $| present, the voltage data points in the [GND Clamp] V/I table $| are referenced to 0v. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: Power Supplies: It is intended that standard TTL and CMOS $| devices be specified using only the [Voltage Range] keyword. $| However, in cases where the output characteristics of a device $| depend on more than a single supply and ground, or a pullup, $| pulldown, or clamp structure is referenced to something other $| than the default supplies, use the additional 'reference' $| keywords. $| $| If the [Voltage Range] keyword is not present, then all four of $| the other keywords must be present. If the [Voltage Range] $| keyword is present, the other keywords are optional and may or $| may not be used as required. It is legal (although redundant) $| for an optional keyword to specify the same voltage as specified $| by the [Voltage Range] keyword. $|--------------------------------------------------------------------------- $| variable typ min max $[GND Clamp Reference] 0V 0V 0V $| |============================================================================== | Keywords: [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves of | the pulldown and pullup structures of an output buffer and the | V/I curves of the clamping diodes connected to the GND and the $| POWER pins, respectively. Currents are considered positive $| when their direction is into the component. $| | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: The V/I curve of the [Pullup] and the [POWER Clamp] structures $| are 'Vcc relative', meaning that the voltage values are $| referenced to the Vcc pin. (Note: Under these keywords, all $| references to 'Vcc' refer to the voltage rail defined by the $| [Voltage range], [Pullup Reference], or [POWER Clamp Reference] $| keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | $| When tabulating data for ECL devices, the data in the pulldown $| table is measured with the output in the 'logic low' state. $| In other words, the data in the table represents the V-I $| characteristics of the output when the output is at the most $| negative of its two logic levels. Likewise, the data in the $| pullup table is measured with the output in the 'logic one' $| state and represents the V-I characteristics when the output $| is at the most positive logic level. Note that in BOTH of $| these cases, the data is referenced to the Vcc supply voltage, $| using the equation Vtable = Vcc - Voutput. $| $| V/I table data is allowed to be non-monotonic in one axis. $| To be monotonic, the V/I table data must meet any one of the $| following 8 criteria: $| 1- The CURRENT axis either increases or remains constant as $| the voltage axis is increased. $| 2- The CURRENT axis either increases or remains constant as $| the voltage axis is decreased. $| 3- The CURRENT axis either decreases or remains constant as $| the voltage axis is increased. $| 4- The CURRENT axis either decreases or remains constant as $| the voltage axis is decreased. $| $| 5- The VOLTAGE axis either increases or remains constant as $| the current axis is increased. $| 6- The VOLTAGE axis either increases or remains constant as $| the current axis is decreased. $| 7- The VOLTAGE axis either decreases or remains constant as $| the current axis is increased. $| 8- The VOLTAGE axis either decreases or remains constant as $| the current axis is decreased. $| $| It is assumed that the simulator sums the clamp curves $| together with the appropriate pullup or pulldown curve when a $| buffer is driving high or low, respectively. From this $| assumption and the nature of 3-statable buffers, it follows $| that the data in the clamping curve sections are handled as $| constantly present curves and the pullup and pulldown curves $| are used only when needed in the simulation. $| $| The clamp curves of an input or I/O buffer can be measured $| directly with a curve tracer, with the I/O buffer 3-stated. $| However, sweeping enabled buffers results in curves that are $| the sum of the clamping curves and the output structures. $| Based on the assumption outlined above, the pullup and $| pulldown curves of an IBIS model must represent the difference $| of the $3-stated and the enabled buffer's curves. (Note that $| the resulting difference curve can demonstrate a non-monotonic $| shape.) This requirement enables the simulator to sum the $| curves, without the danger of double counting, and arrive at $| an accurate model in both the 3-stated and enabled conditions. $| $| Since in the case of a non 3-statable buffer, this difference $| curve cannot be generated through lab measurements (because $| the clamping curves cannot be measured alone), the pullup and $| pulldown curves of an IBIS model can contain the sum of the $| clamping characteristics and the output structure. In this $| case, the clamping curves must contain all zeroes, or the $| keywords must be omitted. |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | $|============================================================================== $| Keywords: [Rgnd], [Rpower], [Rac], [Cac] $| Required: Yes, if they exist in the device $| Description: The data for these keywords define the resistance values of $| Rgnd and Rpower connected to GND and the POWER pins, $| respectively. $| Usage Rules: For each of these keywords, the three columns hold the $| typical, minimum, and maximum resistance values. The three $| entries for R(typ), R(min), and R(max), or the three entries for $| C(typ), C(min), and C(max) must be placed on a single line and $| must be separated by at least one white space or tab character. $| All three columns are required under these keywords. However, $| data is only required in the typical column. If minimum $| and/or maximum values are not available, the reserved word $| "NA" must be used indicating the R(typ) or C(typ) value by $| default. $| Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and $| [Rgnd] is connected to 'GND'. However, [GND Clamp Reference] $| voltages, if defined, apply to [Rgnd]. [POWER Clamp Reference] $| voltages, if defined, apply to [Rpower]. Either or both [Rgnd] $| and [Rpower] may be defined and may coexist-exist with [GND Clamp] $| and [POWER Clamp] structures. If an AC terminator is $| specified, then both [Rac] and [Cac] are required. When $| [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the $| Model_type must be Terminator. $| $| |<-------------TERMINATOR Model--------------->| $| $| VOLTAGE RANGE or $| POWER_CLAMP REF $| o $| | $| POWER_ |---o---| $| CLAMP | | $| |--o--| \ $| | | / $| | VI | \ RPOWER PACKAGE Keyword $| Parameters $| |--o--| | |<----------------->| $| | | $| | | PIN $| o-----o-------o-----o-----/\/\/\--UUUUUU---o--o $| | |GND_ | | R_PKG L_PKG | $| | |CLAMP | | | $| | |--o--| | | | $| | | | \ | | $| | | VI | /RGND | | $| | | | \ \ | $| | |--o--| / / RAC | $| | | | \ | $| | |---o---| / | $| | | | | $| C_COMP --- o --- CAC C_PKG --- $| --- GND or --- --- $| | GND_CLAMP REF | | $| | | | $| |-------------------o----------------------| $| | $| o $| GND $|------------------------------------------------------------------------------ $| variable R(typ) R(min) R(max) $| $[Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator $[Rpower] 220Ohm 200Ohm NA $| $[Rac] 30Ohm NA NA $| $| variable C(typ) C(min) C(max) | AC terminator $| $[Cac] 50pF NA NA $| |============================================================================== | Keyword: [Ramp] | Required: Yes, except for inputs | Description: Defines the rise and fall times of a buffer. $| Sub-Params: dV/dt_r, dV/dt_f, R_load $| Usage Rules: These parameters describe an ideal slope and can be expressed $| as a ratio of any reasonable voltage and time values as shown $| in the examples. The [Ramp] values can to use "NA" for the $| min and max values only. The R_load sub-parameter is optional $| if the preferred 50 ohm load is used. It is required if a non- $| standard load is used. $|------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n $R_load = 300ohms $| $|============================================================================== $| Keywords: [Rising waveform], [Falling waveform] $| Required: No $| Description: Describes the shape of the rising and falling edge $| waveforms of a driver. $| Sub-params: R_fixture, V_fixture, C_fixture, L_fixture, $| R_dut, L_dut, C_dut $| Usage Rules: Each [Rising waveform] and [Falling waveform] keyword $| introduces a table of time vs. voltage points that $| describe the shape of an output waveform. These $| time/voltage points are taken under the conditions $| specified in the R/L/C/V_fixture and R/L/C_dut $| sub-parameters. The table itself consists of $| one column of time points, then three columns of $| voltage points in the standard typ, min, and max format. $| The four entries must be placed on a single line and $| must be separated by at least one white space or tab $| character. All four columns are required. However, data $| is only required in the typical column. If minimum $| or maximum data is not available, use the reserved word $| "NA". The first value in the time column need not be `0'. $| Time values must increase as one parses down the table. $| The waveform table can contain a maximum of 100 data $| points. A maximum of 100 waveform tables are allowed per $| model. Note that for backwards compatibility, the existing $| [Ramp] keyword is still required. $| $| A waveform table must include the entire waveform; $| i.e., the first entry (or entries) in a voltage column $| must be the DC voltage of the output before switching $| and the last entry (or entries) of the column must be $| the final DC value of the output after switching. $| $| A [Model] specification can contain more than one rising $| edge or falling edge waveform table. However, each new $| table must begin with the appropriate keyword and sub- $| parameter list as shown below. If more than one rising or $| falling edge waveform table is present, then the data in $| each of the respective tables must be time correlated. $| In other words, the rising (falling) edge data in each $| of the rising (falling) edge waveform tables must be $| entered with respect to a common reference point on the $| input stimulus waveform. $| $| The 'fixture' sub-parameters specifies the loading $| conditions under which the waveform is taken. The R_dut, $| C_dut, and L_dut Sub-params are analogous to the $| package parameters R_pkg, C_pkg and L_pkg and are used $| if the waveform includes the effects of pin $| inductance/capacitance. The diagram below shows the $| interconnection of these elements. $| $| PACKAGE | TEST FIXTURE $| _________ $| | DUT | L_dut R_dut | L_fixture R_fixture $| | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture $| | | \/ | | | \/ $| |_________| | | $| | | $| C_dut === | === C_fixture $| | | $| | | $| gnd | gnd $| $| Only the R_fixture and V_fixture sub-parameters are $| required, the rest of the sub-parameters are optional. $| If a sub-parameter is not used, its value defaults to $| zero. The sub-parameters must appear in the text after $| the keyword and before the first row of the waveform $| table. $|------------------------------------------------------------------------------ $[Rising waveform] $R_fixture = 500 $V_fixture = 5.0 $C_fixture = 50p $L_fixture = 2n $C_dut = 7p $R_dut = 1m $L_dut = 1n $|Time V(typ) V(min) V(max) $ 0.0ns 0.3 0.5 NA $ 0.5ns 0.3 0.5 NA $ 1.0ns 0.6 0.7 NA $ 1.5ns 0.9 0.9 NA $ 2.0ns 1.5 1.3 NA $ 2.5ns 2.1 1.7 NA $ 3.0ns 3.0 2.7 NA $ 3.5ns 3.2 3.0 NA $| $[Falling waveform] $R_fixture = 50 $V_fixture = 0 $|Time V(typ) V(min) V(max) $ 10.0ns 3.2 3.0 NA $ 10.5ns 3.0 2.7 NA $ 11.0ns 2.1 1.7 NA $ 11.5ns 1.5 1.3 NA $ 12.0ns 0.9 0.9 NA $ 12.5ns 0.6 0.7 NA $ 13.0ns 0.3 0.5 NA $ 13.5ns 0.3 0.5 NA | ------------------------------ end of part 3 --------------------------------- From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:33:36 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07390; Wed, 25 May 94 00:33:36 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DPx-000MO3C; Wed, 25 May 94 00:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:30:21 PST Date: Wed, 25 May 94 00:30:21 PST From: Derrick Duehren Message-Id: <940525003021_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 4 Text item: Text_1 |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor base | its data on typical process data, and then derate by voltage and temperature, | and a proprietary "X%" factor. This methodology also has the nice feature | that the data can be derived either from vendor-proprietary silicon models, or | typical device measurement over temperature/voltage. | $| 1) V/I curves for CMOS devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, max temp deg C, typical process, minus "X%" $| max = hi voltage tol, min temp deg C, typical process, plus "X%" $| $| V/I curves for bipolar devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, min temp deg C, typical process, minus "X%" $| max = hi voltage tol, max temp deg C, typical process, plus "X%" $| $| Nominal, min, and max temperature are specified by the manufacturer $| of the part. The default range is 50C nom, 0C min, and 100C max $| temperatures. $| $| X% should be statistically determined by the silicon vendor based $| on numerous fab lots, test chips, process controls, etc. The value $| of X need not be published in the IBIS file, and may decrease over $| time as data on the I/O buffers and silicon process increases. $| $| Temperatures are junction temperatures. $| | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | For example, a device with a 5 V power supply voltage should be | characterized between (0 - 5) = -5 V and (5 + 5) = 10 V; and a | device with a 3.3 V power supply should be characterized between | (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the pulldown curve. $| $| When tabulating output data for ECL type devices, the voltage points $| must span the range of Vcc to Vcc - 2.2V. This range applies to both the $| pullup and pulldown tables. Note that this range applies ONLY when $| characterizing an ECL output. $| $| These voltage ranges must be spanned by the IBIS data. Data derived $| from lab measurements may not be able to span these ranges as such and $| so may need to be extrapolated to cover the full range. This data must $| not be left for the simulator to provide. | | 3) Ramp Rates: $| The following steps assume that the default load resistance of 50 ohms is $| used. There may be devices that will not drive a load of only 50 ohms $| into any useful level of dynamics. In these cases, use the manufacturer's $| suggested (non-reactive) load and add the load sub parameter to the [Ramp] $| specification. $| $| The ramp rate does not include package and parameters; it is the intrinsic $| output stage rise and fall time only. $| $| The ramp rates (listed in AC characteristics below) should be derived $| as follows: $| $| a. If starting with the silicon model, remove all packaging. If starting $| with a packaged device, perform the measurements as outlined below then $| use whatever techniques are appropriate to derive the actual, unloaded $| rise and fall times. $| $| b. If: The Model_type is one of the following: Output, I/O, or $| 3-state (not open or ECL types); $| Then: Attach a 50 ohm resistor to GND to derive the rising edge $| ramp. Attach a 50 ohm resistor to POWER to derive the $| falling edge ramp. $| $| If: The Model_type is Output_ECL or I/O_ECL; $| Then: Attach a 50 ohm resistor to the termination voltage $| (Vterm = VCC - 2v). Use this load to derive both the $ | rising and falling edges. $| $| If: The Model_type is either an open_sink type or open_drain type; $| Then: Attach either a 50 ohm resistor or the vendor-suggested $| termination resistance to either POWER or the vendor- $| suggested termination voltage. Use this load to derive both $| the rising and falling edges. $| $| If: The Model_type is an open_source type; $| Then: Attach either a 50 ohm resistor or the vendor-suggested $| termination resistance to either GND or the vendor-suggested $| termination voltage. Use this load to derive both the rising $| and falling edges. $| $| c. Due to the resistor, output swings will not make a full transition as $| expected. However the pertinent data can still be collected as $| follows: $| 1) determine the 20% to 80% voltages of the 50 Ohm swing $| 2) measure this voltage change as "dv" $| 3) measure the amount of time required to make this swing "dt" $| d. Post the value as a ratio "dv/dt". The simulation tool vendor $| extrapolates this value to span the required voltage swing range in $| the final model. $| $| e. Typ, Min, and Max must all be posted, and are derived at the same $| extremes as the V/I curves, which are: $| $| Ramp rates for CMOS devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, max temp deg C, typical process, minus "X%" $| max = hi voltage tol, min temp deg C, typical process, plus "X%" $| $| Ramp rates for bipolar devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, min temp deg C, typical process, minus "X%" $| max = hi voltage tol, max temp deg C, typical process, plus "X%" $| $| where nominal, min, and max temp are specified by the manufacturer of $| the part. The preferred range is 50C nom, 0C min, and 100C max $| temperatures. $| $| Note that the derate factor, "Y%", may be different than that used $| for the V/I curve data. This factor is similar to the X% factor $| described above. As in the case of V/I curves, temperatures are $| junction temperatures. $| $| f. During the IV measurements, the driving waveform should have a $| rise/fall time fast enough to avoid thermal feedback. The specific $| choice of sweep time is left to the modeling engineer. $| | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. | $-----------------------------------cut here ----------------------------------- |============================================================================== NOTES ON IBIS_CHK PROGRAM (not to be left in the actual specification) $The V/I table DATA SHOULD BE MONOTONIC to insure that most simulators provide $stable simulations. Monotonic data is needed to insure that all data is $single valued. MONOTONIC DATA IS NOT REQUIRED to provide a valid IBIS model. $It is recognized that automated measurement equipment may be used to acquire $this data and as such may include "noise" that causes the data to be non- $monotonic. It is also recognized that some devices may be non-monotonic in $certain regions. Therefore the IBIS specification allows non-monotonic data. $Simulation tools should filter out non-monotonic data if such data causes $instabilities in the simulation results. The IBIS_CHK program tests for non- $monotonic data and provides a maximum of one note per V/I table if non- $montonic data is found. $ $ "NOTE: Line xxx of V/I table yyy for model zzz is non-monotonic! $ Most simulators will filter this data to remove the non-monotonic data." $ $ Where xxx is the line number in the IBIS file. $ Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. $ Where zzz is the name of the model. $ $*************************************************************************** $Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. $*************************************************************************** $For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, $GND_clamp $ $ 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. $ $ 2) IF:The current in the TYPICAL column corresponding to Vmax is less than $ the current in the TYPICAL column corresponding to Vmin than $ the table is assumed to have decreasing current. $ ELSE IF:The current in the TYPICAL column corresponding to Vmax $ is greater than the current in the TYPICAL column corresponding to $ Vmin than the table is assumed to have increasing current. $ ELSE: The table is assumed to have equal current." $ $ Note: This works for all cases of discontinuities unless the magnitude of $ discontinuity is such that this model is in all probability $ completely unrealistic. $ $*************************************************************************** $Change 3- Add a header comment statement at the TOP of the IBIS_CHK program $ to insure that new changes to the IBIS_CHK program do not break tests $ that worked in old MAJOR versions. This approach makes the program $ larger however it insures the parser always works the same on older $ versions of IBIS. This approach uses more memory, but has the reward $ of low maintaining costs. The IBIS_CHK program is very small and $ would not be effected by this until many revisions have occurred. $*************************************************************************** $NOTICE TO ANY PERSON MODIFING THIS PROGRAM! $------------------------------------------- $This program SHALL NOT BE MODIFIED unless there is an associated IBIS Buffer $Issue Resolution Document (BIRD). Said BIRD shall be agreed upon by IBIS $committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is $allowed to modify the source code. The present CZAR is Jon Powell (April $1994). The IBIS committee may also hire programmers from time to time to make $major changes to the source code. $ $Note: Source licensees are free to modify their own copies of this source $code in any way they choose. Source licensees shall not redistribute $the source code modified or otherwise. Source licensing is available from the $IBIS open forum. The IBIS open forum is non-profit. $ $The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED $when adding code for the next version of the IBIS specification. Instead $completely new code for all functions and features shall be created. This $may require duplication of numerous functions. $ $Each function shall be preceded by VXX_ where XX is the MAJOR version $of the IBIS specification which is being parsed and tested. A MAJOR version $would for example be 1.x going to 2.x. A MINOR version would for example be $1.1 to 1.2. Functions using the above syntax would look as follows: $V01_GetValue $ $MINOR revisions DO NOT required new code. $ $Startup code shall be provided at the top of the program that reads the $version number from the IBIS file and runs the portion of the program $corresponding to that MAJOR version. Code that is used only by the program $startup function is not duplicated. $ $-----------------------------------cut here ---------------------------------- $|============================================================================= $| PACKAGE MODELING $| The [Package_Model] keyword is used within a [Component] to indicate $| which package model should be used for that part. $| $| The resolved specification permits .ibs files to contain [Define $| Package Model] keywords as well. These are described in $| "SYNTAX FOR THE .PKG FILE", below. 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. $| $|============================================================================== $| Keyword: [Package Model] Package_Model_Name $| Required: No $| Description: Indicates the name of the package model $| Usage Rules: The Package_Model_Name is limited to 40 characters. $| Spaces are allowed in the name. The name should include the $| company name or initials to help ensure uniqueness. If the $| package model is in a separate .pkg file, it must be kept in $| the same directory as the .ibs file. $| Other Notes: Use the [Package_Model] keyword within a [Component] to $| indicate which package model should be used for that part. $| The specification permits .ibs files to contain [Define $| Package Model] keywords as well. These are described $| in the "package modeling" section below. When package model $| definitions occur within an .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. $| $| SYNTAX FOR THE .PKG FILE $| $| Package models are stored in a file whose name looks like .pkg. $| $| The provided must adhere to MS-DOS file name conventions: it must $| not exceed 8 characters in length. All of these characters must be lower $| case. The extension ".pkg" is used to identify files containing package $| models. $| $| The .pkg file must contain all of the Required elements of a normal .ibs $| file, including [IBIS Ver], [File Name], [File Rev], and the [End] keywords. $| $| Optional elements include the [Date], [Source], [Notes], [Disclaimer], $| and [Comment char] keywords. $| $| All of the above elements follow the exact same rules as those for a normal $| .ibs file. $| $| The [Component] and [Model] keywords are FORBIDDEN in the .pkg file. The $| .pkg file is only for package models. $| $|============================================================================== $| Keyword: [Define Package Model] $| Required: Yes $| Description: Mark 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 and blank characters are $| allowed. $|------------------------------------------------------------------------------ $[Define Package Model] Package_Model_Name $|============================================================================== $| $|============================================================================== $| Keyword: [Manufacturer] $| Required: Yes $| Description: Declares the manufacturer of the part(s) that use this package $| model. $| Usage Rules: The length of the Manufacturer's name must not exceed 40 $| characters (blank characters are allowed, e.g., Texas $| Instruments). In addition, each manufacturer must use a $| consistent name in all .ibs files. $|------------------------------------------------------------------------------ $[Manufacturer] Manufacturer's Name | e.g., Intel Corp. $| $|============================================================================== $| Keyword: [OEM] $| Required: Yes $| Description: Declares the manufacturer of the package. $| Usage Rules: The length of the Manufacturer's name must not exceed 40 $| characters (blank characters are allowed, e.g., Texas $| Instruments). In addition, each manufacturer must use a $| consistent name in all .ibs files. $| Other Notes: This keyword is useful if the semiconductor vendor sells a $| single IC in packages from different manufacturers (e.g. AMP, $| Kyocera). $|------------------------------------------------------------------------------ $[OEM] Pkgs_R_Us Inc. $|============================================================================== $| $ $The [Description] keyword is used to indicate to a human being what $the model is describing. $| $|============================================================================== $| Keyword: [Description] $| Required: Yes $| Description: Provides a concise yet easily human-readable description of $| what kind of package the [Package_Model] is representing. $| Usage Rules: The description must be less than 60 characters in length, $| must fit on a single line, and may contain spaces. $|------------------------------------------------------------------------------ $[Description] 220-Pin Quad Ceramic Flat Pack $| $|============================================================================== $| Keyword: [Number of Pins] $| Required: Yes $| Description: Tells the parser how many pins to expect. $| Usage Rules: The value must be a positive integer less than 60 $| characters long. $|------------------------------------------------------------------------------ $[Number of Pins] 128 $| $|============================================================================== $| Keyword: [Pin Names] $| Required: Yes $| Description: Tells the parser the set of names that are used for the package $| pins, and to defines an ordering of them. The first pin name $| given is the "lowest" pin, and the last pin given is the $| "highest." The pin names can not exceed 5 characters in $| length. $| Usage Rules: Following the [Pin Names] field, the names of the pins are $| listed. There must be as many names listed as there are $| pins (as given by the preceding [Number of Pins].) $|------------------------------------------------------------------------------ $[Pin Names] $A1 $A2 $| . $| . $| . $A22 $B1 $| . $| . $| . $| etc. $| $|============================================================================== $| Keyword: [Model Data] $| Required: Yes $| Description: Indicates the beginning of the formatted model data. $|------------------------------------------------------------------------------ $[Model Data] $| ------------------------------ end of part 4 ------------------------------ From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:33:47 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07395; Wed, 25 May 94 00:33:47 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DQ8-000MOBC; Wed, 25 May 94 00:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:30:32 PST Date: Wed, 25 May 94 00:30:32 PST From: Derrick Duehren Message-Id: <940525003032_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 5 of 5 Text item: Text_1 $|============================================================================== $| Keyword: [End Model Data] $| Required: Yes $| Description: Indicates the end of the formatted model data. $| Other Notes: In between the [Model Data] and [End Model Data] keywords is $| the package model data itself. The data is a set of 3 $| matrices: the resistance (R), inductance (L), and capacitance $| (C) matrices. Each matrix can be formatted differently (see $| below). Use one of the matrix keywords below to mark the $| beginning of each new matrix. $|------------------------------------------------------------------------------ $[End Model Data] $| $|============================================================================== $| Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] $| Required: [Resistance Matrix] is optional. If it's not present, its $| entries are assumed to be zero. [Inductance Matrix] and $| [Capacitance Matrix] are required. $| Description: These keywords mark the beginning of a matrix, and $| specify how the matrix data is formatted. $| Usage Rules: There are 3 choices for the Format_Keyword: $| Banded Matrix, Sparse Matrix, and Full Matrix. $| $| After each of these keywords, the matrix data follows in the $| appropriate format. $| $| These formats are described in detail below. $|------------------------------------------------------------------------------ $[Resistance Matrix] Format_Keyword $[Inductance Matrix] Format_Keyword $[Capacitance Matrix] Format_Keyword $| $|============================================================================== $| For each [Resistance Matrix], [Inductance Matrix], or [Capacitance $| Matrix] a different format can be used for the data. The choice of $| formats is provided to satisfy different simulation accuracy and speed $| requirements. Also, there are many packages in which the resistance $| matrix can have no coupling terms at all. In this case, the most $| concise format (Banded_Matrix) can be used. $| $| One common aspect of all the different formats is that they exploit $| the symmetry of the matrices they describe. This means that the $| entries below the main diagonal of the matrix are identical to the $| corresponding entries above the main diagonal. Therefore, only $| roughly one-half of the matrix needs to be described. By convention, $| the main diagonal and the UPPER half of the matrix are provided. $| $| In the following text, we use the notation [I, J] to refer to the entry in $| row I and column J of the matrix. Note that I and J are allowed to be $| alphanumeric strings as well as integers. An ordering of these $| strings has been defined earlier in the [Pin Names] section. The following $| text sometimes refers to "Row 1", which 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 metrix "suffix" $| notation. Thus, an entry of the C matrix could be given as "1.23e-12" or as $| "1.23p" or "1.23pF". $| $| 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." Again let the matrix size be N, and let the bandwidth $| be B. An entry [I,J] of the matrix is zero if: $| $| | I - J | > B $| $| where |.| denotes the absolute value. $| $|The bandwidth for a Banded_Matrix must be specified using the [Bandwidth] $|keyword: $| $|============================================================================== $| Keyword: [Bandwidth] $| Required: Yes (for banded matrices only) $| Description: Indicates the bandwidth of the matrix. The BW field below $| must be a nonnegative integer. This keyword occurs after the $| [Resistance Matrix], etc. keyword, and BEFORE the matrix data $| is given. $| Usage Rules: $|------------------------------------------------------------------------------ $[Bandwidth] 10 $| $|============================================================================== $| The banded matrix is specified one row at a time, starting with row 1 and $| working up to higher rows. Each row is marked with the [Row] keyword, as $| above. As before, symmetry is exploited: entries below the main diagonal are $| never given. $| $| The first row only needs to specify the entries [1,1] through [1,1+B] since $| any other entries are guaranteed to be zero. The second row will need to $| specify the entries [2,2] through [2, 2+B], and so on. In general, for row M $| the entries [M,M] through [M,M+B] are given. $| $| Unlike the Full_Matrix, each successive row will typically have the same $| number of entries, except for the last few rows. When M + B finally exceeds $| the size of the matrix N, then the number of entries in each row starts to $| decrease; the last row (row N) has only 1 entry. $| $| As in the Full_Matrix (below), if all the entries for a particular row does $| 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. $| $| 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: Indicate the beginning of a new row of the matrix. The $| Row_Number field must be a pin name, $| Usage Rules: $|------------------------------------------------------------------------------ $[Row] 3 $| $|============================================================================== $| Following a [Row] keyword is a block of numbers that represent the $| entries for that row. Suppose that the current row is number M. Then $| the first number listed is the diagonal entry, [M,M]. Following this $| number are the entries of the upper half of the matrix that belong to row M: $| [M, M+1], [M, M+2], ... up to [M,N]. $| $| For even a modest-sized package, this data will not all fit on one line. $| Since each line of an IBIS file must be 80 characters long or less, it is $| permissible to break the data up with new lines 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. $| $| 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 (PGA's.) $| $| 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 $| $| Please 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 Names] section is observed. $| $| Also, please note that it is again necessarily the case that the N'th $| row of an N x N matrix has just a single entry (the diagonal entry.) $| $| An Example $| $| The following is an example of a package model file following the $| above specifications. For the sake of brevity, an 8-pin package has $| been described. For purposes of illustration, each of the matrices is $| specified using a different format. $| $|============================================================================== $| $[IBIS Ver] 2.0 $[File Name] example.pkg $[File Rev] 0.1 $[Date] April, 17 1994 $[Source] fervid imaginings $[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. $ Read at your own risk. See your dentist regularly. $| $|============================================================================== $| $[Define Package Model] Bozo-SMT-cer-8-pin-pkgs $[Manufacturer] Bozonics Semiconductors Ltd. $[OEM] Pkgs_R_Us $[Description] 8-Pin ceramic SMT package $[Number of Pins] 8 $| $[Pin Names] $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 $| $| All done! $| $[End Model Data] $[End] $|============================================================================== ------------------------------ end of Rev2_0.txt ------------------------------- From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:34:20 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07400; Wed, 25 May 94 00:34:20 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DQf-000MO3C; Wed, 25 May 94 00:31 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:31:05 PST Date: Wed, 25 May 94 00:31:05 PST From: Derrick Duehren Message-Id: <940525003105_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 5/20/94 Meeting Minutes Text item: Text_1 Date: May 24, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Editing Committee Meeting 5/20/94 Attendees: Cadence Design C. Kumar HyperLynx Kellee Crisafulli Intel Corporation Stephen Peters, Will Hobbs, Derrick Duehren (editor) Interconnectix, Inc. Bob Ross Quad Design Jon Powell NOTE: "AR" = Action Required. ------------------------------------------------------------------------ 5/20/94 Meeting Proposed Agenda ------------------------------- 8:00 Greetings 8:15 Bob Ross's roll-up (Presentation) 8:30 Page-by-page review of roll-up (in teams) 11:30 Pending BIRDs discussion Noon Lunch / Levels-of-support discussion 1:00 Conference call open forum (Vote on BIRDs) 2:00 Format/spec. outline discussion (new sections?) - Package model (within / without) - IBIS Check program, how to spec. - Context diagrams in the spec.? 2:30 Continue page-by-page review 4:00 Statement of Intent review/rewrite 4:30 Wrap up - Assign ARs (including who does final draft/post to reflector) 1. Greetings While waiting for everyone to arrive, Will Hobbs described Intel's plan for providing Pentium(TM) processor IBIS models. Discussion flowed into flight times and ramp times. 2. Bob Ross's Roll-up (Presentation) Bob briefly introduced his roll up, which was then used as a basis for the editing process. 3. Page-by-page review of roll-up The group reviewed Bob's roll-up page-by-page, noting changes on a master copy. All changes from V1.1 are marked in the Word for Windows edit file REV2_0.DOC, which Derrick is maintaining. 4. Pending BIRDs discussion Discussed as part of page-by-page review. 6. Conference call open forum (Vote on BIRDs) Bob ward, John Kiefer, Arpad joined the editing committee on the phone. BIRD 13.2 was discussed and approved unanimously. BIRD 14.1 was split into two issues: 1) First part Specifications Section [Pin Extension 1]. Model_type sub-parameter removed. Vtest changed to Vmeas. This BIRD is to be reissued as BIRD 16 and entered into REV2_0.DOC as pending approval at the 5/27 meeting. 2) Second (additional sub-parameters to the Model keyword). This portion of BIRD 14 (as BIRD 14.3) was approved unanimously. BIRD 5.4, Pin Mapping, was approved unanimously. BIRD 15. A long discussion ensued, mostly between Jon Powell and Arpad. Data derivation, combining data, measurement anomalies, decomposing data into data/ V/I curves,... should we provide measured or simulated data? Agreement reached: Chop out all but last paragraph of BIRD 15: Since in the case of a non 3-statable buffer this difference curve cannot be generated through lab measurements (because the clamping curves can not be measured alone), the pullup and pulldown curves of an IBIS model may contain the sum of the clamping characteristics and the output structure. In this case the clamping curves must contain all zeroes, or the keywords must be omitted. Tri-stateable parts: Keep 15 as is - sorta. This affects the non-monotonic approved BIRD. Add note to it (regarding the Golden Parser Warning/Note). Resolution was not clear. x. Levels-of-support discussion Decided not to do levels of support at this time. 8. Continue page-by-page review The group completed the review of Bob's roll-up. AR: Derrick and Stephen to edit, clean up, and post the draft to vhdl.org. [DONE] 7. Format/spec. outline discussion (new sections?) Discussed as part of page-by-page review. - Package model (within / without) Within. - IBIS Check program, how to spec. Not discussed. - Context diagrams in the spec.? Yes, as needed. 9. Statement of Intent review/rewrite Started, not finished. 10. Wrap up Derrick will chair the 5/27 meeting, as Will Hobbs will be traveling. The main focus will be discussion of the draft Rev 2.0 document. Bridge (415) 904-8800 #744468, 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:43:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07453; Wed, 25 May 94 00:43:18 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DZL-000MO3C; Wed, 25 May 94 00:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:40:03 PST Date: Wed, 25 May 94 00:40:03 PST From: Derrick Duehren Message-Id: <940525004003_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 5/27/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 5/27/94 Bridge: Res: (415) 904-8800 744468 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. NOTE: Derrick Duehren will be Chairing the meeting in Will Hobb's absence. 8:00 Check-in Intros of new IBIS participants Duehren Review of previous meeting's minutes Duehren Miscellany/Announcements Duehren Opens for new issues All New models available All IBIS Cookbook Rosenbaum 8:30 IBIS 2.0 Ratification/DAC/Other 2.0 Issues Derrick - May 20 Editing meeting - Report - Rev 2.0 Ratification Summit Rev 2.0 Review/Discussion/Approval of pending sections All BIRD 14/16, New section for [Model] sub-parameters Keifer BIRD 15, Clarification on usage of the V/I tables Arpad 9:55 Wrap-up, Next Meeting Plans Duehren From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:53:26 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07536; Wed, 25 May 94 00:53:26 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DjA-000MO3C; Wed, 25 May 94 00:50 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:50:11 PST Date: Wed, 25 May 94 00:50:11 PST From: Derrick Duehren Message-Id: <940525005011_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Rev2_0 posted to vhdl.org Text item: Text_1 In case my 5-part mailing didn't work well for you, I have posted the draft IBIS Spec Rev2_0 to vhdl.org. It is in \pub\ibis\ver2.0\rev2_0.x01 - Derrick Duehren Intel From randyh Wed May 25 18:42:49 1994 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18259; Wed, 25 May 94 18:42:49 PDT Date: Wed, 25 May 94 18:42:49 PDT From: randyh (Randy Harr) Message-Id: <9405260142.AA18259@vhdl.vhdl.org> To: ibis@vhdl.org Subject: IBIS reflector My apologies to all. I added a new name to the IBIS list on 18 May which prevented anyone except the new names added from receiving mail. Worse yet, a UNIX sendmail bug did not report this error and just dropped everyone else off the list. Therefore email seemed to be going into a black hole for most people. I will retrieve all the messages sent since 18 May (from the email.archive file online) and resend them to the reflector. You should be fully back in operation now. And to think I thought everyone was being silent! Randy Harr, SYSOP, IBIS list randyh@vhdl.org randyh@synopsys.com From randyh Wed May 25 18:47:42 1994 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18307; Wed, 25 May 94 18:47:42 PDT Date: Wed, 25 May 94 18:47:42 PDT From: randyh (Randy Harr) Message-Id: <9405260147.AA18307@vhdl.vhdl.org> To: ibis Subject: Missing mail since 18 May From Derrick_Duehren@ccm2.jf.intel.com Wed May 18 13:06:58 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19572; Wed, 18 May 94 13:06:58 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q3rqU-000MNpC; Wed, 18 May 94 13:04 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 18 May 94 13:04:01 PST Date: Wed, 18 May 94 13:04:01 PST From: Derrick Duehren Message-Id: <940518130401_6@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 5/20 Teleconference Meeting Text item: Text_1 IBIS Meeting 5/20/94, 1:00 pm PDT Bridge: Res: (916) 356-9999 315842 Agenda ------ 1:00 Role call 1:10 BIRD 13 discuss and vote 1:20 BIRD 14 discuss and vote 1:30 BIRD 15 discuss and vote 1:40 Discuss and vote on any editing committee issues 1:50 Wrap up Editing Committee ----------------- Kumar, Cadence Kellee Crisafulli, HyperLynx Will Hobbs, Stephen Peters, and Derrick Duehren (admin.), Intel Bob Ross, Interconnectix Ravender Goyal, Mentor Graphics Syed Huq, National Semiconductor Jon Powell, Quad Design From John_M_Keifer@ccm.fm.intel.com Wed May 18 16:05:52 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20749; Wed, 18 May 94 16:05:52 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q3udc-000MNdC; Wed, 18 May 94 16:02 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 18 May 94 16:02:56 PST Date: Wed, 18 May 94 16:02:56 PST From: John M Keifer Message-Id: <940518160256_5@ccm.hf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS14.1 Text item: Text_1 To: IBIS Committee Here is the updated BIRD14 with the suggested fixes. This includes Model_type, Rref, and Vref being added to the [SPECS] section, Rref and Vref being optionally added to all model files, and Vt being changed to Vtest to be clearer on the meaning. I have asked around and to my knowledge everyone agrees with these changes and with this updated BIRD. If anyone has any further problems with this BIRD, please put them on the reflector and let me know. Note: No defaults were added for backcompatability. This means that with this BIRD, if an old IBIS Model is used that doesn't have the parameters of this BIRD, the parameter is ignored (i.e. there is no official default configuration for the simulator, and the Model is treated just like it is presently with IBIS Version 1.1). The user has the choice to either use an old Model as it is, obtain a new Model from their vendor, or obtain the needed data book and edit(upgrade) the Model themselves. John Keifer ************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.1 ISSUE TITLE: Adding a new section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: May 18, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. It is also desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [SPECS], is added to the .IBS file. The keyword [SPECS] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [SPECS] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vtest (a test voltage), are added to a [Model]. These sub-parameters are also optional. |************************************************************************* | | Keyword: [SPECS] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vtest, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [SPECS] section consists of five characters for a | pin number, ten for Model_type, six for Vinl, six for | Vinh, five for Vtest, five for Rref, five for Vref, five | for Cref, and six for each of the three sub-parameters | in C_comp. These three sub-parameters represent the | following: typ, min, and max. All sub-parameters must | be separated by at least one blank space. This comes | to a total of seventy-five characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [SPECS] | C_comp Pin Model_type Vinl Vinh Vtest Rref Vref Cref typ min max 1 NA 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA NA 2.5V NA NA 30pF NA NA NA 9 NA 1.5V 3.5V NA NA NA NA NA NA NA 12 I/O NA NA NA NA NA NA NA NA NA 13 NA NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vtest, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vtest is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vtest=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vtest, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Vtest, Rref, Vref, and Cref and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overridden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Vtest, Rref, Vref, and Cref is standard data available in data books. Allowing the specification of Vtest, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* From Don_A_Telian@ccm.fm.intel.com Thu May 19 10:03:06 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00184; Thu, 19 May 94 10:03:06 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q4BRz-000MNpC; Thu, 19 May 94 10:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 19 May 94 10:00:03 PST Date: Thu, 19 May 94 10:00:03 PST From: Don A Telian Message-Id: <940519100003_1@ccm.hf.intel.com> To: John_M_Keifer@ccm.fm.intel.com, Arpad_Muranyi@ccm.fm.intel.com, Will_Hobbs@ccm2.jf.intel.com, ibis@vhdl.org Subject: BIRD 14.1, Updated from John Keifer Text item: Text_1 To: IBIS Committee Here is the updated BIRD14 with the suggested fixes. This includes Model_type, Rref, and Vref being added to the [SPECS] section, Rref and Vref being optionally added to all model files, and Vt being changed to Vtest to be clearer on the meaning. I have asked around and to my knowledge everyone agrees with these changes and with this updated BIRD. If anyone has any further problems with this BIRD, please put them on the reflector and let me know. Note: No defaults were added for backcompatability. This means that with this BIRD, if an old IBIS Model is used that doesn't have the parameters of this BIRD, the parameter is ignored (i.e. there is no official default configuration for the simulator, and the Model is treated just like it is presently with IBIS Version 1.1). The user has the choice to either use an old Model as it is, obtain a new Model from their vendor, or obtain the needed data book and edit(upgrade) the Model themselves. John Keifer ************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.1 ISSUE TITLE: Adding a new section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: May 18, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. It is also desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [SPECS], is added to the .IBS file. The keyword [SPECS] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [SPECS] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vtest (a test voltage), are added to a [Model]. These sub-parameters are also optional. |************************************************************************* | | Keyword: [SPECS] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vtest, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [SPECS] section consists of five characters for a | pin number, ten for Model_type, six for Vinl, six for | Vinh, five for Vtest, five for Rref, five for Vref, five | for Cref, and six for each of the three sub-parameters | in C_comp. These three sub-parameters represent the | following: typ, min, and max. All sub-parameters must | be separated by at least one blank space. This comes | to a total of seventy-five characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [SPECS] | C_comp Pin Model_type Vinl Vinh Vtest Rref Vref Cref typ min max 1 NA 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA NA 2.5V NA NA 30pF NA NA NA 9 NA 1.5V 3.5V NA NA NA NA NA NA NA 12 I/O NA NA NA NA NA NA NA NA NA 13 NA NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vtest, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vtest is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vtest=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vtest, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Vtest, Rref, Vref, and Cref and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overridden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Vtest, Rref, Vref, and Cref is standard data available in data books. Allowing the specification of Vtest, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* From Derrick_Duehren@ccm2.jf.intel.com Thu May 19 20:43:01 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05118; Thu, 19 May 94 20:43:01 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q4LRJ-000MNOC; Thu, 19 May 94 20:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 19 May 94 20:40:01 PST Date: Thu, 19 May 94 20:40:01 PST From: Derrick Duehren Message-Id: <940519204001_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: BIRD 14.1 Text item: Text Item To: IBIS Committee Here is the updated BIRD14 with the suggested fixes. This includes Model_type, Rref, and Vref being added to the [SPECS] section, Rref and Vref being optionally added to all model files, and Vt being changed to Vtest to be clearer on the meaning. I have asked around and to my knowledge everyone agrees with these changes and with this updated BIRD. If anyone has any further problems with this BIRD, please put them on the reflector and let me know. Note: No defaults were added for backcompatability. This means that with this BIRD, if an old IBIS Model is used that doesn't have the parameters of this BIRD, the parameter is ignored (i.e. there is no official default configuration for the simulator, and the Model is treated just like it is presently with IBIS Version 1.1). The user has the choice to either use an old Model as it is, obtain a new Model from their vendor, or obtain the needed data book and edit(upgrade) the Model themselves. John Keifer ************************************************************************* ************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.1 ISSUE TITLE: Adding a new section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: April 26, 1994 DATE REVISED: May 18, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. It is also desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [SPECS], is added to the .IBS file. The keyword [SPECS] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [SPECS] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vtest (a test voltage), are added to a [Model]. These sub-parameters are also optional. |************************************************************************* | | Keyword: [SPECS] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vtest, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [SPECS] section consists of five characters for a | pin number, ten for Model_type, six for Vinl, six for | Vinh, five for Vtest, five for Rref, five for Vref, five | for Cref, and six for each of the three sub-parameters | in C_comp. These three sub-parameters represent the | following: typ, min, and max. All sub-parameters must | be separated by at least one blank space. This comes | to a total of seventy-five characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [SPECS] | C_comp Pin Model_type Vinl Vinh Vtest Rref Vref Cref typ min max 1 NA 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA NA 2.5V NA NA 30pF NA NA NA 9 NA 1.5V 3.5V NA NA NA NA NA NA NA 12 I/O NA NA NA NA NA NA NA NA NA 13 NA NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vtest, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vtest is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vtest=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vtest, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [SPECS] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [SPECS] section. This feature will reduce the size of the .IBS file. The [SPECS] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [SPECS] keyword is also optional and hence fully backward compatible. The keywords Vtest, Rref, Vref, and Cref and all other sub-parameters of a [Model] are to be used as default values only. All sub-parameters in a [Model] are overridden by any values listed in the [SPECS] section. All of the data in the [SPECS] section, Vtest, Rref, Vref, and Cref is standard data available in data books. Allowing the specification of Vtest, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:03:35 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06918; Wed, 25 May 94 00:03:35 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6Cwu-000MOBC; Wed, 25 May 94 00:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:00:20 PST Date: Wed, 25 May 94 00:00:20 PST From: Derrick Duehren Message-Id: <940525000020_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, Part 1 Text item: Text_1 Key to right-most column revision marks: ## = Editor Comments $ = Change from Version 1.1 Post comments to the IBIS reflector. We will discuss this draft at the 5/27/94 IBIS teleconference. The bridge number is (415) 904-8800 #744468, 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). - Derrick Duehren (Derrick_Duehren@ccm.jf.intel.com) ----------------------------------- Cut Here ---------------------------------- |============================================================================== | I/O Buffer Information Specification (IBIS) Version 2.x1 [DRAFT 5/24/94] |============================================================================== | | Statement of Intent: | | In order to enable an industry standard method to electronically transport | IBIS Modeling Data between silicon vendors, simulation software vendors, and | end customers, this template is proposed. The intention of this template is | to specify a consistent format that can be parsed by software, allowing each | simulation vendor to derive models compatible with their own product. | | One goal of this template is to represent the current state of IBIS data, | while allowing a growth path to more complex models / methods (when deemed | appropriate). This would be accomplished by a revision of the base | template, and possibly the addition of new keywords or categories. | | Another goal of this template is to ensure that it is simple enough for | silicon vendors and customers to use and modify, while ensuring that it is | rigid enough for software simulation vendors to write reliable parsers. | | Finally, this template is meant to contain a complete description of the I/O | elements on an entire component. Consequently, several models will need to | be defined in each file, as well as a table that equates the appropriate | buffer to the correct pin and signal name. | | Version 1.1 of this electronic template was finalized by an industry-wide | group of simulation experts representing various companies and interests. | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | ASCII file format. It represents the minimum amount of I/O buffer | information required to create an accurate IBIS model of common CMOS and | bipolar I/O structures. Future revisions of the ASCII file will add items | considered to be "enhancements" to Version 1.0 to allow accurate modeling | of new, or other, I/O buffer structures. Consequently, all future | revisions will be considered super sets of Version 1.0, allowing backward | compatibility. In addition, as modeling platforms develop support for | revisions of the IBIS ASCII template, all previous revisions of the | template must also be supported. | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | comments have been added for further clarification. | $| Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility $| with Versions 1.0 and 1.1. A complete list of changes to the specification $| is in the IBIS Version 2.0 Release Notes document ("ver2_0.rn"). $| |============================================================================== | $| General syntax rules and guidelines for ASCII IBIS files: | $| 1) The content of the files is case sensitive, except for reserved $| words, parameters, sub-parameters, and keywords. Reserved words and $| keywords are not case sensitive, and file names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no connect pins, | NA - used where data not available. | $| 3) File names used in the file must only have lower case characters to | enhance UNIX compatibility and must conform to DOS rules. (The length of | a file name should not exceed eight plus three characters and it must | not contain special characters which are illegal in DOS). | | 4) The file must have no more than 80 characters per line. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment char] to any other character. The [Comment char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | $| 7) Underscores and spaces are equivalent in keywords. Spaces are not $| allowed in sub-parameter names. | | 8) Valid scaling factors are: $| T = tera k = kilo n = nano $| G = giga m = milli p = pico $| M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, and Henries.) The | parser looks at only one alphabetic character after a numerical entry, | therefore it is enough to use only the prefixes to scale the parameters. | However, for clarity, it is allowed to use full abbreviations for the | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | allowed (e.g., 1.2345e-12). | | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) Currents are considered positive when their direction is into the | component. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |------------------------------------------------------------------------------ $[IBIS Ver] 2.0 | Used for template variations |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment char] keyword. The following | characters can NOT be used: A B C D E F G H I J K L M N O P | Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u $| v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + - | Other Notes: The [Comment char] keyword can be used throughout the file, as | desired. |------------------------------------------------------------------------------ [Comment char] |_char |============================================================================== | Keyword: [File name] | Required: Yes | Description: Specifies the name of the IBIS file, "filename.ibs". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ibs". |------------------------------------------------------------------------------ $[File name] ver2_0.ibs |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely |------------------------------------------------------------------------------ [File Rev] 1.0 | Used for .ibs file variations |============================================================================== $| Keywords: [Date] [Source] [Notes] [Disclaimer] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: The [Date] information is allowed to contain blanks, and be of $| any format up to 40 characters. $| $| Because IBIS model writers may consider the information in $| these keywords essential to users, and sometimes legally $| required, design automation tools should make this information $| available. Derivative models should include this text $| verbatim. Any text following the [Copyright] keyword must be $| included in any derivative models verbatim. |------------------------------------------------------------------------------ $[Date] 06/09/94 | The latest file revision date | [Source] Put originator and the source of information here. For example: From silicon level SPICE model at Intel. From lab measurement at IEI. Compiled from manufacturer's data book at Quad Design, etc... | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | $[Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the Component Name must not exceed 40 characters, | and blank characters are allowed. |------------------------------------------------------------------------------ $[Component] Component Name | e.g., 7403398 MC452 $| |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies the component's manufacturer. | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Manufacturer's Name | e.g., Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines a range of values for the default packaging resistance, | inductance, and capacitance of the component pins. | Sub-Params: R_pkg, L_pkg, C_pkg | Usage Rules: The typical (typ) column must be specified. If data for the | other columns are not available, they must be noted with "NA". | Other Notes: If RLC parameters are available for individual pins, they can | be listed in columns 4-6 under keyword [Pin]. The values | listed in the [Pin] description section override the default $| values defined here. Use the [Package Model] keyword for more $| complex package descriptions. If defined, the [Package Model] $| data overrides the values in the [Package] keyword. $| Regardless, the data listed under the [Package] keyword must $| still be valid. |------------------------------------------------------------------------------ [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF |============================================================================== | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pins and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, associates the I/O model for that | pin. Each model_name must have a [Model] keyword below, | unless it is a reserved model name (POWER, GND, or NC). | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |------------------------------------------------------------------------------ [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF |============================================================================== ################################################################################ ## PENDING BIRD14.1 ADDITION FOR VERSION 2.0 ## $|============================================================================== $| Keyword: [Pin Extension 1] $| Required: Optional $|Description: These data are an extension to the [Pin] keyword. $| Associates additional component specifications for the $| various external pins. $| Sub-Params: Vinl, Vinh, Vmeas, Rref, Vref, Cref, C_comp $|Usage Rules: Only pins that have values different from the default $| values specified in the [Model] sub-parameters should be $| listed. Sub-parameters not used on a line must be $| filled in with NA. All sub-parameters must be separated $| by at least one blank space. Use this keyword to avoid $| duplicating models due to minor differences in pin $| specifications. The definitions of Rref, Vref, Cref and $| C_comp are found under the [Model] keyword. $| Column length limits are: $| Pin 5 characters max $| Vinl 6 characters max $| Vinh 6 characters max $| Vmeas 5 characters max $| Rref 5 characters max $| Vref 5 characters max $| Cref 5 characters max $| C_comp 6 characters max each for "typ", "min", and "max" $|------------------------------------------------------------------------------ $[Pin Extension 1] $| C_comp $| ------------------- $Pin Vinl Vinh Vmeas Rref Vref Cref typ min max $1 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF $4 NA NA 2.5V NA NA 30pF NA NA NA $9 1.5V 3.5V NA NA NA NA NA NA NA $12 NA NA NA NA NA NA NA NA NA $13 NA NA NA 50 5V NA NA NA NA $| $|##################### END OF PENDING BIRD 14.2 ############################### $|============================================================================== $| Keyword: [Package Model] Package_Model_Name $| Required: No $| Description: Indicates the name of the package model $| Usage Rules: The Package_Model_Name is limited to 40 characters. $| Spaces are allowed in the name. The name should include the $| company name or initials to help ensure uniqueness. If the $| package model is in a separate .pkg file, it must be kept in $| the same directory as the .ibs file. $| Other Notes: Use the [Package_Model] keyword within a [Component] to $| indicate which package model should be used for that part. $| The specification permits .ibs files to contain [Define $| Package Model] keywords as well. These are described $| in the "package modeling" section below. When package model $| definitions occur within an .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. $| $| NOTES ON PACKAGE MODELS AND SEPERATE FILES $| $| Keywords for [Define Package Model] through [End Model Data] are $| defined in the "package modeling" section of this specification. Note that $| the actual package models can be in a separate file .pkg. $| or may also exist in the IBIS files between the [Define Package Model]...[End $| Model Data] keywords for each package model that is defined. For reference, $| these keywords are shown below. Refer to the "package modeling" section $| of this specification for full descriptions, syntax and usage. Simulators $| that do not support these keywords will ignore all entries between the $| [Define Package Model] and [End Model Data] keywords. $| $| [Define Package Model] $| [Manufacturer] $| [OEM] $| [Description] $| [Number of Pins] $| [Pin Names] $| [Model Data] $| [Resistance Matrix] $| [Inductance Matrix] $| [Capacitance Matrix] $| [Row] $| [Bandwidth] $| [End Model Data] $| ---------------------------------- end of part one ---------------------------- From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:03:49 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06923; Wed, 25 May 94 00:03:49 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6Cx9-000MOBC; Wed, 25 May 94 00:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:00:35 PST Date: Wed, 25 May 94 00:00:35 PST From: Derrick Duehren Message-Id: <940525000035_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 2 Text item: Text_1 ## DOES THIS BELONG HERE (FROM BOB'S BIRD 10.1x)? ############################ ## When measuring the entries of the RLC matrices, either with laboratory ## equipment or field-solver software, currents are defined as ENTERING the pins ## of the package from the board (General Syntax Rule #10). The corresponding ## voltage drops are to be measured with the current pointing "in" to the "+" ## sign and "out" of the "-" sign. ## ## I1 +-----+ I2 ## -----> | | <------ ## board 0--------| Pkg |---------0 board ## + V1 - | | - V2 + ## +-----+ ## ## It is important to observe this convention in order to get the correct signs ## for the mutual inductances and resistances. ################################################################################ $|------------------------------------------------------------------------------ $[Package Model] Package_Model_Name $| $|============================================================================== $| Keyword: [Pin Mapping] $| Required: No $|Description: Used to indicate which power and ground buses a given driver, $| receiver, or terminator is connected. $| Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref $|Usage Rules: Each power and ground bus is given a unique name which must $| not exceed 15 characters. The first column contains a pin $| number. Each pin number must match one of the pin numbers $| declared previously in the [Pin] section of the IBIS file. $| The second column, "pulldown_ref", designates the ground bus $| connections for that pin. Here the term "ground bus" can $| also mean another "power bus". The third column "pullup_ref" $| designates the power bus connection. The forth and fifth $| columns "gnd_clamp_ref" and "power_clamp_ref" contain $| entries, if needed, to specify different ground bus $| and power bus connections than those previously specified. $| $| If the [Pin Mapping] keyword is present, then the bus $| connections for EVERY pin listed in the [Pin] section must $| be given. $| $| Each line must contain either three or five columns. "NC" $| is used for entries which are not needed or which follow $| the conditions below: $| $| If a pin has no connection, then both the "pulldown_ref" $| and "pullup_ref" entries for it will be NC. $| $| GND and POWER pin entries and buses are designated by $| entries in either the "pulldown_ref" or "pullup_ref" columns. $| There is no implied association to any column other than $| through explicit designations in other pins. $| $| For any other type of pin, the "pulldown_ref" column contains $| the power connection for the [Pulldown] table for non-ECL type $| [Models]. This is also the power connection for the [GND Clamp] $| table and the [Rgnd] model unless overridden by a specification $| in the "gnd_clamp_ref" column. $| $| Also, the "pullup_ref" column contains the power connection $| for the [Pullup] table and, for ECL type models, the [Pulldown] $| table. This is also the power connection for the [POWER Clamp] $| table and the [Rpower] model unless overridden by a specification $| in the "power_clamp_ref" column. $| $| Column length limits are: $| [Pin Mapping] 5 characters max $| pulldown_ref 15 characters max $| pullup_ref 15 characters max $| gnd_clamp_ref 15 characters max $| power_clamp_ref 15 characters max $| $$| When 5 columns are used the headings "gnd_clamp_ref" and $| "power_clamp_ref" must be used. Otherwise, these headings can $| be omitted. $|--------------------------------------------------------------------------- $[Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref $| $1 GNDBUS1 PWRBUS1 | Signal pins and their associated $2 GNDBUS2 PWRBUS2 | ground and power connections $3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP $4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP $5 GNDBUS2 PWRBUS2 NC PWRCLAMP $6 GNDBUS2 PWRBUS2 GNDCLMP NC $ | Some possible clamping connections $| . | are shown above for illustration $| . | purposes $| . $11 GNDBUS1 NC | One set of ground connections. $12 GNDBUS1 NC | NC indicates no connection to $13 GNDBUS1 NC | power bus. $| . $21 GNDBUS2 NC | Second set of ground connections $22 GNDBUS2 NC $23 GNDBUS2 NC $| . $31 NC PWRBUS1 | One set of power connections. $32 NC PWRBUS1 | NC indicates no connection to $33 NC PWRBUS1 | ground bus. $| . $41 NC PWRBUS2 | Second set of power connections $42 NC PWRBUS2 $43 NC PWRBUS2 $| . $51 GNDCLMP NC | Additional power connections $52 NC PWRCLMP | for clamps $| $|============================================================================== $| Keyword: [Diff Pin] $| Required: No $|Description: Associates differential pins, their differential $| threshold voltages, and differential timing delays. $| Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max $|Usage Rules: Enter only differential pin pairs. The [Diff Pin] column $| contains a non-inverting pin number and the inv_pin column $| always contains the corresponding inverting pin number for $| I/O output. The vdiff column contains the specified $| output and differential threshold voltage between pins if $| the pins are Input or I/O Model_types. For output only $| differential pins, the vdiff entry is 0V. The tdelay columns $| contain launch delays of the non-inverting pins relative to $| the inverting pins. The values can be either polarity. $| $| If a pin is a differential input pin, the differential input $| threshold (vdiff) overrides and supersedes the need for Vinh and $| Vinl. $| $| If vdiff is not defined for a pin that is defined as requiring a $| Vinh by its [Model] type. The parser issues a warning and $| vdiff is set to the default value of 200mV. $| $|Other Notes: The output pin polarity specification in the table overrides $| the [Model] Polarity specification such that the pin in the $| [Diff Pin] column is Non-Inverting and the pin in the $| inv_pin column is Inverting. This convention enables $| one [Model] to be used for both pins. $| $| Column length limits are: $| [Diff Pin] 5 characters max $| inv_pin 5 characters max $| vdiff 9 characters max $| tdelay_typ 9 characters max $| tdelay_min 9 characters max $| tdelay_max 9 characters max $| $| Each line must contain either four or six columns. If "NA" is $| entered in the vdiff, tdelay_typ, or tdelay_min columns, its $| entry is interpreted as 0V or 0ns. If "NA" appears in $| the tdelay_max column, its value is interpreted as the $| tdelay_typ value. When using six columns, the headers $| tdelay_min and tdelay_max must be listed. Entries for the $| tdelay_min column are based on minimum magnitudes; and $| tdelay_max column, maximum magnitudes. One entry of vdiff, $| regardless of its polarity, is used for difference magnitudes. $|--------------------------------------------------------------------------- $[Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max $| $ 3 4 150mV -1ns 0ns -2ns | Input or I/O pair $ 7 8 0V 1ns NA NA | Output* pin pair $ 9 10 NA NA NA NA | Output* pin pair $16 15 200mV 1ns | Input or I/O pin pair $20 19 0V NA | Output* pin pair, tdelay = 0ns $22 21 NA NA | Output*, tdelay = 0ns $ | * Could be Input or I/O with vdiff = 0V |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes. $| Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref $| Rref, Vref $| Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, $| Open_sink, I/O_open_sink, Open_source, I/O_open_source, $| Input_ECL, Output_ECL, I/O_ECL, and Terminator model must | begin with the keyword [Model]. The model_name must match | the one that is listed under the [Pin] keyword and must not | contain more than 20 characters. An .ibs file must contain | enough [Model] keywords to cover all of the model_names | specified under the [Pin] keyword, except for those | model_names that use reserved words (POWER, GND and NC). | Model_names with reserved words are an exception and | they do not have to have a corresponding [Model] keyword. | C_comp is allowed to use "NA" for the min and max values only. | The Model_type and C_comp sub-parameters are required. | $| The model types Input, I/O, I/O_open_drain, I/O_open_sink, and $| I/O_open_soure must have Vinl and Vinh defined. If they are not $| defined, the parser issues a warning and the default $| values of Vinl=.8V and Vinh=2.0V are assumed. $| $| The model types Input_ECL and I/O_ECL must have Vinl and Vinh $| defined. If they are not defined, the parser issues a $| warning and the default values of Vinl=-1.475V and Vinh=-1.165V $| are assumed. $| $| Cref, Rref and Rref are optional. These parameters correspond $| to the test load that the manufacturer uses when specifying the $| propagation delay and/or output switching time of the device. $| Vmeas is the reference voltage level the manufacture uses $| for the above. This information is included in the IBIS $| specification to facilitate board-level timing simulation. $| The assumed connections for Cref, Rref, and Rref are shown $| below. $| ## AR John Keifer: Please supply a connection diagram $| $| Other Notes: A complete [Model] description normally contains the following $| keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], $| [POWER Clamp], and [Ramp]. A Model_type of Terminator uses one $| or more of the [Rgnd], [Rpower], [Rac], and [Cac] keywords. $| However, some models may have only a subset of these keywords. $| For example, an input structure normally only needs the $| [Voltage Range], [GND Clamp], and possibly the [POWER Clamp] $| keywords. If one or more of [Rgnd], [Rpower], [Rac], and [Cac] $| keywords are used, then the Model_type must be Terminator. $| $| A "Terminator" is an input-only device that can have analog $| loading effects on the circuit being simulated but has no $| digital logic thresholds. Examples of Terminators are: $| capacitors, termination diodes, pullup resistors etc. $| ## The following paragraph seems confusing to me, particularly the ## parenthetical phrases. - Derrick $| $| Model_types with Open_sink specify that the output has $| an OPEN side (the [Pullup] keyword is not used, or I = 0mA $| for all voltages specified) AND the output SINKS current. $| Model_types with "open_drain" have the identical meaning and $| are retained for backward compatibility. Model_types with $| Open_source specify that the output has an OPEN side (the $| [Pulldown keyword is not used, or I = 0mA for all voltages $| specified) AND the output SOURCES current. Model_types with $| Input_ECL, Output_ECL, or I/O_ECL specify that the model $| represents and ECL type logic that follows different $| conventions for the [Pulldown] keyword. $| | C_comp defines the silicon die capacitance. This | value should not include the capacitance of the package. | |------------------------------------------------------------------------------ [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, $ I/O_open_drain, Open_sink, I/O_open_sink, $ Open_source, I/O_open_source, Input_ECL, $ Output_ECL, I/O_ECL, Terminator | List one only, if any Polarity Non-Inverting, Inverting | List one only, if any Enable Active-High, Active-Low | List one only, if any | Signals RAS, CAS, A(0-64), D(0-128),... | Local list, if desired Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any $Vmeas = 1.5V |Test voltage timings are specified to $Cref = 50pF |Timing specification test load capacitance value $Rref = NA |Timing specification test load resistance value $Vref = NA |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== $| Keyword: [Temperature range] $| Required: Yes, if other than the preferred 0, 50, 100 degree C range $| Description: Defines the temperature range over which the model is $| to operate. $| Usage Rules: List the actual die temperatures (not percentages) in the $| usual typ, min, max format. "NA" is not allowed. $| Other Notes: [Temperature range] also describes the temperature range over $| which the various V/I curves and ramp rates were derived. $|------------------------------------------------------------------------------ $| variable typ min max $[Temperature range] 27.0C -50C 130.0C | |============================================================================== | Keyword: [Voltage Range] $| Required: Yes, if [Pullup Reference], [Pulldown Reference], $| [POWER Clamp Reference], and [GND Clamp Reference] are not $| present $|Description: Defines the power supply voltage tolerance over which the $| model is intended to operate. It also specifies the default $| voltage rail to which the pullup and POWER_clamp V/I data is $| referenced. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|--------------------------------------------------------------------------- $| variable typ min max $[Voltage Range] 5.0v 4.5v 5.5v $| $|============================================================================== $| Keyword: [Pullup Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a voltage rail other than that defined by the $| [Voltage Range] keyword as the reference voltage for the $| pullup V/I data. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: This keyword, if present, also defines the voltage range over $| which the min and max dV/dt_r values are derived. $|--------------------------------------------------------------------------- $| variable typ min max $[Pullup Reference] 5.0V 4.5V 5.5V $| $|============================================================================== $| Keyword: [Pulldown Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a power supply rail other than 0v as the reference $| voltage for the pulldown V/I data. If this keyword is not $| present, the voltage data points in the pulldown V/I table $| are referenced to 0v. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: This keyword, if present, also defines the voltage range over $| which the min and max dV/dt_f values are derived. $|--------------------------------------------------------------------------- $| variable typ min max $[Pulldown Reference] 0V 0V 0V $| $|============================================================================== $| Keyword: [POWER Clamp Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a voltage rail other than that defined by the $| [Voltage Range] keyword as the reference voltage for the $| [POWER Clamp] V/I data. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. $|--------------------------------------------------------------------------- $| variable typ min max $[POWER Clamp Reference] 5.0V 4.5V 5.5V $| ---------------------------------- end of part 2 ------------------------------ From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:33:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07385; Wed, 25 May 94 00:33:18 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DPf-000MO3C; Wed, 25 May 94 00:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:30:03 PST Date: Wed, 25 May 94 00:30:03 PST From: Derrick Duehren Message-Id: <940525003003_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 3 Text item: Text_1 $|============================================================================== $| Keyword: [GND Clamp Reference] $| Required: Yes, if the [Voltage Range] keyword is not present. $|Description: Defines a power supply rail other than 0v as the reference $| voltage for the [GND Clamp] V/I data. If this keyword is not $| present, the voltage data points in the [GND Clamp] V/I table $| are referenced to 0v. $|Usage Rules: Provide actual voltages (not percentages) in the usual typ, min, $| max format. "NA" is allowed for the min and max values only. $|Other Notes: Power Supplies: It is intended that standard TTL and CMOS $| devices be specified using only the [Voltage Range] keyword. $| However, in cases where the output characteristics of a device $| depend on more than a single supply and ground, or a pullup, $| pulldown, or clamp structure is referenced to something other $| than the default supplies, use the additional 'reference' $| keywords. $| $| If the [Voltage Range] keyword is not present, then all four of $| the other keywords must be present. If the [Voltage Range] $| keyword is present, the other keywords are optional and may or $| may not be used as required. It is legal (although redundant) $| for an optional keyword to specify the same voltage as specified $| by the [Voltage Range] keyword. $|--------------------------------------------------------------------------- $| variable typ min max $[GND Clamp Reference] 0V 0V 0V $| |============================================================================== | Keywords: [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves of | the pulldown and pullup structures of an output buffer and the | V/I curves of the clamping diodes connected to the GND and the $| POWER pins, respectively. Currents are considered positive $| when their direction is into the component. $| | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: The V/I curve of the [Pullup] and the [POWER Clamp] structures $| are 'Vcc relative', meaning that the voltage values are $| referenced to the Vcc pin. (Note: Under these keywords, all $| references to 'Vcc' refer to the voltage rail defined by the $| [Voltage range], [Pullup Reference], or [POWER Clamp Reference] $| keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | $| When tabulating data for ECL devices, the data in the pulldown $| table is measured with the output in the 'logic low' state. $| In other words, the data in the table represents the V-I $| characteristics of the output when the output is at the most $| negative of its two logic levels. Likewise, the data in the $| pullup table is measured with the output in the 'logic one' $| state and represents the V-I characteristics when the output $| is at the most positive logic level. Note that in BOTH of $| these cases, the data is referenced to the Vcc supply voltage, $| using the equation Vtable = Vcc - Voutput. $| $| V/I table data is allowed to be non-monotonic in one axis. $| To be monotonic, the V/I table data must meet any one of the $| following 8 criteria: $| 1- The CURRENT axis either increases or remains constant as $| the voltage axis is increased. $| 2- The CURRENT axis either increases or remains constant as $| the voltage axis is decreased. $| 3- The CURRENT axis either decreases or remains constant as $| the voltage axis is increased. $| 4- The CURRENT axis either decreases or remains constant as $| the voltage axis is decreased. $| $| 5- The VOLTAGE axis either increases or remains constant as $| the current axis is increased. $| 6- The VOLTAGE axis either increases or remains constant as $| the current axis is decreased. $| 7- The VOLTAGE axis either decreases or remains constant as $| the current axis is increased. $| 8- The VOLTAGE axis either decreases or remains constant as $| the current axis is decreased. $| $| It is assumed that the simulator sums the clamp curves $| together with the appropriate pullup or pulldown curve when a $| buffer is driving high or low, respectively. From this $| assumption and the nature of 3-statable buffers, it follows $| that the data in the clamping curve sections are handled as $| constantly present curves and the pullup and pulldown curves $| are used only when needed in the simulation. $| $| The clamp curves of an input or I/O buffer can be measured $| directly with a curve tracer, with the I/O buffer 3-stated. $| However, sweeping enabled buffers results in curves that are $| the sum of the clamping curves and the output structures. $| Based on the assumption outlined above, the pullup and $| pulldown curves of an IBIS model must represent the difference $| of the $3-stated and the enabled buffer's curves. (Note that $| the resulting difference curve can demonstrate a non-monotonic $| shape.) This requirement enables the simulator to sum the $| curves, without the danger of double counting, and arrive at $| an accurate model in both the 3-stated and enabled conditions. $| $| Since in the case of a non 3-statable buffer, this difference $| curve cannot be generated through lab measurements (because $| the clamping curves cannot be measured alone), the pullup and $| pulldown curves of an IBIS model can contain the sum of the $| clamping characteristics and the output structure. In this $| case, the clamping curves must contain all zeroes, or the $| keywords must be omitted. |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | $|============================================================================== $| Keywords: [Rgnd], [Rpower], [Rac], [Cac] $| Required: Yes, if they exist in the device $| Description: The data for these keywords define the resistance values of $| Rgnd and Rpower connected to GND and the POWER pins, $| respectively. $| Usage Rules: For each of these keywords, the three columns hold the $| typical, minimum, and maximum resistance values. The three $| entries for R(typ), R(min), and R(max), or the three entries for $| C(typ), C(min), and C(max) must be placed on a single line and $| must be separated by at least one white space or tab character. $| All three columns are required under these keywords. However, $| data is only required in the typical column. If minimum $| and/or maximum values are not available, the reserved word $| "NA" must be used indicating the R(typ) or C(typ) value by $| default. $| Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and $| [Rgnd] is connected to 'GND'. However, [GND Clamp Reference] $| voltages, if defined, apply to [Rgnd]. [POWER Clamp Reference] $| voltages, if defined, apply to [Rpower]. Either or both [Rgnd] $| and [Rpower] may be defined and may coexist-exist with [GND Clamp] $| and [POWER Clamp] structures. If an AC terminator is $| specified, then both [Rac] and [Cac] are required. When $| [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the $| Model_type must be Terminator. $| $| |<-------------TERMINATOR Model--------------->| $| $| VOLTAGE RANGE or $| POWER_CLAMP REF $| o $| | $| POWER_ |---o---| $| CLAMP | | $| |--o--| \ $| | | / $| | VI | \ RPOWER PACKAGE Keyword $| Parameters $| |--o--| | |<----------------->| $| | | $| | | PIN $| o-----o-------o-----o-----/\/\/\--UUUUUU---o--o $| | |GND_ | | R_PKG L_PKG | $| | |CLAMP | | | $| | |--o--| | | | $| | | | \ | | $| | | VI | /RGND | | $| | | | \ \ | $| | |--o--| / / RAC | $| | | | \ | $| | |---o---| / | $| | | | | $| C_COMP --- o --- CAC C_PKG --- $| --- GND or --- --- $| | GND_CLAMP REF | | $| | | | $| |-------------------o----------------------| $| | $| o $| GND $|------------------------------------------------------------------------------ $| variable R(typ) R(min) R(max) $| $[Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator $[Rpower] 220Ohm 200Ohm NA $| $[Rac] 30Ohm NA NA $| $| variable C(typ) C(min) C(max) | AC terminator $| $[Cac] 50pF NA NA $| |============================================================================== | Keyword: [Ramp] | Required: Yes, except for inputs | Description: Defines the rise and fall times of a buffer. $| Sub-Params: dV/dt_r, dV/dt_f, R_load $| Usage Rules: These parameters describe an ideal slope and can be expressed $| as a ratio of any reasonable voltage and time values as shown $| in the examples. The [Ramp] values can to use "NA" for the $| min and max values only. The R_load sub-parameter is optional $| if the preferred 50 ohm load is used. It is required if a non- $| standard load is used. $|------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n $R_load = 300ohms $| $|============================================================================== $| Keywords: [Rising waveform], [Falling waveform] $| Required: No $| Description: Describes the shape of the rising and falling edge $| waveforms of a driver. $| Sub-params: R_fixture, V_fixture, C_fixture, L_fixture, $| R_dut, L_dut, C_dut $| Usage Rules: Each [Rising waveform] and [Falling waveform] keyword $| introduces a table of time vs. voltage points that $| describe the shape of an output waveform. These $| time/voltage points are taken under the conditions $| specified in the R/L/C/V_fixture and R/L/C_dut $| sub-parameters. The table itself consists of $| one column of time points, then three columns of $| voltage points in the standard typ, min, and max format. $| The four entries must be placed on a single line and $| must be separated by at least one white space or tab $| character. All four columns are required. However, data $| is only required in the typical column. If minimum $| or maximum data is not available, use the reserved word $| "NA". The first value in the time column need not be `0'. $| Time values must increase as one parses down the table. $| The waveform table can contain a maximum of 100 data $| points. A maximum of 100 waveform tables are allowed per $| model. Note that for backwards compatibility, the existing $| [Ramp] keyword is still required. $| $| A waveform table must include the entire waveform; $| i.e., the first entry (or entries) in a voltage column $| must be the DC voltage of the output before switching $| and the last entry (or entries) of the column must be $| the final DC value of the output after switching. $| $| A [Model] specification can contain more than one rising $| edge or falling edge waveform table. However, each new $| table must begin with the appropriate keyword and sub- $| parameter list as shown below. If more than one rising or $| falling edge waveform table is present, then the data in $| each of the respective tables must be time correlated. $| In other words, the rising (falling) edge data in each $| of the rising (falling) edge waveform tables must be $| entered with respect to a common reference point on the $| input stimulus waveform. $| $| The 'fixture' sub-parameters specifies the loading $| conditions under which the waveform is taken. The R_dut, $| C_dut, and L_dut Sub-params are analogous to the $| package parameters R_pkg, C_pkg and L_pkg and are used $| if the waveform includes the effects of pin $| inductance/capacitance. The diagram below shows the $| interconnection of these elements. $| $| PACKAGE | TEST FIXTURE $| _________ $| | DUT | L_dut R_dut | L_fixture R_fixture $| | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture $| | | \/ | | | \/ $| |_________| | | $| | | $| C_dut === | === C_fixture $| | | $| | | $| gnd | gnd $| $| Only the R_fixture and V_fixture sub-parameters are $| required, the rest of the sub-parameters are optional. $| If a sub-parameter is not used, its value defaults to $| zero. The sub-parameters must appear in the text after $| the keyword and before the first row of the waveform $| table. $|------------------------------------------------------------------------------ $[Rising waveform] $R_fixture = 500 $V_fixture = 5.0 $C_fixture = 50p $L_fixture = 2n $C_dut = 7p $R_dut = 1m $L_dut = 1n $|Time V(typ) V(min) V(max) $ 0.0ns 0.3 0.5 NA $ 0.5ns 0.3 0.5 NA $ 1.0ns 0.6 0.7 NA $ 1.5ns 0.9 0.9 NA $ 2.0ns 1.5 1.3 NA $ 2.5ns 2.1 1.7 NA $ 3.0ns 3.0 2.7 NA $ 3.5ns 3.2 3.0 NA $| $[Falling waveform] $R_fixture = 50 $V_fixture = 0 $|Time V(typ) V(min) V(max) $ 10.0ns 3.2 3.0 NA $ 10.5ns 3.0 2.7 NA $ 11.0ns 2.1 1.7 NA $ 11.5ns 1.5 1.3 NA $ 12.0ns 0.9 0.9 NA $ 12.5ns 0.6 0.7 NA $ 13.0ns 0.3 0.5 NA $ 13.5ns 0.3 0.5 NA | ------------------------------ end of part 3 --------------------------------- From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:33:36 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07390; Wed, 25 May 94 00:33:36 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DPx-000MO3C; Wed, 25 May 94 00:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:30:21 PST Date: Wed, 25 May 94 00:30:21 PST From: Derrick Duehren Message-Id: <940525003021_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 4 Text item: Text_1 |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor base | its data on typical process data, and then derate by voltage and temperature, | and a proprietary "X%" factor. This methodology also has the nice feature | that the data can be derived either from vendor-proprietary silicon models, or | typical device measurement over temperature/voltage. | $| 1) V/I curves for CMOS devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, max temp deg C, typical process, minus "X%" $| max = hi voltage tol, min temp deg C, typical process, plus "X%" $| $| V/I curves for bipolar devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, min temp deg C, typical process, minus "X%" $| max = hi voltage tol, max temp deg C, typical process, plus "X%" $| $| Nominal, min, and max temperature are specified by the manufacturer $| of the part. The default range is 50C nom, 0C min, and 100C max $| temperatures. $| $| X% should be statistically determined by the silicon vendor based $| on numerous fab lots, test chips, process controls, etc. The value $| of X need not be published in the IBIS file, and may decrease over $| time as data on the I/O buffers and silicon process increases. $| $| Temperatures are junction temperatures. $| | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | For example, a device with a 5 V power supply voltage should be | characterized between (0 - 5) = -5 V and (5 + 5) = 10 V; and a | device with a 3.3 V power supply should be characterized between | (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the pulldown curve. $| $| When tabulating output data for ECL type devices, the voltage points $| must span the range of Vcc to Vcc - 2.2V. This range applies to both the $| pullup and pulldown tables. Note that this range applies ONLY when $| characterizing an ECL output. $| $| These voltage ranges must be spanned by the IBIS data. Data derived $| from lab measurements may not be able to span these ranges as such and $| so may need to be extrapolated to cover the full range. This data must $| not be left for the simulator to provide. | | 3) Ramp Rates: $| The following steps assume that the default load resistance of 50 ohms is $| used. There may be devices that will not drive a load of only 50 ohms $| into any useful level of dynamics. In these cases, use the manufacturer's $| suggested (non-reactive) load and add the load sub parameter to the [Ramp] $| specification. $| $| The ramp rate does not include package and parameters; it is the intrinsic $| output stage rise and fall time only. $| $| The ramp rates (listed in AC characteristics below) should be derived $| as follows: $| $| a. If starting with the silicon model, remove all packaging. If starting $| with a packaged device, perform the measurements as outlined below then $| use whatever techniques are appropriate to derive the actual, unloaded $| rise and fall times. $| $| b. If: The Model_type is one of the following: Output, I/O, or $| 3-state (not open or ECL types); $| Then: Attach a 50 ohm resistor to GND to derive the rising edge $| ramp. Attach a 50 ohm resistor to POWER to derive the $| falling edge ramp. $| $| If: The Model_type is Output_ECL or I/O_ECL; $| Then: Attach a 50 ohm resistor to the termination voltage $| (Vterm = VCC - 2v). Use this load to derive both the $ | rising and falling edges. $| $| If: The Model_type is either an open_sink type or open_drain type; $| Then: Attach either a 50 ohm resistor or the vendor-suggested $| termination resistance to either POWER or the vendor- $| suggested termination voltage. Use this load to derive both $| the rising and falling edges. $| $| If: The Model_type is an open_source type; $| Then: Attach either a 50 ohm resistor or the vendor-suggested $| termination resistance to either GND or the vendor-suggested $| termination voltage. Use this load to derive both the rising $| and falling edges. $| $| c. Due to the resistor, output swings will not make a full transition as $| expected. However the pertinent data can still be collected as $| follows: $| 1) determine the 20% to 80% voltages of the 50 Ohm swing $| 2) measure this voltage change as "dv" $| 3) measure the amount of time required to make this swing "dt" $| d. Post the value as a ratio "dv/dt". The simulation tool vendor $| extrapolates this value to span the required voltage swing range in $| the final model. $| $| e. Typ, Min, and Max must all be posted, and are derived at the same $| extremes as the V/I curves, which are: $| $| Ramp rates for CMOS devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, max temp deg C, typical process, minus "X%" $| max = hi voltage tol, min temp deg C, typical process, plus "X%" $| $| Ramp rates for bipolar devices: $| typ = nominal voltage, nominal temp deg C, typical process $| min = low voltage tol, min temp deg C, typical process, minus "X%" $| max = hi voltage tol, max temp deg C, typical process, plus "X%" $| $| where nominal, min, and max temp are specified by the manufacturer of $| the part. The preferred range is 50C nom, 0C min, and 100C max $| temperatures. $| $| Note that the derate factor, "Y%", may be different than that used $| for the V/I curve data. This factor is similar to the X% factor $| described above. As in the case of V/I curves, temperatures are $| junction temperatures. $| $| f. During the IV measurements, the driving waveform should have a $| rise/fall time fast enough to avoid thermal feedback. The specific $| choice of sweep time is left to the modeling engineer. $| | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. | $-----------------------------------cut here ----------------------------------- |============================================================================== NOTES ON IBIS_CHK PROGRAM (not to be left in the actual specification) $The V/I table DATA SHOULD BE MONOTONIC to insure that most simulators provide $stable simulations. Monotonic data is needed to insure that all data is $single valued. MONOTONIC DATA IS NOT REQUIRED to provide a valid IBIS model. $It is recognized that automated measurement equipment may be used to acquire $this data and as such may include "noise" that causes the data to be non- $monotonic. It is also recognized that some devices may be non-monotonic in $certain regions. Therefore the IBIS specification allows non-monotonic data. $Simulation tools should filter out non-monotonic data if such data causes $instabilities in the simulation results. The IBIS_CHK program tests for non- $monotonic data and provides a maximum of one note per V/I table if non- $montonic data is found. $ $ "NOTE: Line xxx of V/I table yyy for model zzz is non-monotonic! $ Most simulators will filter this data to remove the non-monotonic data." $ $ Where xxx is the line number in the IBIS file. $ Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. $ Where zzz is the name of the model. $ $*************************************************************************** $Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. $*************************************************************************** $For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, $GND_clamp $ $ 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. $ $ 2) IF:The current in the TYPICAL column corresponding to Vmax is less than $ the current in the TYPICAL column corresponding to Vmin than $ the table is assumed to have decreasing current. $ ELSE IF:The current in the TYPICAL column corresponding to Vmax $ is greater than the current in the TYPICAL column corresponding to $ Vmin than the table is assumed to have increasing current. $ ELSE: The table is assumed to have equal current." $ $ Note: This works for all cases of discontinuities unless the magnitude of $ discontinuity is such that this model is in all probability $ completely unrealistic. $ $*************************************************************************** $Change 3- Add a header comment statement at the TOP of the IBIS_CHK program $ to insure that new changes to the IBIS_CHK program do not break tests $ that worked in old MAJOR versions. This approach makes the program $ larger however it insures the parser always works the same on older $ versions of IBIS. This approach uses more memory, but has the reward $ of low maintaining costs. The IBIS_CHK program is very small and $ would not be effected by this until many revisions have occurred. $*************************************************************************** $NOTICE TO ANY PERSON MODIFING THIS PROGRAM! $------------------------------------------- $This program SHALL NOT BE MODIFIED unless there is an associated IBIS Buffer $Issue Resolution Document (BIRD). Said BIRD shall be agreed upon by IBIS $committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is $allowed to modify the source code. The present CZAR is Jon Powell (April $1994). The IBIS committee may also hire programmers from time to time to make $major changes to the source code. $ $Note: Source licensees are free to modify their own copies of this source $code in any way they choose. Source licensees shall not redistribute $the source code modified or otherwise. Source licensing is available from the $IBIS open forum. The IBIS open forum is non-profit. $ $The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED $when adding code for the next version of the IBIS specification. Instead $completely new code for all functions and features shall be created. This $may require duplication of numerous functions. $ $Each function shall be preceded by VXX_ where XX is the MAJOR version $of the IBIS specification which is being parsed and tested. A MAJOR version $would for example be 1.x going to 2.x. A MINOR version would for example be $1.1 to 1.2. Functions using the above syntax would look as follows: $V01_GetValue $ $MINOR revisions DO NOT required new code. $ $Startup code shall be provided at the top of the program that reads the $version number from the IBIS file and runs the portion of the program $corresponding to that MAJOR version. Code that is used only by the program $startup function is not duplicated. $ $-----------------------------------cut here ---------------------------------- $|============================================================================= $| PACKAGE MODELING $| The [Package_Model] keyword is used within a [Component] to indicate $| which package model should be used for that part. $| $| The resolved specification permits .ibs files to contain [Define $| Package Model] keywords as well. These are described in $| "SYNTAX FOR THE .PKG FILE", below. 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. $| $|============================================================================== $| Keyword: [Package Model] Package_Model_Name $| Required: No $| Description: Indicates the name of the package model $| Usage Rules: The Package_Model_Name is limited to 40 characters. $| Spaces are allowed in the name. The name should include the $| company name or initials to help ensure uniqueness. If the $| package model is in a separate .pkg file, it must be kept in $| the same directory as the .ibs file. $| Other Notes: Use the [Package_Model] keyword within a [Component] to $| indicate which package model should be used for that part. $| The specification permits .ibs files to contain [Define $| Package Model] keywords as well. These are described $| in the "package modeling" section below. When package model $| definitions occur within an .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. $| $| SYNTAX FOR THE .PKG FILE $| $| Package models are stored in a file whose name looks like .pkg. $| $| The provided must adhere to MS-DOS file name conventions: it must $| not exceed 8 characters in length. All of these characters must be lower $| case. The extension ".pkg" is used to identify files containing package $| models. $| $| The .pkg file must contain all of the Required elements of a normal .ibs $| file, including [IBIS Ver], [File Name], [File Rev], and the [End] keywords. $| $| Optional elements include the [Date], [Source], [Notes], [Disclaimer], $| and [Comment char] keywords. $| $| All of the above elements follow the exact same rules as those for a normal $| .ibs file. $| $| The [Component] and [Model] keywords are FORBIDDEN in the .pkg file. The $| .pkg file is only for package models. $| $|============================================================================== $| Keyword: [Define Package Model] $| Required: Yes $| Description: Mark 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 and blank characters are $| allowed. $|------------------------------------------------------------------------------ $[Define Package Model] Package_Model_Name $|============================================================================== $| $|============================================================================== $| Keyword: [Manufacturer] $| Required: Yes $| Description: Declares the manufacturer of the part(s) that use this package $| model. $| Usage Rules: The length of the Manufacturer's name must not exceed 40 $| characters (blank characters are allowed, e.g., Texas $| Instruments). In addition, each manufacturer must use a $| consistent name in all .ibs files. $|------------------------------------------------------------------------------ $[Manufacturer] Manufacturer's Name | e.g., Intel Corp. $| $|============================================================================== $| Keyword: [OEM] $| Required: Yes $| Description: Declares the manufacturer of the package. $| Usage Rules: The length of the Manufacturer's name must not exceed 40 $| characters (blank characters are allowed, e.g., Texas $| Instruments). In addition, each manufacturer must use a $| consistent name in all .ibs files. $| Other Notes: This keyword is useful if the semiconductor vendor sells a $| single IC in packages from different manufacturers (e.g. AMP, $| Kyocera). $|------------------------------------------------------------------------------ $[OEM] Pkgs_R_Us Inc. $|============================================================================== $| $ $The [Description] keyword is used to indicate to a human being what $the model is describing. $| $|============================================================================== $| Keyword: [Description] $| Required: Yes $| Description: Provides a concise yet easily human-readable description of $| what kind of package the [Package_Model] is representing. $| Usage Rules: The description must be less than 60 characters in length, $| must fit on a single line, and may contain spaces. $|------------------------------------------------------------------------------ $[Description] 220-Pin Quad Ceramic Flat Pack $| $|============================================================================== $| Keyword: [Number of Pins] $| Required: Yes $| Description: Tells the parser how many pins to expect. $| Usage Rules: The value must be a positive integer less than 60 $| characters long. $|------------------------------------------------------------------------------ $[Number of Pins] 128 $| $|============================================================================== $| Keyword: [Pin Names] $| Required: Yes $| Description: Tells the parser the set of names that are used for the package $| pins, and to defines an ordering of them. The first pin name $| given is the "lowest" pin, and the last pin given is the $| "highest." The pin names can not exceed 5 characters in $| length. $| Usage Rules: Following the [Pin Names] field, the names of the pins are $| listed. There must be as many names listed as there are $| pins (as given by the preceding [Number of Pins].) $|------------------------------------------------------------------------------ $[Pin Names] $A1 $A2 $| . $| . $| . $A22 $B1 $| . $| . $| . $| etc. $| $|============================================================================== $| Keyword: [Model Data] $| Required: Yes $| Description: Indicates the beginning of the formatted model data. $|------------------------------------------------------------------------------ $[Model Data] $| ------------------------------ end of part 4 ------------------------------ From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:33:47 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07395; Wed, 25 May 94 00:33:47 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DQ8-000MOBC; Wed, 25 May 94 00:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:30:32 PST Date: Wed, 25 May 94 00:30:32 PST From: Derrick Duehren Message-Id: <940525003032_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: DRAFT IBIS Rev 2.0, part 5 of 5 Text item: Text_1 $|============================================================================== $| Keyword: [End Model Data] $| Required: Yes $| Description: Indicates the end of the formatted model data. $| Other Notes: In between the [Model Data] and [End Model Data] keywords is $| the package model data itself. The data is a set of 3 $| matrices: the resistance (R), inductance (L), and capacitance $| (C) matrices. Each matrix can be formatted differently (see $| below). Use one of the matrix keywords below to mark the $| beginning of each new matrix. $|------------------------------------------------------------------------------ $[End Model Data] $| $|============================================================================== $| Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] $| Required: [Resistance Matrix] is optional. If it's not present, its $| entries are assumed to be zero. [Inductance Matrix] and $| [Capacitance Matrix] are required. $| Description: These keywords mark the beginning of a matrix, and $| specify how the matrix data is formatted. $| Usage Rules: There are 3 choices for the Format_Keyword: $| Banded Matrix, Sparse Matrix, and Full Matrix. $| $| After each of these keywords, the matrix data follows in the $| appropriate format. $| $| These formats are described in detail below. $|------------------------------------------------------------------------------ $[Resistance Matrix] Format_Keyword $[Inductance Matrix] Format_Keyword $[Capacitance Matrix] Format_Keyword $| $|============================================================================== $| For each [Resistance Matrix], [Inductance Matrix], or [Capacitance $| Matrix] a different format can be used for the data. The choice of $| formats is provided to satisfy different simulation accuracy and speed $| requirements. Also, there are many packages in which the resistance $| matrix can have no coupling terms at all. In this case, the most $| concise format (Banded_Matrix) can be used. $| $| One common aspect of all the different formats is that they exploit $| the symmetry of the matrices they describe. This means that the $| entries below the main diagonal of the matrix are identical to the $| corresponding entries above the main diagonal. Therefore, only $| roughly one-half of the matrix needs to be described. By convention, $| the main diagonal and the UPPER half of the matrix are provided. $| $| In the following text, we use the notation [I, J] to refer to the entry in $| row I and column J of the matrix. Note that I and J are allowed to be $| alphanumeric strings as well as integers. An ordering of these $| strings has been defined earlier in the [Pin Names] section. The following $| text sometimes refers to "Row 1", which 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 metrix "suffix" $| notation. Thus, an entry of the C matrix could be given as "1.23e-12" or as $| "1.23p" or "1.23pF". $| $| 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." Again let the matrix size be N, and let the bandwidth $| be B. An entry [I,J] of the matrix is zero if: $| $| | I - J | > B $| $| where |.| denotes the absolute value. $| $|The bandwidth for a Banded_Matrix must be specified using the [Bandwidth] $|keyword: $| $|============================================================================== $| Keyword: [Bandwidth] $| Required: Yes (for banded matrices only) $| Description: Indicates the bandwidth of the matrix. The BW field below $| must be a nonnegative integer. This keyword occurs after the $| [Resistance Matrix], etc. keyword, and BEFORE the matrix data $| is given. $| Usage Rules: $|------------------------------------------------------------------------------ $[Bandwidth] 10 $| $|============================================================================== $| The banded matrix is specified one row at a time, starting with row 1 and $| working up to higher rows. Each row is marked with the [Row] keyword, as $| above. As before, symmetry is exploited: entries below the main diagonal are $| never given. $| $| The first row only needs to specify the entries [1,1] through [1,1+B] since $| any other entries are guaranteed to be zero. The second row will need to $| specify the entries [2,2] through [2, 2+B], and so on. In general, for row M $| the entries [M,M] through [M,M+B] are given. $| $| Unlike the Full_Matrix, each successive row will typically have the same $| number of entries, except for the last few rows. When M + B finally exceeds $| the size of the matrix N, then the number of entries in each row starts to $| decrease; the last row (row N) has only 1 entry. $| $| As in the Full_Matrix (below), if all the entries for a particular row does $| 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. $| $| 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: Indicate the beginning of a new row of the matrix. The $| Row_Number field must be a pin name, $| Usage Rules: $|------------------------------------------------------------------------------ $[Row] 3 $| $|============================================================================== $| Following a [Row] keyword is a block of numbers that represent the $| entries for that row. Suppose that the current row is number M. Then $| the first number listed is the diagonal entry, [M,M]. Following this $| number are the entries of the upper half of the matrix that belong to row M: $| [M, M+1], [M, M+2], ... up to [M,N]. $| $| For even a modest-sized package, this data will not all fit on one line. $| Since each line of an IBIS file must be 80 characters long or less, it is $| permissible to break the data up with new lines 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. $| $| 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 (PGA's.) $| $| 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 $| $| Please 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 Names] section is observed. $| $| Also, please note that it is again necessarily the case that the N'th $| row of an N x N matrix has just a single entry (the diagonal entry.) $| $| An Example $| $| The following is an example of a package model file following the $| above specifications. For the sake of brevity, an 8-pin package has $| been described. For purposes of illustration, each of the matrices is $| specified using a different format. $| $|============================================================================== $| $[IBIS Ver] 2.0 $[File Name] example.pkg $[File Rev] 0.1 $[Date] April, 17 1994 $[Source] fervid imaginings $[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. $ Read at your own risk. See your dentist regularly. $| $|============================================================================== $| $[Define Package Model] Bozo-SMT-cer-8-pin-pkgs $[Manufacturer] Bozonics Semiconductors Ltd. $[OEM] Pkgs_R_Us $[Description] 8-Pin ceramic SMT package $[Number of Pins] 8 $| $[Pin Names] $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 $| $| All done! $| $[End Model Data] $[End] $|============================================================================== ------------------------------ end of Rev2_0.txt ------------------------------- From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:34:20 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07400; Wed, 25 May 94 00:34:20 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DQf-000MO3C; Wed, 25 May 94 00:31 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:31:05 PST Date: Wed, 25 May 94 00:31:05 PST From: Derrick Duehren Message-Id: <940525003105_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 5/20/94 Meeting Minutes Text item: Text_1 Date: May 24, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Editing Committee Meeting 5/20/94 Attendees: Cadence Design C. Kumar HyperLynx Kellee Crisafulli Intel Corporation Stephen Peters, Will Hobbs, Derrick Duehren (editor) Interconnectix, Inc. Bob Ross Quad Design Jon Powell NOTE: "AR" = Action Required. ------------------------------------------------------------------------ 5/20/94 Meeting Proposed Agenda ------------------------------- 8:00 Greetings 8:15 Bob Ross's roll-up (Presentation) 8:30 Page-by-page review of roll-up (in teams) 11:30 Pending BIRDs discussion Noon Lunch / Levels-of-support discussion 1:00 Conference call open forum (Vote on BIRDs) 2:00 Format/spec. outline discussion (new sections?) - Package model (within / without) - IBIS Check program, how to spec. - Context diagrams in the spec.? 2:30 Continue page-by-page review 4:00 Statement of Intent review/rewrite 4:30 Wrap up - Assign ARs (including who does final draft/post to reflector) 1. Greetings While waiting for everyone to arrive, Will Hobbs described Intel's plan for providing Pentium(TM) processor IBIS models. Discussion flowed into flight times and ramp times. 2. Bob Ross's Roll-up (Presentation) Bob briefly introduced his roll up, which was then used as a basis for the editing process. 3. Page-by-page review of roll-up The group reviewed Bob's roll-up page-by-page, noting changes on a master copy. All changes from V1.1 are marked in the Word for Windows edit file REV2_0.DOC, which Derrick is maintaining. 4. Pending BIRDs discussion Discussed as part of page-by-page review. 6. Conference call open forum (Vote on BIRDs) Bob ward, John Kiefer, Arpad joined the editing committee on the phone. BIRD 13.2 was discussed and approved unanimously. BIRD 14.1 was split into two issues: 1) First part Specifications Section [Pin Extension 1]. Model_type sub-parameter removed. Vtest changed to Vmeas. This BIRD is to be reissued as BIRD 16 and entered into REV2_0.DOC as pending approval at the 5/27 meeting. 2) Second (additional sub-parameters to the Model keyword). This portion of BIRD 14 (as BIRD 14.3) was approved unanimously. BIRD 5.4, Pin Mapping, was approved unanimously. BIRD 15. A long discussion ensued, mostly between Jon Powell and Arpad. Data derivation, combining data, measurement anomalies, decomposing data into data/ V/I curves,... should we provide measured or simulated data? Agreement reached: Chop out all but last paragraph of BIRD 15: Since in the case of a non 3-statable buffer this difference curve cannot be generated through lab measurements (because the clamping curves can not be measured alone), the pullup and pulldown curves of an IBIS model may contain the sum of the clamping characteristics and the output structure. In this case the clamping curves must contain all zeroes, or the keywords must be omitted. Tri-stateable parts: Keep 15 as is - sorta. This affects the non-monotonic approved BIRD. Add note to it (regarding the Golden Parser Warning/Note). Resolution was not clear. x. Levels-of-support discussion Decided not to do levels of support at this time. 8. Continue page-by-page review The group completed the review of Bob's roll-up. AR: Derrick and Stephen to edit, clean up, and post the draft to vhdl.org. [DONE] 7. Format/spec. outline discussion (new sections?) Discussed as part of page-by-page review. - Package model (within / without) Within. - IBIS Check program, how to spec. Not discussed. - Context diagrams in the spec.? Yes, as needed. 9. Statement of Intent review/rewrite Started, not finished. 10. Wrap up Derrick will chair the 5/27 meeting, as Will Hobbs will be traveling. The main focus will be discussion of the draft Rev 2.0 document. Bridge (415) 904-8800 #744468, 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:43:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07453; Wed, 25 May 94 00:43:18 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DZL-000MO3C; Wed, 25 May 94 00:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:40:03 PST Date: Wed, 25 May 94 00:40:03 PST From: Derrick Duehren Message-Id: <940525004003_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 5/27/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 5/27/94 Bridge: Res: (415) 904-8800 744468 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). When you call into the meeting, ask for the IBIS Open Forum and give the bridge operator the reservation number. NOTE: Derrick Duehren will be Chairing the meeting in Will Hobb's absence. 8:00 Check-in Intros of new IBIS participants Duehren Review of previous meeting's minutes Duehren Miscellany/Announcements Duehren Opens for new issues All New models available All IBIS Cookbook Rosenbaum 8:30 IBIS 2.0 Ratification/DAC/Other 2.0 Issues Derrick - May 20 Editing meeting - Report - Rev 2.0 Ratification Summit Rev 2.0 Review/Discussion/Approval of pending sections All BIRD 14/16, New section for [Model] sub-parameters Keifer BIRD 15, Clarification on usage of the V/I tables Arpad 9:55 Wrap-up, Next Meeting Plans Duehren From Derrick_Duehren@ccm2.jf.intel.com Wed May 25 00:53:26 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07536; Wed, 25 May 94 00:53:26 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q6DjA-000MO3C; Wed, 25 May 94 00:50 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 25 May 94 00:50:11 PST Date: Wed, 25 May 94 00:50:11 PST From: Derrick Duehren Message-Id: <940525005011_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Rev2_0 posted to vhdl.org Text item: Text_1 In case my 5-part mailing didn't work well for you, I have posted the draft IBIS Spec Rev2_0 to vhdl.org. It is in \pub\ibis\ver2.0\rev2_0.x01 - Derrick Duehren Intel From randyh Wed May 25 18:42:49 1994 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18259; Wed, 25 May 94 18:42:49 PDT Date: Wed, 25 May 94 18:42:49 PDT From: randyh (Randy Harr) Message-Id: <9405260142.AA18259@vhdl.vhdl.org> To: ibis@vhdl.org Subject: IBIS reflector My apologies to all. I added a new name to the IBIS list on 18 May which prevented anyone except the new names added from receiving mail. Worse yet, a UNIX sendmail bug did not report this error and just dropped everyone else off the list. Therefore email seemed to be going into a black hole for most people. I will retrieve all the messages sent since 18 May (from the email.archive file online) and resend them to the reflector. You should be fully back in operation now. And to think I thought everyone was being silent! Randy Harr, SYSOP, IBIS list randyh@vhdl.org randyh@synopsys.com From fkai@dellgate.us.dell.com Thu May 26 06:42:51 1994 Return-Path: Received: from dellgate.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26166; Thu, 26 May 94 06:42:51 PDT Received: by dellgate.us.dell.com with UUCP (Smail3.1.28.1 #1) id m0q6fgf-000D8LC; Thu, 26 May 94 08:41 CDT Message-Id: Date: Thu, 26 May 94 08:41 CDT From: fkai@dellgate.us.dell.com (Francis Kai) To: ibis@vhdl.org, randyh@vhdl.org (Randy Harr) Subject: Re: IBIS reflector Yes. I thought it is impossible to shut up everyone, so it will be my system's fault. Francis From speters@ichips.intel.com Thu May 26 08:27:57 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26828; Thu, 26 May 94 08:27:57 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 26 May 94 08:24:45 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 26 May 94 08:23:58 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 26 May 94 08:24:26 PDT Message-Id: <9405261524.AA18896@xtg801.intel.com> To: ibis@vhdl.org Subject: New Spec change notes re-posting Date: Thu, 26 May 1994 08:24:25 -0700 From: Stephen Peters Hello Fellow IBISans -- Now that the reflector is back on line I'm going to repost the change notes that went along with the new, rev2.0 spec. The spec itself, the minutes of the editing committe meetting, and the agenda for Fridays teleconferece are in Randy's message of 5/25 titled "Missing Mail since May 18" Please look the spec over and come prepared with comments. Best Regards, Stephen Peters Intel Corp. --------------------- cut here ------------------------ IBIS Version 2.0 Change Notes Following is a list of the changes from IBIS version 1.1 to version 2.0. The global changes to the specifications are listed first, then the specific added keywords and changes to existing keywords. The changes are listed in the order they appear in the specification. Only changes related to functionality or meaning are listed; minor changes to spelling, grammar, and syntax are not included. It is expected that this document will evolve into the official release notes for Version 2.0. Global changes to specification: 1. Underscores and spaces are now equivalent in keywords. For example, the version 1.1 keyword [GND_clamp] can now be typed as [GND clamp] and the parser will accept it. The intent is that all new keywords added to the specification NOT use an underscore character. In addition, it is now explicitly required that sub-parameter names NOT contain spaces. 2. Three new scaling factors have been added: T=tera, G=giga and f=femto 3. The characters "+" and "-" have been added to the list of forbidden comment characters. Specific changes: 4. The keyword [Copyright] has been added. A note was also added that derivative models should include the text in the [Notes], [Source] and [Disclaimer] keywords. Any text following the [Copyright] keyword must be included verbatim in the derivative models. 5. The other notes section of [Package] keyword was updated to include references to the [Package Model] keyword. The specification now requires that data in the [Package] keyword always be valid even if the [Package Model] keyword is used. 6. Bird 14.1 was broken into two proposals. The [Spec] keyword was renamed [Pin Extension 1] and the override of Model_type was deleted. John Keifer has agreed to reissue this portion of his bird as Bird 16 and a separate vote will be taken before including into Version 2.0 7. [Package Model] keyword was added per Bird 10.1 with the following added requirement: If the package model is in a separate .pkg file then it must be kept in the same directory as the .ibs file. 8. The [Pin Mapping] keyword was added per Bird 5.4 (Note that the original, approved Bird 5.2 was reopened because of changes required by the adoption of Bird 3, multiple supply rails.) 9. The [Diff Pin] keyword was added per Bird 6.2. 10. To the [Model] keyword was added the sub-parameters Cref, Vmeas, Rref and Vref per the second part of Bird 14.1 John Keifer has agreed to reissue Bird 14 with these changes only. The additional model types per Bird 7.2 were added as well as the terminator model type of Bird 9.2. Bird 2.2 (requiring Vinl and Vinh specification for inputs) was incorporated. 12. The [Temperature range] keyword was added per Bird 13. 11. The [Pullup Reference], [Pulldown Reference], [GND clamp reference], and [POWER clamp reference] keywords were added per Bird 3. 13. The following changes were made in the "Other Notes:" section of the V/I curve waveform table keywords. A) All references to 'Vcc' were clarified to mean the voltage rail referenced by the [Pullup reference] or [POWER clamp reference] keyword. B) Notes on how to tabulate data for ECL type devices were added per Bird 4. B) Bird 8.2 was incorporated by defining monotonic data and stating that non-monotonic data is allowed. C) Bird 15 was incorporated by explicitly stating the assumptions regarding summing of clamp and pullup/pulldown VI curves. The specification also now explicitly allows non-tristatable devices, if needed, to include power and ground clamp data in in the [Pullup] or [Pulldown] table. 14. The [Rgnd], [Rpwer], [Rac] and [Cac] keywords were added per Bird 9.2 along with the "terminator" Model_type. 15. The [Ramp] keyword now includes the R_load sub-parameter per Bird 13 16. The [Rising waveform] and [Falling waveform] keywords were included per Bird 12. 17. The min, typ and max temperature conditions were updated per Bird 13 18. The required voltage range over which an ECL output is characterized is specified per Bird 4. 19. Note on extrapolating full VI table ranges even if using measured data was added per Bird 13. 20. The method used to derive ramp time was updated per Bird 13 and Bird 7.2 21. The "Notes on IBIS_chk program" section was added. This section includes the IBIS_chk references from Bird 8.2 and Bird 11.2 22. The "Package Model" section was added to contain the body of Bird 10.1 ------- changes by BIRD PREVIOUSLY APPROVED BIRDS ADDED TO SPECIFICATION: BIRD SUBJECT ---- ------- 2.2 Requiring VIH VIL thresholds for input devices 3.0 Multiple Power Supplies and References 4.0 ECL Extensions 5.2 reopened by Bird 5.4 6.2 Differential Pin Specification 7.2 Open Specification Completion 8.1 Specification of V/I data Monotonicity 9.2 Terminator Specification 10.1 Describing coupling effects in package models 11.2 Improving common error detection in IBIS_CHK program 12.1 Non-linear driver waveforms BIRDS APPROVED AT THE EDITING COMMITTEE MEETING: BIRD SUBJECT ---- ------- 5.4 Pin Mapping for Ground Bounce Simulation 13.3 Clarify some conditions of measurements 15.0 Clarification on the usage of V/I tables 14.2 Adding timing measurement parameters BIRDS GENERATED AND NEED TO BE APPROVED: BIRD ---- 16.0 Pin Extension portion of 14.2 From speters@ichips.intel.com Thu May 26 13:59:47 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28978; Thu, 26 May 94 13:59:47 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 26 May 94 08:28:47 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 26 May 94 08:27:48 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 26 May 94 08:28:17 PDT Message-Id: <9405261528.AA18905@xtg801.intel.com> To: ibis@vhdl.org Cc: Johm_M_Keifer@ccm.hf.intel.com Subject: Birds 14.3 and 16.0 Date: Thu, 26 May 1994 08:28:16 -0700 From: Stephen Peters Hello Fellow IBISans -- Here are the Birds from John Keifer dealing with measurment conditions and the Pin Extention addiditon. (My apologies to those who recieved this mailing twice.) Regards, Stephen Peters Buffer Issue Resolution Document (BIRD) BIRD ID#: 14.3 ISSUE TITLE: Adding four new sub-parameters to [Model] REQUESTER: John Keifer at Intel DATE SUBMITTED: May 20, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have four new sub-parameters added to a [Model] in order to fully represent the characteristics of a given component's I/O cells. These sub-parameters are desirable for the user of the IBIS [Models] who wishes to perform board level simulations. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Four new sub-parameters, Cref (a reference specload), Rref (a reference resistance), Vref (a reference voltage), and Vmeas (a test voltage), are added to a [Model]. These sub-parameters are also optional. The [Model] section should be changed as shown below, only changes are listed. |************************************************************************* | | Keyword: [Model] | . | . | Sub-Params: ..., Vmeas, Rref, Vref, Cref | | Other Notes: ... Component timings are usually specified into a | reference capacitance that can be listed as Cref, or into | a reference resistance, Rref, pulled to a reference voltage, | Vref. Vmeas is the test voltage at a driver that timings are | specified to. (This is usually around the 50% level of the | voltage thresholds. For example, TTL=1.5V, CMOS=2.5V.) | |************************************************************************* Example: [Model] IB080812 Model_type I/O Polarity Non-Inverting Enable Active-High | Signals A[2-17] Vinl = 0.8V Vinh = 2.0V Vmeas=1.5V |Test voltage timings are specified to Rref=NA |Reference resistance Vref=NA |Reference voltage Cref=50pF |Reference capacitance timings are specified into The Vmeas, Rref, Vref, and Cref sub-parameters would be placed inside each [Model] file, after Vinh. Pictorial description: _________ | | | |\ | Rref |Driver| \|------|----/\/\/----o Vref | | /| _|_ | |/ | --- Cref --------- | --- ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: All of these added [Model] sub-parameters, Vmeas, Rref, Vref, and Cref are standard data available in data books. Allowing the specification of Vmeas, Rref, Vref, and Cref enhances the usability of an IBIS model by providing key parameters for simulation. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* To IBIS Committee: The only real problems I have heard that anybody has with this Bird is that it will be difficult for simulation vendors to implement quickly, and that those just starting to make and use IBIS [Model]s might presently get confused with this new keyword. However, everyone, at the same time, seems to agree that this is a good Bird for those making and using IBIS [Model]s from the perspective of having a smaller .IBS file therefore making it quicker to create, more efficient, and using up less disk space. Am I correct in assuming that everyone would generally agree that this would be a good BIRD to pass for the next IBIS version, but IBIS version 2.0 is too soon? If this is true, this BIRD should just be held out until the final IBIS 2.0 is official, and then passed for the next IBIS version instead of getting thrown out completely. John Buffer Issue Resolution Document (BIRD) BIRD ID#: 16 ISSUE TITLE: Adding an override section for [Model] sub-parameters REQUESTER: John Keifer at Intel DATE SUBMITTED: May 23, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: ************************************************************************* ************************************************************************* STATEMENT OF THE ISSUE: It is desirable to have a new optional keyword added to the top of an .IBS file in order to parameterize the sub-parameters of a [Model] so that each time a [Model] is used with a different sub-parameter a new [Model] would not have to be made. ************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword, [PIN EXTENSION 1], is added to the .IBS file. The keyword [PIN EXTENSION 1] and all of its sub-parameters are optional. The sub-parameters under this keyword override the sub-parameters of a [Model]. Only those pins should be listed in the [PIN EXTENSION 1] section which need to override the default sub-parameters of a [Model]. All sub-parameters must be filled in on a line either with NA or a value. |************************************************************************* | | Keyword: [PIN EXTENSION 1] | Required: No |Description: Used to list pin-level specifications that differ from | the more global sub-params listed under [Model] below. | Sub-Params: Vinl, Vinh, Vmeas, Rref, Vref, Cref, C_comp |Usage Rules: Only pins that have values different from the default | values specified in [Model] sub-parameters should be | listed. Sub-parameters not used on a line must be | filled in with NA. | The [PIN EXTENSION 1] section consists of five characters | for a pin number, six for Vinl, six for Vinh, six for Vmeas, | five for Rref, five for Vref, five for Cref, and six | for each of the three sub-parameters in C_comp. These | three sub-parameters represent the following: typ, min, | and max. All sub-parameters must be separated by at | least one blank space. This comes to a total of | sixty-six characters. | |************************************************************************* Example: Pin1 = I/O, Pin4 = Output/3-state, Pin9 = Input [PIN EXTENSION 1] | C_comp Pin Vinl Vinh Vmeas Rref Vref Cref typ min max 1 0.8V 2.0V 1.5V NA NA 50pF 4.5pF 3.0pF 6.0pF 4 NA NA 2.5V NA NA 30pF NA NA NA 9 1.5V 3.5V NA NA NA NA NA NA NA 12 NA NA NA NA NA NA NA NA NA 13 NA NA NA 50 5V NA NA NA NA This section will be placed directly underneath the pin list (the [Pin] keyword section). ************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Presently if a particular [Model] needs to be used for a couple of buffers in which the only differences are in the Vinl, Vinh, or C_comp sub-parameters, separate [Model]s have to be made. With the [PIN EXTENSION 1] keyword, only one [Model] has to be made with the sub-parameters being passed down from the [PIN EXTENSION 1] section. This feature will reduce the size of the .IBS file. The [PIN EXTENSION 1] section allows separating the details from the core of a [Model], and at the same time, gives the user the sub-parameters he needs. The [PIN EXTENSION 1] keyword is also optional and hence fully backward compatible. ************************************************************************* ANY OTHER BACKGROUND INFORMATION: ************************************************************************* ------- End of Unsent Draft From paulf@eos.ncsu.edu Fri May 27 09:35:37 1994 Return-Path: Received: from c11059-364dan.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11987; Fri, 27 May 94 09:35:37 PDT Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA05060; Fri, 27 May 1994 12:32:58 -0400 From: paulf@eos.ncsu.edu Message-Id: <9405271632.AA05060@c11059-364dan.ece.ncsu.edu> To: ibis@vhdl.org Subject: SI mail list Date: Fri, 27 May 94 12:32:57 EDT Many of you are most likely interested, Regards, Paul ------- Forwarded Message Date: Tue, 17 May 94 09:37:04 +0800 From: Raymond.Anderson@ebay.sun.com (Ray Anderson) To: si-list@android.ebay.sun.com Subject: Signal Integrity Mailing List Now Active ANNOUNCEMENT: The Signal Integrity Mailing List has been activated. PURPOSE: The si-list is intended to be a forum for professionals both in industry and academia to: discuss signal integrity matters, ask questions pertaining to si, make announcements related to si related functions, and anything else you can think of related signal integrity. Modeling, simulation, measurements, software, EMC/EMI are some of the areas for discussion that come to mind. If interest warrants, I can provide ftp space on a publically accessible server for signal integrity related files and programs. HOW TO USE: To send a message to the list subscribers: ==> email to: si-list@android.ebay.sun.com <== Any message sent to this address will be broadcast to ALL subscribers of the list. Remember that this list is comprised of members from various organizations both academic and commercial scattered across the continent, so be careful not to post proprietary information. Please use the si-admin address described below for administrative matters. This will help maximize the signal to noise ratio on the list and keep admin messages from flooding everyones mailbox. For administrative matters (subscribe, unsubscribe, change address, etc.): ==> e-mail to: si-admin@android.ebay.sun.com <== Any message sent to this address will NOT go to the general list, but will result in local action being taken to administer the list. Please note that at this time administration is being done manually so any admin requests will not take effect instantly but may take 1 to 2 days in some cases. Please list the action desired, (subscribe, unsubscribe, change, etc.) in the subject line. Describe the change in the body of the message. Form isn't important as a human will be reading the message. FURTHER DETAILS: The membership of an internet mailing list is a dynamic quantity that will change over time. However to give you an idea of the initial membership, the following list shows those who are presently subscribed to the list: raymond.anderson@uranium.ebay.sun.com raymonda@crosstalk.ebay.sun.com weston.beal@arrakis.ebay.sun.com lovewell@lovewell.ebay.sun.com erich.selna@eng.sun.com eric.bogatin@eng.sun.com tomb@amcc.com pschau@amp.com ddelute@isi.edu gilg@mcc.com Jean-Jacques.Hajjar@analog.com cairo!dah@uunet.uu.net HWTT@asic.sc.ti.com signal-integrity@harris.mlb.semi.harris.com jjr@bnr.ca ldsmith@sjevm5.vnet.ibm.com jwang@swanson.com gaofeng@tanner.com rmittra@decwa.ece.uiuc.edu jose@decwa.ece.uiuc.edu paulf@ncsu.edu canright@convex.com smehrot@eos.ncsu.edu mbs@eos.ncsu.edu slipa@eos.ncsu.edu jtschaff@eos.ncsu.edu astanas@eos.ncsu.edu yctekmen@eos.ncsu.edu charvat@eos.ncsu.edu clark@contec.com raghu@contec.com dileep@contec.com pwang@contec.com Thanks to all of those that expressed interest in the concept of an internet signal integrity mailing list. - ---------------------------------------------------------------------------- This response does not represent the official position of, or statement by, Sun Microsystems Incorporated. The above data is provided for informational purposes only. It is supplied without warranty of any kind. - ---------------------------------------------------------------------------- /\ \\ \ \ \\ / / \/ / / Raymond E. Anderson WB6TPU / / \//\ Signal Integrity Engineer \//\ / / Sun Microsystems / / /\ / 2550 Garcia Ave. MS MIL04-16 / \\ \ Mountain View, CA 94043-1100 \ \\ \/ (408) 276-5224 (408) 956-0492 fax raymond.anderson@Sun.Com ------- End of Forwarded Message From bob@icx.com Fri May 27 14:00:43 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13641; Fri, 27 May 94 14:00:43 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02189 for ; Fri, 27 May 94 16:49:50 -0400 Date: Fri, 27 May 94 13:42:07 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03769; Fri, 27 May 94 13:42:07 PDT Message-Id: <9405272042.AA03769@icx.com> To: ibis@vhdl.org Subject: IBIS Ver2.0.1 Editing Comments To IBIS Committee: Many comments on Version 2_0.1 were captured at the meeting. Here are a a few more minor editoral comments: 1. Under [Package], Other Notes, last sentence: Reword it to something like: "However, the [Package] keyword is still required to contain valid default data in case the [Package Model] keyword is not recognized." 2. Under [Model], Other Notes, second to last paragraph: a) missing ] in [Pulldown] keyword b) last sentence: "and" should be "an" 3. In [Pulldown Reference], [GND Clamp Reference], "0v" should be "0 V" to be consistent with other sections (or 0V). 4. Under [Rgnd], [Rpower, [Rac], [Cac] the figure for Terminator Model has the "Parameters" line shifted. It should be centered under "PACKAGE keyword". Also, is it worth some attempt to make all of the pictures consistent with each other, e.g., the same inductance, resistance and capacitance symbols? 5. Under [Ramp], Required: Should state "Yes, except for inputs and terminators". 6. Under [Rising Waveform], [Falling Waveform], the figure showing C_fixture is missing a line. See comment in 4 about consistent diagrams. 7. In NOTES ON DATA DERIVATION SECTION, a) Consider changing typ, min and max text to this format: typ = typical voltage, typical temperature, typical process min = minimum voltage, maximum temperature, typical process, minus "X%" max = maximum voltage, minimum temperature, typical process, plus "X%" .... etc. "low voltage tol, max temp deg C, ..." is not as direct in lining up the "typ", "min", and "max" voltages and temperatures defined elsewhere. b) For consistency, pick one of the formats for defining voltage: "(0 - 5) = -5 V .............. or (0 - 5) = -5V Vcc to Vcc - 2.2V ............. or Vcc to Vcc - 2.2 V under 3) b. (Vterm = VCC -2v) ... (Vterm = Vcc - 2 V) or (Vterm = Vcc -2V) c) Under 3) e., change "X%" to "Y%" in defining the extremes. See note for a) above. 8. In the PACKAGE MODELING section, second paragraph, "The resolved specification ..." should be "The specification ..." Is it really appropriate to repeat almost completely the [Package Model] keyword here? It is already in the main "*.ibs" section where it belongs. 9. Under SYNTAX FOR THE .PKG FILE section, third paragraph, "Required" should be "required". 10. Finally, Under [Number of Pins], I am looking forward to seeing an example of a complete package model which contains 1e58 pins (the number of pins defined by a "positive integer less than 60 characters long" without leading zeros. I am glad we are planning for future capacity. Perhaps in Usage Rules: "The value must be a positive integer." Great job Derrick and Stephen for your editing!! Bob Ross Interconnectix, Inc. From bob@icx.com Sat May 28 18:27:44 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26910; Sat, 28 May 94 18:27:44 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04724 for ; Sat, 28 May 94 21:19:50 -0400 Date: Sat, 28 May 94 18:11:33 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA07854; Sat, 28 May 94 18:11:33 PDT Message-Id: <9405290111.AA07854@icx.com> To: ibis@vhdl.org Subject: IBIS_CHK REVISION DOCUMENT NAME To IBIS Committee: How about "PEEP" for Parser Error Extraction|Elimination|Eradication|E... Proposal? Then I can say that I do not want to hear a PEEP out of the person who proposed the "God-like assembly that can make no error" name. Bob Ross Interconnectix, Inc. From bob@icx.com Sun May 29 18:27:44 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07287; Sun, 29 May 94 18:27:44 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA03679 for ; Sun, 29 May 94 21:16:00 -0400 Date: Sun, 29 May 94 18:04:48 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10105; Sun, 29 May 94 18:04:48 PDT Message-Id: <9405300104.AA10105@icx.com> To: ibis@vhdl.org Subject: IBIS VER2.0 COMMENT Stephen and Derrick: How about putting the official title of "IBIS: I/O Buffer Information Specification" at the beginning of the Spec. so we know what IBIS stands for. Bob Ross Interconnectix, Inc. From bracken@bacon.performance.com Tue May 31 07:32:22 1994 Return-Path: Received: from bacon.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27895; Tue, 31 May 94 07:32:22 PDT Received: by bacon.performance.com (4.1/SMI-4.1) id AA03881; Tue, 31 May 94 10:32:11 EDT Message-Id: <9405311432.AA03881@bacon.performance.com> To: ibis@vhdl.org Subject: Bird 10 minor revision (Bird 10.2) for IBIS 2.0 Date: Tue, 31 May 94 10:32:08 -0400 From: bracken@bacon.performance.com All, This is a slightly revised version of BIRD 10 which incorporates the [End Package Model] keyword that was discussed in the telemeeting of 05-27-94. I have also removed the semi-humorous company names and disclaimers. I have taken the liberty of adding the new, optional [Copyright] keyword to the package models, as was done for the main IBIS file. This was not strictly necessary, since the .pkg file is just an IBIS 2.0 file without [Component] and [Model] keywords... --Eric ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 10.2 ISSUE TITLE: Describing coupling effects in package models REQUESTOR: Eric Bracken, Performance Signal Integrity, Inc. DATE SUBMITTED: 17 March 1994 DATE REVISED: 15 April 1994 DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: For a more thorough signal integrity analysis, a mechanism is needed for describing electromagnetic couplings between the different pins of a package. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Summary: ------- A new keyword, [Package Model], is added to the .ibs file. This keyword is used within a [Component] to indicate (by name) the package model that should be used for a part. Package models can be found either in separate package model files, which bear the .pkg extension, or within the same .ibs file as the [Component]. An additional new keyword, [Define Package Model], is also added to the specification; this is used to mark the beginning of the actual package model data. The purpose of breaking up the package model and the component model is to make associations between the two more flexible: several components may share a single package model, or one component may have several different incarnations which use different packages (and thus, different package models). Use of [Package Model] is OPTIONAL. If it is not provided, then the table of RLC values listed in the [Pin] section of the [Component] is used as the "package model" for the part. On the other hand, if the [Package Model] IS given, then the R_pin, L_pin and C_pin values in the [Pin] section may either be ignored, or may be used for less detailed simulations without coupling. Probably this data will simply be left out of the [Pin] section when a [Package Model] is used; this practice is permitted by the IBIS Ver. 1.1 specification since [Pin] data may contain either 3 or 6 columns. A .pkg file is just an ordinary IBIS file, with the restriction that it cannot contain [Component]'s or [Model]'s. Only package models declared by the [Define Package Model] keyword may be contained within these files. Of course, all of the necessary components of an IBIS file ([IBIS Ver], [File Name], [File Rev], etc. through [End]) must still be included within a .pkg file. The package model to be used treats every package as a collection of current carrying "paths," which lead from the board, through the packages pins, leadframe traces and bonding wires to a bonding pad on the die itself. Each path has a self-resistance, self-inductance and self-capacitance associated with it. In addition, there is the flexibility to describe mutual inductance, mutual resistance and coupling capacitance drops between every path. This data can be listed concisely as three RLC parameter matrices. This BIRD describes how these matrices are to be formatted. I. Syntax for the .IBS File. ---------------------------- The following syntax is used for specifying a package model: |============================================================================== | | Keyword: [Package Model] | | Required: No | | Description: Used to indicate the name of the package model | | Usage Rules: The Package_Model_Name is limited to 40 characters. | Spaces are allowed in the name. | |------------------------------------------------------------------------------ | [Package Model] Package_Model_Name The [Package_Model] keyword is used within a [Component] to indicate which package model should be used for that part. The resolved specification permits .ibs files to contain [Define Package Model] keywords as well. These are described in Section II, "Syntax for the .PKG file", below. 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 which have the same name. II. Syntax for the .PKG File ----------------------------- Package models are stored in a file whose name looks like .pkg The provided must adhere to the venerable MS-DOS file name conventions: it must not exceed 8 characters in length. All of these characters must be lower case. The extension ".pkg" is used to identify files containing package models. The .pkg file must contain all of the Required elements of a normal .ibs file, including [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], and [Comment char] keywords. All of the above elements follow the exact same rules as those for a normal .ibs file. Items which are FORBIDDEN in the .pkg file are [Component] and [Model] keywords. The .pkg file is only for package models. A. Package Models ------------------ Each package model is preceded by the [Define Package Model] keyword. |============================================================================== | | Keyword: [Define Package Model] | | Required: Yes | | Description: Used to mark 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 and blank characters ARE | allowed. | |------------------------------------------------------------------------------ | [Define Package Model] Package_Model_Name The [End Package Model] keyword marks the end of a complete package model. For every [Define Package Model], a corresponding [End Package Model] keyword is required. |============================================================================== | | Keyword: [End Package Model] | | Required: Yes | | Description: Used to mark the end of a package model description. | | Usage Rules: The keyword must come at the end of each complete package | model description. | | It is suggested that a comment follow the [End Package Model] | 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] Between the [Define Package Model] and the [End Package Model] keywords, a package model description is provided. This consists of several keywords described below. The [Manufacturer] keyword is used to declare the manufacturer of the part(s) which use this package model. This would typically be the name of the semiconductor vendor. The syntax is identical to that of the [Manufacturer] keyword in the .ibs file, e.g. [Manufacturer] Quality Semiconductors Ltd. An additional optional keyword, [OEM], is used to indicate the name of the PACKAGE's manufacturer. This is useful if the semiconductor vendor sells a single IC in packages from different manufacturers (e.g. AMP, Kyocera). The [OEM] keyword's syntax is analogous to that of the [Manufacturer] keyword. [OEM] Acme Packaging Co. The [Description] keyword is used to indicate to a human being what the model is describing. |============================================================================== | | Keyword: [Description] | | Required: Yes | | Description: This is used to provide a concise yet easily human-readable | description of what kind of package the [Package_Model] | is representing. An example Description_Text might be: | "220-Pin Quad Ceramic Flat Pack". | | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and MAY contain spaces. | |------------------------------------------------------------------------------ | [Description] Description_Text The [Number of Pins] keyword identifies how many pins the package has. |============================================================================== | | Keyword: [Number of Pins] | | Required: Yes | | Description: This is used to tell the parser how many pins to expect. | | Usage Rules: The How_Many field must be a positive integer less than 60 | characters long. | |------------------------------------------------------------------------------ | [Number of Pins] How_Many The [Pin Names] keyword is used to list the names of the pins of the package, and to define an "ordering" among them. If the integers 1, 2, 3, ... are used as pin names, then the ordering is probably the obvious one. However, this is not the case when alphanumeric pin names are used. Since the ordering is very important for the RLC matrix information to be described shortly, we require that it be made explicit before those matrices are given. |============================================================================== | | Keyword: [Pin Names] | | Required: Yes | | Description: This is used to tell the parser the set of names that | will be used for the package pins, and to define an | ordering of them. The first pin name given is the | "lowest" pin, and the last pin given is the "highest." | The pin names may not exceed 5 characters in length. | | Usage Rules: Following the [Pin Names] field, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) | |------------------------------------------------------------------------------ | [Pin Names] | A1 A2 | . | . | . A22 B1 | . | . | . | etc. The beginning of the actual model data is marked with the [Model Data] keyword. |============================================================================== | | Keyword: [Model Data] | | Required: Yes | | Description: This is used to indicate the beginning of the formatted | model data. | | Usage Rules: This is pretty simple. | |------------------------------------------------------------------------------ | [Model Data] Similarly, the end of the model data is marked with an [End Model Data] keyword: |============================================================================== | | Keyword: [End Model Data] | | Required: Yes | | Description: This is used to indicate the end of the formatted | model data. | | Usage Rules: This is pretty simple too. | |------------------------------------------------------------------------------ | [End Model Data] In between these two keywords is the package model data itself. The data to be supplied is a set of 3 matrices: the resistance (R), inductance (L), and capacitance (C) matrices. Each matrix may be formatted differently (see below). A special keyword is used to mark the beginning of each new matrix: |============================================================================== | | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | | Required: [Resistance Matrix] is optional. If it's not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | | Description: These are used to mark the beginning of a matrix, and to | specify how the matrix data will be formatted. | | Usage Rules: There are 3 choices for the Format_Keyword: | Banded Matrix, Sparse Matrix, and Full Matrix. | | After each of these keywords, the matrix data will follow | in the appropriate format. | | These formats are described in detail below. | |------------------------------------------------------------------------------ | [Resistance Matrix] Format_Keyword [Inductance Matrix] Format_Keyword [Capacitance Matrix] Format_Keyword C. Matrix Formats ------------------ For each [Resistance Matrix], [Inductance Matrix], or [Capacitance Matrix] a different format may 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 may have no coupling terms at all; in this case, the most concise format (Banded_Matrix) may be used. One common aspect of all the different formats is that they exploit the symmetry of the matrices they describe. This means that the entries below the main diagonal of the matrix are identical to the corresponding entries above the main diagonal. Therefore, only roughly one-half of the matrix needs to be described. By convention, the main diagonal and the UPPER half of the matrix will be provided. The available formats are Banded_Matrix, Sparse_Matrix, and Full_Matrix. We describe each of the formats separately below. In the following, 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 has been defined earlier in the [Pin Names] section. The reader is advised that the following text sometimes refers to "Row 1", by which we mean the row corresponding to the first pin. Also, please 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". 1. Full_Matrix When the Full_Matrix format is used, the couplings between every pair of elements will be specified explicitly. We 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: This is used to indicate the beginning of a new row of | the matrix. The Row_Number field must be a pin name, | | Usage Rules: This is pretty simple. | |------------------------------------------------------------------------------ | [Row] Row_Number Following a [Row] keyword is a block of numbers which 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 are the entries of the upper half of the matrix that belong to row M: [M, M+1], [M, M+2], ... up to [M,N]. For even a modest-sized package, this data will not all fit on one line. Since each line of an IBIS file must be 80 characters long or less, it is permissible to break the data up with newlines so that this limit is observed. An example: suppose the package has 40 pins and that we are currently working on Row 19. There will be 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. It will be observed that Row 1 always has the most entries, and that each successive row has one fewer entry than the last; the last row will always have just a single entry. 2. 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." Again let the matrix size be N, and let the bandwidth be B. An entry [I,J] of the matrix will be zero if | I - J | > B where |.| denotes the absolute value. The bandwidth for a Banded_Matrix must be specified using the [Bandwidth] keyword: |============================================================================== | | Keyword: [Bandwidth] | | Required: Yes (for banded matrices only) | | Description: This is used to indicate the bandwidth of the matrix. | The BW field below must be a nonnegative integer. This | keyword occurs after the [Resistance Matrix], etc. | keyword, and BEFORE the matrix data is given. | | Usage Rules: This is pretty simple. | |------------------------------------------------------------------------------ | [Bandwidth] BW The banded matrix is specified one row at a time, starting with row 1 and working up to higher rows. Each row is marked with the [Row] keyword, as above. As before, symmetry is exploited: entries below the main diagonal are never given. The first row will only need to specify the entries [1,1] through [1,1+B] since any other entries are guaranteed to be zero. The second row will need to specify the entries [2,2] through [2, 2+B], and so on. In general, for row M the entries [M,M] through [M,M+B] are given. Unlike the Full_Matrix, each successive row will _typically_ have the same number of entries, except for the last few rows. When M + B finally exceeds the size of the matrix N, then the number of entries in each row will start to decrease; the last row (row N) will have only 1 entry. As in the Full_Matrix, if all the entries for a particular row will not fit into a single 80-character line, the entries may 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. 3. Sparse_Matrix The final option for specifying the entries of the matrix is the Sparse_Matrix format. 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 may occur. This is useful in certain situations, such as for Pin Grid Arrays (PGA's.) As usual, symmetry may 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 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 may 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 Please 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 Names] section is observed. Also, please note that it is again necessarily the case that the N'th row of an N x N matrix will have just a single entry (the diagonal entry.) D. An Example The following is an example of a package model file following the above specifications. For the sake of brevity, an 8-pin package has been described. For purposes of illustration, each of the matrices is specified using a different format. | |================================================================ | [IBIS Ver] 2.0 [File Name] example.pkg [File Rev] 0.1 [Date] 17 April 1994 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver, using 3-D Autocad model from Acme Packaging. [Notes] Example for a BIRD on 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 Packaging Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Names] 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 | | All done! | [End Model Data] [End Package Model] | QS-SMT-cer-8-pin-pkgs [End] III. Note on Measurement ------------------------- When measuring the entries of the RLC matrices, either with laboratory equipment or field solver software, the following fact should be kept in mind: Currents are defined as ENTERING the pins of the package from the board. The corresponding voltage drops are to be measured with the current pointing "in" to the "+" sign and "out" of the "-" sign. I1 +-----+ I2 -----> | | <------ board 0--------| Pkg |---------0 board + V1 - | | - V2 + +-----+ It is important to observe this convention in order to get the correct signs for the mutual inductances and resistances. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This is an attempt to add more electromagnetic information to the packaging models. The main element missing from the original IBIS packaging models are couplings between pins. These couplings can change the effective inductances of power and ground pins, affecting the amount of ground bounce that occurs in the model. The couplings can also lead to increased noise between signal pins. For these reasons (and more), they are worth considering. There are many ways one might approach the description of the coupling information. The choices made will certainly impact the efficiency and the accuracy of the signal integrity simulations that are carried out. To meet a wide variety of needs, several different options have been provided for specifying the coupling data. Full-matrix formats may be used for maximum electromagnetic rigorousness, or descriptions with limited amounts of coupling can be used to speed up simulation. This BIRD permits detailed package model information to be stored either in the .ibs file, along with [Component]'s and [Model]'s, or in a separate .pkg file. In the case where the package model is defined in the .ibs file, that definition is local to that single file. When a .pkg file is used, the model definition is exported, so that it can be used by IBIS [Component]'s in other files. Note that this is a departure from standard IBIS practice--in .ibs files, the "model" names, at least, are not exported from the file that contains them. Keeping package model data in separate files leads to the possibility of naming conflicts when different vendors (or even different groups within a large vendor company) provide files independently. Hopefully this can be managed by using long names for package models, and by using an official "name server" which keeps track of existing model names and warns of conflicts. What is still missing from this spec is the ability to handle models with arbitrary topologies of RLC circuit elements. This would be useful, for example, in the modelling of large packages where the traces are long enough to exhibit some "transmission-line" effects. In these cases, it would be useful to be able to break the single series RL element up into a ladder (or some more complex structure) of RLC elements. This capability will become more important as the signal speeds of the IC's rise. Therefore, this spec may need to be overhauled and updated at some time in the not-too-distant future. It is certainly true that the Full_Matrix format is a special case of both the Banded_Matrix and the Sparse_Matrix formats. It can be regarded as "syntactic sugar" which may or may not appeal to everyone. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The classic electromagnetics text by Ramo, Whinnery and Van Duzer provides some nice background theory on how one goes about defining resistance, inductance and capacitance values for arbitrary structures, and also describes the high-frequency limitations to this approach. ******************************************************************************* From Will_Hobbs@ccm2.jf.intel.com Tue May 31 11:18:04 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29378; Tue, 31 May 94 11:18:04 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 31 May 94 11:15:19 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 31 May 94 11:15:09 -0700 Received: from ccMail by jfsmt2.intel.com id AA770408108 Tue, 31 May 94 11:15:08 PDT Date: Tue, 31 May 94 11:15:08 PDT From: "Hobbs, Will" Message-Id: <9404317704.AA770408108@jfsmt2.intel.com> To: ibis@vhdl.org, bob@icx.com ( Bob Ross) Subject: Re: IBIS VER2.0 COMMENT I agree. In fact, we could put a concise one-line description of the IBIS philosophy right under it: "A behavioral method of specifying I/O buffer characteristics that can be parsed easily by software." Or something like that.... Will Stephen and Derrick: How about putting the official title of "IBIS: I/O Buffer Information Specification" at the beginning of the Spec. so we know what IBIS stands for. Bob Ross Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Tue May 31 16:20:47 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01416; Tue, 31 May 94 16:20:47 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 31 May 94 16:18:08 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Tue, 31 May 94 16:17:50 -0700 Received: from ccMail by jfsmt2.intel.com id AA770426278 Tue, 31 May 94 16:17:58 PDT Date: Tue, 31 May 94 16:17:58 PDT From: "Hobbs, Will" Message-Id: <9404317704.AA770426278@jfsmt2.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com Cc: ibis@vhdl.org Subject: Re: DAC meeting schedule Arpad, You and several others have asked me this, so I am copying the reflector in case anyone else is in the dark. The Birds of a Feather session is on Wednesday night, 6/8, beginning at 5:30 PM. It will be in or near the convention center. The IBIS V2.0 ratification session will be at a Cadence site in San Diego all day Thursday, 6/9. Kumar will be getting us the directions to the meeting. Arrival time for the Thursday meeting is 8:00. The meeting will start no later than 8:30, lunch is targeted for noon, and Kumar is providing morning coffee and donuts. Right Kumar? Will Will, Does anyone have a schedule for the IBIS meetings at DAC? I would like to make travel plans, and I need to know our meeting times. Arpad